The PI monitor

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.

default-main

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.

pihat-env-thumb

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.

5 Likes

Very nice and wonderfully documented.

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.

Again, nice work.

2 Likes

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.

3 Likes