Networking multiple Mycodo daemons

[kizniche]

Monitoring is key to any good regulatory system, with redundancy often used to accomplish this. This may be useful for remote operation or where great liability is involved (e.g. keeping things alive, preventing damage of expensive materials, ensuring safety, etc.).

The main use of networking would be to add the ability to monitor the status of a running Mycodo daemon on another device and to respond if there is an issue (e.g. daemon crash, linux kernel panic, corrupt filesystem causing instability, disconnect from the network, loss of regulation, etc.).

Initial features would be the ability to notify by email, power cycle the affected Pi with the use of a normally-closed (NC) relay, or take control of the regulation relays to recover the system from a loss of regulation. Additionally, If the host (monitoring system) experiences an issue, the slave (monitored system) could power-cycle the host.

A point-to-point connection would provide the best security, such as a single ethernet cable (TCP/IP) or serial (Tx/Rx). With a dedicated connection, there are fewer additional points of failure (such as routers, switches, and wireless APs, although these could still be used).

If successful, this feature could potentially lead to more advanced features such as improving graph generation performance or other processes by splitting processing tasks (cluster).

[kizniche]

This feature may be unnecessary (except if there's a kernel panic or other critical Pi failure)... http://linux.die.net/man/8/watchdog http://blog.ricardoarturocabral.com/2013/01/auto-reboot-hung-raspberry-pi-using-on.html

[zsole2]

Kyle,

Checking back again... after a long time. This is a testament to the stability you have achieved with the project, no need to worry, it just works! Congrats, again! Networking gets more interesting these days, at least for me. With the availability of Pi Zero, my setup could be easily decentralized: cheese refrigerators with their own Zeros, no need to be bunched into a single space around the Pi, generating cumulative noise and heat. In fact, the cost of the Pi Zero could be less than the necessary aux materials needed to connect the relays and sensors to the central Pi. I see that your development goes into the other direction, rather adding more and more sensors with the multiplexers to the same Pi. But networking could come in handy with respect to performance, for example. Other than clustering you mentioned, the slave system could only collect and store the data, and the host processes everything, generates graphs, etc. If the host is on my laptop, there is no worry about the processing power of the Pi, it can be done offline, after collecting the data from the slave (and instructing the daemon if changes in parameters are necessary). It is also good for archiving data on the host, and not be at risk of corrupted SD cards in the Pi.

I don't want to be long here, just a few thoughts on further possibilities in this directions, if you are out of ideas on improvement (which is obviously not the case).

Zsolt

[kizniche]

I'd like to add a host/slave functionality in the future. A mode that can be optionally set for each Pi (normal, host, or slave), which if not set to normal would involve setting the slave IP on the host and the host IP on the slave, and probably also a password. Right now we're going through a huge code restructuring, which should make future development much easier.