DietPi-Banner | Show low voltage⚡️ warning

[Marzal]

As discussed on #3225 (better late than never)

Hi, first time contributor (and not experienced dev). I've tested this functionality on 3 devices (2 Rpi 3A+ and 1 RPi2)

It will do nothing if the user doesn't has access to /dev/vcio[_gencmd]
if [[ -r /dev/vcio ]]; then
On my system root or been on the video group is needed (usermod -aG video dietpi), but checking the file seems more "bulletproof".

On Print_Header I changed the order with this check first, so having updates doesn't hide the Undervoltage. But this will hide updates notifications.

I could change the code to show both, but wanted to ask first. With only one warning I think that it's better to first know that we have voltage problems before upgrading (happy to change otherwise).

Sorry if I messed up some convention.

vcgencmd get_throttled can show 4 states for 2 moments current and "occurred" (not sure about the scope). So I have implemented warning only for current problems, but show on grey "occurred" ones if detected.

Feedback welcome. Thanks for this great project.

EDITED:

I'm not sure if this option should be restricted on some devices like VMs on:

	if (($G_HW_MODEL == 20)); then
		aENABLED=(1 0 0 0 0 1 0 1 0 0 0 1 1 0 0 1 0 0 0 0 0 0)
	else
		aENABLED=(1 0 1 0 0 1 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 1)
	fi

Actually I think I can revert that change. Seems like it doesn't apply for Print_Header and Print_Updates

[Marzal]

Example of just past warnings throttled=0x50000:

Nothing on Header and only grey on Print_Updates

[Marzal]

Rebased, there was no conflicts.

[MichaIng]

Please rebase this, since the script went through same major changes.

And please change the following things:

• vcgencmd exists on Raspberry Pi only, hence skip the check on non-RPi systems (( $G_HW_MODEL > 9 )).
• You currently skip Check_DietPi_Update etc if the system is throttled, but you do print the info not as replacement for the update notification, but additionally (which itself is good). However, $AVAILABLE_UPDATE is set by Check_DietPi_Update. To show both notifications alongside, Check_Throttled must not run instead of Check_DietPi_Update, but additionally (if this is an RPi system).
• There are new color codes aCOLOUR[highlight] and aCOLOUR[alert], which could be used for past and current events respectively.
• I'd also adjust the wording, to not throw "Throttled" in every case, but maybe a short (header) and long message about what really happened: undervoltage, thermal throttling, etc. The long form could add a recommendation about how to mitigate it: replace PSU, enhance cooling, etc, depending on the actual event.

[Marzal]

Thanks for the feedback, I've started testing what I can do about them (not been a developer).

But I have doubts about this request:

• I'd also adjust the wording, to now thow "Throttled" in every case, but maybe a short (header) and long message about what really happened: undervoltage, thermal throttling, etc. The long form could add a recommendation about how to mitigate it: replace PSU, enhance cooling, etc, depending on the actual event.

Does this refers to Print_Header ? On Print_Updates I'm already showing what the problem is (Undervoltage, Freq, Throttled, Temp...)
On Print_Header I could change Throttled! to Throttled detected! check details below. But I didn't want to make it to long for small "screens"

Or do you mean the Throttled : list of types that I'm displaying on Print_Updates.
That I should show something like:

• Undervoltage has ocurred : Check PSU, voltage...
• And a new line for each type (current/past + Undervoltage, Freq, Throttled, Temp). Or similar to the Disk Usage ?

Option with a new line on Print_Header to not superseed updates, and with similar Disk Usage format on Print_Updates. Work in progress.

Example with also updates available

[MichaIng]

What I means is, in case it is a current undervoltage event, and a past temperature limit event:

 ─────────────────────────────────────────────────────
 DietPi v10.6.2 : Current undervoltage detected!
 ─────────────────────────────────────────────────────
 ...
 ─────────────────────────────────────────────────────

 apt upgrade     : Run now to apply 1 available APT package upgrades
 Current undervoltage detected! Please check PSU and peripherals for stable operation!
 Temp limit recently exceeded! You might want to think about enhancing your cooling.

Something like this. I'm no fans of additional separator lines. Aim to reduce those which have been added with v10.6, at least in case there is only one disk or command. Hence I'd also prefer those new warnings without additional separator lines:

• Replacing the existing update notification in the upper Print_Header is fine. We might think about some priority, like current events > updates > past event, or so. It cannot be a full sentence, but a few words like above are fine. "Throttled" is something very different than "undervoltage", even that both events are checked with the get_throttled command. So if it is an undervoltage event, which I'd rate a lot more critical than thermal throttling, then this should be clear in the header as well.
• At the bottom Print_Updates part, I'd however show each of these event on a separate line (only skipping past events if the same is currently happening as well), just below the update notifications. There, a full sentence can be shown, or a combination of the shorter warning that is shown in the header and an additional sentence about counter measures.

Regarding the wording and meaning of the events. It probably requires some testing, but AFAIK:

• "Throttled" is about temporary thermal throttling of the CPU frequency, hence when the defined temp_limit has been exceeded to a certain degree for a certain time. Not sure whether any temp_limit hit means immediate throttling, in which case the two notifications could be basically merged into one.
• "Capped" is about permanent CPU frequency capping, when the system is undervolted to a certain degree for a certain time. Similarly, I am not sure if any undervoltage event immediately causes the frequency to be reduced by an OPP state, so that those two event notifications could be similarly merged.