I guess this is more made for makers, though is is also made by a maker, it gets recursive.
It’s also software, not hardware.
Something I wrote last year as a Python learning exercise; OverWatch is intended to be run on headless computers doing thankless jobs in difficult circumstances:
Eg. A lot of Pi’s being used as octoprint servers and SBC’s etc.
It can collect a whole bunch of data, not just the default set above, but also ping times to target machines in the network, and GPIO pin states. If you add a BME280 environment sensor it will record that too. It even supports displaying stuff on a I2C OLED display, and has a nice tight web interface that can be customised and embedded via url modifiers.
Readings occur every 10s by default and all the data is saved in a time-domain database, you can then graph that data through the web UI.
Care is taken to minimise disk writes (once every five minutes) and it is remarkably low-impact on the host system, I barely notice it on my Pi3, Running with the animated OLED display does chomp at the CPU, but not unreasonably. I run 2xOctoprint, 2xWebcam and a HostAP off this machine, with no problems.
It’s primary purpose is to run in the background and assist debugging problems in real time, it is designed to complement, not replace, services such as Munin.
Finally; it can has pushbutton + web-control for a GPIO pin; I use this to turn the workbench lamp on/off and it’s handy with the webcams.
A feature which might be handy is to periodically watch for undervoltage situations and display them in an appropriate color. Even on the rPi3B+ I ran into issues with USB cabling with too thin wire and also 2A USB power supplies which did not put out 2A.
UUrgh; dont get me started on the subject of Pi Undervolts…
From a perspective of my code they are actually quite hard to detect, the ones that bedevil people and crap out your wifi are very transient, a few ms. But the overwatch spends 99% of it’s time asleep, so it would need to use system flags, which you cannot (easily) clear without a reboot. I looked to see if I could somehow get an interrupt for these events but it’s a kernel thing, I wont go there.
The overwatch architecture is designed to make adding new senses quite easy, and I thought about this quite hard at the time and eventually made a decision not to try and detect throttling events.
overheating would be easier to do since it is generally more prolonged. But the temperature graph will show you this too, in better detail.
testing would also be a problem, my machines do not suffer from this
overwatch is designed to be somewhat architecture neutral, and I avoided adding pi-centric code. CircuitPython is used for the GPIO stuff, and that is a framework that extends beyond the Pi ecosystem.
So; A deliberate omission. I know it’s a weakness but I’ve decided to make like the Pi Forums and simply stand round telling the world+dog that it’s all the fault of their PSU and my code is perfect… and nothing to do with a hair-trigger undervolt detector sitting at the wrong end of a re-purposed high speed data connector with dirt attracting tiny contacts connected via cheap copper wires and tracks.