Remote checking Home Control Units

Those of you who are aware of the Home Control project (Home Control 2019) will know that the software/hardware combination of a Raspberry Pi (running Jessie, Node-Red, SQLite and Mosquitto) and ESP12 (running the software described in the Home Control project) is proving very reliable – but there are occasions when you may wish to be absolutely sure that units are actually doing something.  One way to do that is simply to put timeouts on every response you expect… but that makes for complicated coding. A simpler way is to regularly ask each unit for the status of one of the outputs. It doesn’t matter what the response is, as long as there is a response.

As it happens I’m having an issue right now – the heating controller part of my system back home in the UK is working perfectly except of an on-going issue with Plusnet broadband. They are denying it is their fault but the broadband fails perhaps once a day, maybe more, maybe once every two days but eventually it will fail. Most of the time the TP-Link TD-9980 router reconnects within a minute or so – but for reasons I don’t yet understand, occasionally it just will not reconnect. The solution to that was simple and two-fold, a standard timer which turns the router off for a minute in the early hours every day. That’s the “belt and braces” approach. In addition, the Raspberry Pi is polling Google every few minutes. If it fails totally over a 15 minute period to contact Google, an ESP8266 unit will reboot the router.

All of this worked perfectly for several days and then… the heating relay ESP8266 refused to log back in after one of these “cuts”. I can only put it down to being right on the edge of signal. The reason I say that is that late last year we had horrendous problems with WIFI here in Spain, some kind of attack. It went away but during that time over several days I was losing WIFI constantly so I made damned sure the ESP units would reliable log back in, in the event of temporary failure of MQTT or WIFI or both etc. And yet just occasionally this particular unit will not log back in – a power cycle fixes the problem but that means I need to know about it and ask someone to pull the plug for a moment.

So – I’ve implemented this for the two most important devices in the building – the main heating temperature sensor – and the ESP that controls the relay to turn the heating on and off.

What you see above is as follows: 2 Node-Red “inject” nodes (standard) fire out requests every 5 minutes to MQTT to ask the relay and temperature units for the state of output 0.

Which command is irrelevant as long as it is a query which returns a result and otherwise has no effect on anything.  So for example with a topic holly1/toesp and a payload of {out0?} the system is expecting a response of OFF or ON (irrelevant here) from topic holly1/fromesp/out0

The two incoming MQTT nodes (left, purple) pick up on the response and feed them into my “timeout” nodes  (node-red-contrib-timeout).

As you’ll see below, the operation is simple – the timeout node doesn’t care what is incoming as long as something is. if it gets nothing for 60 minutes it will time out and send a payload out – in this case thanks to the standard email node (green) an email to me.

During that time, normally, the MQTT nodes would have responded every 5 minutes – ie 20 times, topping the timeout node up to 3600 seconds even if most of the messages were missing (and there is no reason why any should be missing).  In this case I’ve not put messages for “safe state” or “warning” – so nothing goes out unless the timeout actually runs down to zero.

Click on any of these images for larger versions.

So while this does not solve the problem, it does mean that I’m alerted to the issue and can ask someone to disconnect and reconnect the relay unit. With what has been 100% reliability of Raspberry Pi 2 boards (with a decent Samsung microSD or similar) I can be pretty sure I’ll get an email if something goes wrong.

I hope this proves useful to others.