FPP 8.4 released!

[dkulp]

FPP 8.4 is released!

This release consists mostly of bug fixes as the result of digging through crash logs, bug reports, zoom room issues, etc...  The main purpose is to provide a release that rolls all the crash fixes and other bug fixes into an easy to install/use release package.

NOTE: The OS level has not changed since 8.3. There is no need to do an fppos update if coming from 8.3.

Enhancements

• Add Advanced option to stop Colorlight outputs from being disabled if ethernet link is down when fppd starts
• Update rpi_ws281x to support newer Pi 3A+/3B/3B+/CM3
• Update UDPOutput to support a "blocking" mode to slow down packet output to allow slower controllers to keep up better. (Advanced UI setting)
• Schedule Preview - mark items that will be skipped in red and note priority reason

Bug Fixes (since 8.3.0)

• Fix crash when manually stopping playlist using ArtNet/SMPTE plugins as timecode generator
• Fix crash using HTTP to detect some AlphaPix controllers
• Fix pixel output on right half of K128
• Fix crashes on SanCloud BeagleBone Enhanced due to to gpiochip label differences
• Fix api/scripts//run
• Fix api/events/:eventId/trigger
• Fix failed plugin install messaging
• Fix HDMI audio out on Pi's
• Fix crash if efuse enable pin cannot be configured. Warn and continue, but don't crash
• Fix a potential crash if PLAYLIST_STOPPED command preset is called
• Fix crash if Chase/Cycle custom pattern is selected, but pattern is empty
• Fix crash if pixel configuration or other configuration json is invalid during output setup
• Fix tooltips on MQTT page being truncated
• Fix some crashes with dynamic playlists that are empty
• Fix some crashes with invalid pixel overlay model configurations
• Fix crashes with RGBMatrix (panel hats for Pi) on older armv6 Pi's
• Fix a crash when sending invalid WLED effect commands
• Fix a crash if fseq file is corrupt

Installation Instructions
If you have a system running 8.x, you can go to the FPP about page (about.php) and click on the "Manual Update" button. At that point, a big green "Upgrade" bar should appear on the main status page. Click on that to start the update process. It may take a long time to upgrade. Likely 5-10 minutes. You will need to reboot after the upgrade is complete to finish the upgrade process.

For users of FPP 7.x or older, it is strongly recommended to do a full "OS Level" upgrade or re-image instead of attempting to upgrade directly from any older FPP version. There are several new features that will not work if an OS level upgrade is not done. There are two ways to do so:

• Re-image - you can backup your 7.x configuration, create a new image, and restore the configuration.
• In-place upgrade - this requires you to have FPP 5.5 and all the updates for 5.5 or FPP 6.x/7.x already running on the device. Download the appropriate "fppos" file to your computer. Make sure the file extension is still fppos (some browsers will rename it). Upload it to the "File Manager" on the FPP instance. Then go to the about page. Under the normal "Manual Upgrade", a new Upgrade OS button should appear. Click it and wait a LONG time. When done, it should reboot into 8.3. At that point, go to the Uploads tab of the FPP File Manager and delete the fppos file. An alternate method to do an in-place upgrade if you are only upgrading one device AND the device has internet connectivity, is to select the 8.3 fppos (download) file and then click on the Upgrade OS button. This will download the fppos file and then install it as mentioned above. This will still take a LONG time and if you are doing this on more than one device, you will essentially be downloading the same file multiple times so is probably not the best way.

NOTE: In SOME cases, the reboot will fail due to library replacement. In that case, a power cycle may be required to get it back up and running.

Selecting an image

For Raspberry Pi series use this image
https://github.com/FalconChristmas/fpp/releases/download/8.4/FPP-v8.4-Pi.img.zip

For Beaglebone Black, Beaglebone Green, PocketBeagle, and Beaglebone Green Gateway use this image
https://github.com/FalconChristmas/fpp/releases/download/8.4/FPP-v8.4-BBB.img.zip

[lrhorer]

I am currently running 8.4 on a system with input GPIO4 enabled on the falling edge to run a Python script.  I need to have the script check both GPIO4 and GPIO17 to see if one or both are low.  In Python, when I use

import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
GPIO.setup(4,GPIO.IN)
GPIO.setup(17,GPIO.IN)

I get an error lgpio.error: 'GPIO busy' on the GPIO.setup(4,GPIO.IN) line.

Note this script runs under more conditions than only when GPIO4 is low, so I cannot merely assume GPIO4 is low.

What would be the best way to handle this?  Gpiozero also does not work.

[MikeKrebs]

I might not understand how Python and FPP play together but I think FPP has that pin "busy". So skip the setup and just read "the other one".

[dkulp]

Do you have a hat installed that may be consuming pins?

You could likely run "gpioinfo" from the command line it it may show which process is consuming the GPIO pins.

[lrhorer]

FPP is indeed using the pin, as expected.  The problem is, I still need to be able to scan the state of the pin in the external script.  The script needs to run on the falling edge of the pin, but it also needs to examine the pin whether nor not it has been called by FPP.  It runs under various situations, including when FPP calls it, as well, and it needs to know the status of the pin whether it has been called by FPP or not.

[darylc]

FPP is indeed using the pin, as expected.  The problem is, I still need to be able to scan the state of the pin in the external script.  The script needs to run on the falling edge of the pin, but it also needs to examine the pin whether nor not it has been called by FPP.  It runs under various situations, including when FPP calls it, as well, and it needs to know the status of the pin whether it has been called by FPP or not.

Personally, I would use node-red instead of a script and have FPP issue a MQTT status when the pin is pressed and let node-red do all the logic including calling back to FPP's API to cause FPP to do things.  This comes with the added bonus of a visual workflow rather than having to re-read/learn the script each time to troubleshoot or modify it.

[lrhorer]

The script does not interact with FPP in any way.  It runs under various situations, one of which is a power or fuse failure, which is indicated by GPIO4 transitioning from around 3V to 0V.  After the script is spawned, it collects various data such as CPU usage, memory usage, temperature, etc.  If requested by the name used to call the script, or if an important situation exists it sends emails and / or texts.  Otherwise it responds per the name used to call the script.

If both GPIO4 and GPIO17 are low, then there is a main power or main fuse failure.  If only GPIO4 is low, then it is a failure of the fuse feeding the string.  If neither are low, then power is OK. (Obviously in this latter case, the script was not called by FPP.) Here is the script so far:

#! /usr/bin/python3
# pi_monitor.py
# Scan / print the health of a Raspberry Pi and
# report any issues to the phone or email list

import psutil, subprocess, email, smtplib, ssl, SendMessage
from time import sleep
from sys import argv, exit
from os import uname
from gpiozero import CPUTemperature
import RPi.GPIO as GPIO

Degrees = "\u00B0C"	# Degree symbol UTF-16
Degrees = "C"

HighCPUUsage = 90	# High CPU usage in %
HighCPUTemp = 65	# High CPU temperature in Celsius
CritCPUTemp = 80	# Critical CPU temperature in Celsius
HighMemUsage = 70	# High Memory utilization
HighDiskUsage = 60	# High Disk utilization
Uname = uname().nodename

phones = [["##########", "Consumer Cellular", True],["##########", "Sprint", True], ["#######", "##########", False]]

# runDef = [ Script Name, Delay in seconds, Send to stdout, Send email / sms ]
runDef = [["start", 30, False, True], ["check", 0, False, False], ["print", 0, True, False], ["flash", 0, True, True], ["mail", 0, False, True]]

GPIO.setmode(GPIO.BCM)
GPIO.setup(4,GPIO.IN)
GPIO.setup(17,GPIO.IN)

Fuse = GPIO.input(4)
Power = GPIO.input(17)

if len(argv) > 0:	# Should always be non-zero if called from CLI
	envString = argv[0]	# Contains the name by which the script was called
	for runVal in runDef:
		scriptName, scriptDelay, scriptPrint, scriptMail, *rest = runVal
		if envString.find(scriptName) > 0:	# Check if script called with this runVal value
			sleep(scriptDelay)
			break
else:
	print("WTF?")	# Not called from CLI
	exit(1)

def pi_status():	# Main routine: always called by script
	# Gather information about system
	result1 = getTemperature()
	result2 = getCPU()
	result3 = getDiskUsage()
	result4 = getMemUsage()
	if scriptMail:	# Called with Mail Send request: send email
		if scriptName == "start":
			sendText = "Raspberry Pi Startup notification\r\n"
		else:
			sendText = "Raspberry Pi Monitor Mail\r\n"
		sendText = sendText + "Host Name: " + Uname + "\r\n"
		sendText = sendText + result1+ "\r\n"
		sendText = sendText + result2+ "\r\n"
		sendText = sendText + result3+ "\r\n"
		sendText = sendText + result4+ "\r"
		sendMessage(sendText)
	if scriptPrint:	# Called with display request: send to stdout
		print("Host Name: " + Uname)
		print(result1)
		print(result2)
		print(result3)
		print(result4)

def getTemperature():
	cpuTemp = int(CPUTemperature().temperature)
	Ctemp = "CPU Temperature: " + str(cpuTemp) + Degrees
	if cpuTemp > CritCPUTemp:
		sendText = "CRITICAL ALARM FROM HOST " + Uname + "!\r\nALERT: Critical temperature " + str(Ctemp) + ".\r\nShutting system down...\r"
		sendMessage(sendText)
		sleep(10)
		subprocess.run(["shutdown", "-h", "0"])
	elif cpuTemp > HighCPUTemp:
		sendText = "Alarm From Host " + Uname + "!\r\nWarning: High temperature " + str(Ctemp) + ".\r"
		sendMessage(sendText)
	return Ctemp

def getCPU():
	cpuPercent = int(psutil.cpu_percent(1))
	Cusage = "CPU Usage: " + str(cpuPercent) + "%"
	if cpuPercent > HighCPUUsage:
		# Sending alert on high cpu usage."
		sendText = "Alert From HOST " + Uname + "!\r\nWarning: High CPU Utilization " + str(cpuPercent) + "%\r"
		sendMessage(sendText)
	return Cusage

def getDiskUsage():
	for dp in psutil.disk_partitions():
		diskUsagePercent = int(psutil.disk_usage(dp.mountpoint).percent)
		diskPercent = "Disk Usage: " + str(diskUsagePercent) + "%"
		if (diskUsagePercent > HighDiskUsage):
			sendText = "Warning From Host " + Uname + "!\r\nWarning: High Disk Usage " + str(diskUsagePercent) + "%.\r"
			sendMessage(sendText)
		return diskPercent

def getMemUsage():
	memUsagePercent = int(psutil.virtual_memory().percent)
	if (memUsagePercent > HighMemUsage):
		sendText = "Alert From Host " + Uname + "!\r\nWarning: High Memory Usage " + str(memUsagePercent) + "%.\r"
		sendMessage(alertMsg)
	memUse = "Memory Usage: " +str(memUsagePercent) + "%"
	return memUse

def getPower():
	if not Fuse:
		if not Power:
			Text = "Main power failure.  Shutdown will occur shortly."
		else:
			Text = "Fuse failure."
		SendMessage(Text)
pi_status()

[lrhorer]

I was unfamiliar with node-red, so I looked it up.  It is just about the last thing on Earth I would want to use for this application.  I could, of course, use an external watchdog to keep track of the GPIO pins, but why add extra code if the code to handle the transition is already in FPP?  I could also take a brute force approach and spawn an external instance of `gpioinfo | grep GPIO4 | grep low`, but that is quite brittle and rather klunky.  An internal Python routine would be far more future proof and independent of the vagaries of gpioinfo.