I may be wrong, but I've been interpreting the vcgencmd results a bit differently. As I understand it, the least-significant digit (bits 0-3) represents the current state, and the most-significant digit (bits 16-19) represents past occurrences, presumably since the last boot up. So, the code 0x50005 has bits 0,2,16, and 18 set, meaning
2: currently throttled
16: under-voltage has occurred
18: throttling has occurred
Similarly, 0x50000 means that there has been under-voltage and throttling in the past but not currently. The temperature seen by @TotallyInformation should not be a concern. Temperature throttling doesn't start until 80°C. The soft temperature limit (60°C by default and adjustable in software) was introduced in the Pi3B+ to give a more gradual approach to the hard limit.
I haven't had a chance to check all of my Pi's, but two 3B's that report throttled=0x0 have temperatures of 50.5°C and 48.9°C. I can report on two or three more machines if there is interest.
As Colin commented above, it would be good to role this up into a node, to provide the status in a 'easy to digest' format. I just wonder how many users are running node-RED on a Pi which is continually throttled....
Should I move this thread from the Lounge to general discussion?
Cool, nice spot - thanks. I thought it was a bit strange. <40°C seems like nothing. My Pi2 is running at 35.8°C. Of course, they are both running in a loft space right now so not surprising they are a lot cooler than many people's. Also, the Pi3 doesn't even have a case on it and the Pi2 has a case with no top.
Ah, thanks Garry, I'd forgotten about that. Actually, on the Pi3, it really isn't a problem. On the Pi2 which also runs InfluxDB - and actually with a lot more data going to it as it is my old live system, I see an occasional spike to 100% but generally it goes to about 30% every few seconds and about 50% every minute or so.
So not too bad despite running so much. Also, my InfluxDB instance on the Pi2 has quite a lot of historic data and that tends to increase the CPU spikes - presumably as it averages my detail data down to the hourly data I keep - that currently goes back to April 2016. How cool is that for such a tiny computer, 438MB of data.
Not a bad idea if you have time.
Yes, it would be an interesting question. As would - how many people are running Node-RED on a Pi?
Do you think this might fit into my node-red-contrib-cpu node, which can also be used currently to display the CPU temperature. If so, please be my guest to describe what could be added to this node to fit the needs ...
depends... I think this voltage thing is fairly Pi specific. If your node is already Pi only then yes... If not then maybe not so obvious. There are a load of other Pi vcgencmd commands that could be investigated (but hopefully not all exposed - let's stick to the basics please !) - see https://elinux.org/RPI_vcgencmd_usage
Seems indeed the vcgencmd is Raspberry specifc, and other devices with Broadcom VideoCore processors. So I agree we should put this stuff in a separate node. Read somewhere that vcgencmd stands for "VideoCore general command". Should we call it node-red-contrib-videocom?
How should the output look like: an array of booleans in the payload? E.g.
No. I doubt most pi users know what the command stands for, so would have no reason to recognise videocom as something relevant to them.
What's wrong with node-red-contrib-vcgencmd if it really does have to be a separate module... no harm including a pi specific node in your existing cpu module and only enabling it when running on a suitable platform.
I agree, for those who want it. Personally, I think it's more natural for a bunch of dashboard or debug nodes to display properties like msg.get_throttled.under_voltage_detected or msg.get_measure_temp.