This is a follow-on article from my blog Home Control 2019 which concerns itself with IOT around the home – you might want to read that first. Scheduler is now defunct, replaced by node-red-contrib-bigtimer.
Many articles on DIY home control tend to scratch the surface and you don’t find out about reliability issues until you’ve wasted many hours building stuff just to discover that the authors never really got into real world subjects like “what happens if the router power-cyles”.
I’ve been working on this stuff for some time now along with my friend Aidan and having installed boards around the place I’m now getting into the “nitty gritty” of reliability.
So for example, take my system here at Bedrock (so called because it is actually a real cave in the mountains of Andalusia). I have a Pergola – which has a 12v power system and an ESP8266-based relay board to turn the lights on and off. I also have flood lights around the place and an internal light which are controlled by another board. Finally I have a watering system which fires off twice a day for a few minutes.
My system as you’ll know from the main home control article is based on a Raspberry Pi2 running MQTT and Node-Red talking to ESP-8266 “Hackitt & Bodgitt” boards and of course my own software.
I have a little uninterruptable on the Pi and that has tests for WIFI and MQTT failing and almost no matter what happens, the system stays up.
After 12 days of perfect operation while I was over in Boston with Espressif, last night the WIFI went off. I had no idea what it was so I power-cycled the router. Still nothing. We sat around for a while and the WIFI came back up – clearly some issue with the service provider.
I noted that it had just turned to DUSK and yet no lights.
And then it twigged. My Node-Red node I wrote a long time ago called scheduler, sends MQTT messages out at dusk and other times to control the lighting… but of course if the WIFI is not connecting at the time, the opportunity is missed.
Now you could use a number of tricks, the various modes of MQTT include a mode to always get the message through. However I can see issues with that and so last night I did an update to my scheduler.
Instead of sending out commands to turn lights on and off at specific times – like dusk and dawn – I’ve added a checkbox to send the instructions out every minute as to the state that is expected. This is entirely optional, controlled by a tickbox. But this way, if a message for whatever reason is missed – it will be sent regularly and the recipient units can then be assured of catching up.
The scheduler which requires Node-Red is no longer maintained and is superceded by node-red-contrib-bigtimer. It was probably the most comprehensive timing mechanism available for Node-Red until I replaced it with node-red-contrib-bigtimer.
Peter
Have you tried using the Retain flag in the mqtt message?. If the server is up and the esp restarts it should pull in the last message on the topic.
Tony
Good suggestion, this will work as long as the message encapsulates all of the information which is necessary for the board to pick up the correct state.
e.g. wouldn’t work if multiple control messages are sent out individually on the same topic, msg 1 = turn on gadget x, msg 2 = turn off gadget y (the retain would hold msg 2 but discard msg1)
But if one message were sent out capturing all of the desired state i.e. msg 1 = turn on gadget x, turn off gadget y then the retain would work.
Andy.
The other thing to use is the Last Will & Testament function. I use this on my IoTBox (blog.Spants.com).
I have set it so my esp sends an online message to the LWT topic when it powers up and then sets up LWT to automatically send offline when mqtt loses communication with the esp. That way you can see that comms are lost (and restored) rather than blindly sending messages. LWT is supported by Tuanpm’s mqtt client and is very easy to use.
Tony