With help from the Tasmota forums and my Italian friend Antonio, I’ve learned some very useful stuff to share, in the last couple of days.
Automatic router Re-Booter using Tasmota and Sonoff BASIC or Similar
I have a 4G router which then feeds a normal router (we have no fibre option where we live but a good 4G+ signal). The 4G router is, say, 95% reliable… the main router higher reliability – but from time to time, usually when I’m away from home – something goes wrong and I can no longer access stuff at home. I WAS getting the odd mains breaker issue but it turned out that our 2-year-old hot water tank had an internal LEAK (very high calcium levels in the water) – I replaced the tank and I’m down to worst-case 6ma total house leakage. Problem solved.
For some time I’ve had Node-Red (on my 24-7 home control Raspberry Pi 4) pinging Google regularly – and if no response that would trigger a 4g router reboot via a Tasmota-driven Sonoff BASIC-type device – but clearly I was not getting everything right as while I was on holiday recently – I lost control of the house. My non-technical neighbour thankfully came over and checked – I had him power-cycle the mains – he did that but later assured me the breakers had been fine. It looks like the normal router providing DHCP had failed (that’s the end of Node-Red). The power cycle of course fixed all that.
SO I decided to start again – both routers on an extension controlled by a Tasmota device – I read somewhere about using a rule in Tasmota so that the device itself (instead of my RPi running Node-Red) – could do the Google checking. I followed the link – but could I hell understand it – however with help I now have a working rule on the power controller – I’ll share it here. The main thing was to ensure that the controller could operate all on it’s own even when its router was down.
In the Tasmota console of the Sonoff-Basic-type device I planned to use to cycle mains power to the routers – I entered this FIRST…
Rule1
ON system#boot do Var1 5 ENDON
ON Var1#State>1439 DO Var1 1439 ENDON
ON Time#Minute|%var1% DO backlog WebQuery http://google.com/ GET ENDON
ON WebQuery#Data$!Done DO backlog Mult1 3; TimedPower 10000,off ENDON
ON WebQuery#Data=Done DO Var1 5 ENDON
Then this line:
Backlog SwitchMode 11; SetOption32 10; Rule1 1;
Then I rebooted the device. Note that the command TIMEDPOWER has variants like TIMEDPOWER1, TIMEDPOWER2 etc… I found that out by trial and error as the command didn’t appear on the tasmota site (it probably will by the tiume you read this as I pointed out it was amiss
I don’t find Tasmota rules to be the easiest thing in the world – let me try to explain what the above rule does. Bearing in mind – we don’t want to wear out the relay on the controller by very frequent switching which could happen with a long outage – I need a Google check (can’t use PING as Tasmota standard builds don’t have that) starting at every 5 minutes and if the connection fails it will then power-cycle the mains and if that doesn’t fix it, it will try again in 15 minutes and so on up to once every every 24 hours, resetting back to 5 minutes after any/every successful connection to Google.
And that just works…. TimedPower is a relatively new Tasmota command which I mentioned in a previous post – I was recommended to use that rather than DELAY – and turning the router power off for 15 seconds then back on – just seemed about right to me. The rule starts with 5 second intervals for Google web queries. If the query fails, the interval is multiplied by 3 for next time – and power is turned off for 15 seconds and back on. If the query succeeds, the interval between checks is set back to 5 seconds.
So, that LOOKS like a solution to the problem of not-entirely-100%-reliable routers. Now been running for over 48 hours.
Giving speech Control to a Zigbee2MQTT-managed Zigbee Device
Separately, my friend Antonio and I had just finished getting the above to work when he came up with something I’d not thought of before:
So using Zigbee2MQTT with various Zigbee controllers is not usually ideal if you want voice control – and we were in the process of messing with Sonoff Basic-type controllers as above and he came out with “why not make use of unused GPIOS on a Sonoff-type controller (GPIOs which are not attached to anything) and use them as on-off devices -controllable by multi-pressing of the Sonoff-type device or by MQTT or Tasmota web interface or Alexa voice as normal, but instead of a simple switch, when using the control to switch the GPIO(s) which won’t do anything, use a rule to have that action send MQTT directly from the device to control another MQTT-compatible device, in this case a Zigbee2MQTT compatible device which normally doesn’t work with Alexa.”
Hence an on-off command to the non-functional GPIOs would end up having that device send an MQTT command to the Zigbee device sitting in the same network to control IT’S output. Remember that the Sonoff-lookalike is running on WiFi but given Zigbee2MQTT running in the same building (in my case on my main home control Raspberry Pi 4 via a cheap Sonoff Zigbee dongle attached to USB on the RPi) it becomes easy for the two networks to interact.
In this case – my Sonoff-basic-type device has power1, power2 and power3 – only the first one being actually connected to a relay – the other two connected to carefully-chosen GPIOs on that device – as it turns out this Sonoff-look-alike uses GPIO12 for the relay, GPIO5 for the button and GPIO1 for the LED – that leaves at least two useable GPIO outputs – maybe more – I chose GPIO13 and GPIO14. I called these outputs (under Tasmota Configuration – other) bash2 and bash3 (for no good reason) while ensuring the Tasmota setup was set to include emulation – Hue Bridge Multi-device.
The right Tasmota rules could make on-off and even brilliance/colour commands transfer to my Zigbee device (a lamp). So now I had a Zigbee device I could device I could control directly but also by ALEXA voice (sadly not Google) using a pair of outputs that don’t actually exist as well on the Sonoff-type device as the one that does – Tasmota rules and MQTT sorted that – I could now Alexa-control one of my cheap AliExpress Zigbee devices I’ve covered in a previous post … see code below…
rule1
on power2#state=1 do publish zigbee2mqtt/aliexpress-zigbee-3/set {“state”:”on”} endon
on power2#state=0 do publish zigbee2mqtt/aliexpress-zigbee-3/set {“state”:”off”} endon
rule1 1
The rule set above is somewhat simpler than the one further up in this article – the first 3 lines detail a rule called rule1 – the last line ensures the rule is running (including after power down-up). That’s it. The name of the Zigbee device is the friendly name I chose to give it. aliexpress-zigbee-3. something like bathroom-light would likely be more useful but these devices are new and still on test. Renaming is a simple matter in the Zigbee2MQTT control interface (by default at port 9099 on my Raspberry Pi). This info is simply entered into the Tasmota console.
Of course, none of this helps Alexa’s utterly hopeless speech recognition – I could not tell you how many device names I’ve tried over the years with Alexa, only to be told that “this song is available in the Amazon music store” or similar.
I hope this gave readers some ideas. For more on Tasmota look here. For more on Zigbee2MQTT look here.
The post A Tasmota/Zigbee2MQTT Learning Day appeared first on Scargill’s Tech Blog.
