Tasmota and Autonomous Turn-off Thoughts
Right now I’m in the process of review writing some of which can’t be released until product launch dates – meantime – one of the main features of the free, open-source Tasmota device control firmware is it’s ability to control various devices and monitor various sensors internally without resorting to “the cloud” – or “someone else’s server” for the cynical.
Tasmota comes in rather handy if you don’t 100% trust your external provider Internet connection (something I’ve come to realise is very sensible here in rural Spain).
So while I like to use Google Home and Alexa, it has become blindingly obvious that they are both useless if you lose your external connection. Hence my home control is primarily internal (with VPN access for external control) – I do use the odd cloud-based device but mostly I use Node-Red on a (UPS-supported) Raspberry Pi to control Tasmota-driven devices and some Zigbee by using a Sonoff Zigbee dongle (was the ZBDongle-P – now upgraded to the ZBDongle-E) and Zigbee2MQTT on the RPi.
That all works well but yesterday I started to realise that one of my routers had failed – this router uniquely sits in a box in our pergola, powered by solar-charged batteries along with various external cameras and outside lights.
While it will always be the case that if the external Internet access fails, I’ll have no way to control lights etc. externally, this is the first time I’ve been unable to control them internally… and it occurred to me this morning that while I really need the extra power of Node-Red to control when and how various devices turn ON (and subsequently off), it would not hurt to use a Tasmota rule or timer to turn individual items OFF somewhat after the designated off time… for example – my lights generally come on at light-up time and off perhaps 11:30pm depending on the time of year – with some staying on or off when we’re on holiday – or on certain days etc… and I have manual overrides and groupings which start to stretch what Tasmota could do on it’s own.
HOWEVER, by adding a rule or timer to turn said devices OFF at, for example midnight, then even IF the WiFi went dead in my absense, at least I’d not end up with an extended electricity bill as Tasmota would completely locally ensure lights and other appliances were not left on un-necessarily – I’ve been known to be out of the house for weeks and it isn’t unheard-of to lose WiFi access internally though I’ve absolutely minimised the possibility by various means.
In this instance I failed at first to grasp that the pergola router had gone down because a solar battery issue meant the batteries died hours after turning on the external lighting but before lights out time. A few times recently we’ve returned home late from the pub to find external lights flashing on and off rather embarrasingly – only to now realise that the pergola power had died earlier before turning off the lights and as the batteries tried to recover – for a few seconds there would be power to IOT-controlled lights but not enough time for the external router to initialise and get the possibly missed once-a-minute-repeated OFF command from Node-Red back in the house.
This new (for me) local OFF override idea using a Tasmota timer will hopefully prevent such events happening in the future.
Solar Problems
I’ve been using these solar orange flicker-LEDs for some time now after initially purchasing the mains-powered versions (never had any issue with the latter)
You probably know the type I’m working on.. the bulb section can be over 20cm long and 10cm diameter
As you can see in the image above, I’ve opened this one up and carefully unsoldered the flexible PCB containing 96 LEDs,the circuit and showing the (in this case) standard 18650 battery and solar panel. I checked the battery – 4.2v – which means it has been sitting outside charging every day. I removed the on-off switch ages ago (and shorted out the wires) – they’re always a source of problems (damp, thin wires)…
After many months this lamp has simply stopped, it does not light up at all (two of them have done the same). Connections to the panel from the solar panel and battery could not be easier hence my confidence that the batteries and panels are both fine. I looked VERY carefully at the PCB, no obvious dry joints or dislodged components, no signs of burning.. I even checked the voltage on the PCB from both solar and battery – fine – the solar voltage being slightly higher than the battery voltage.
Not that long ago these lamps were €9 from AliExpress and stores like B&M in the UK. I was about to bin these two when I realised that Ali now want €20 each – whereas Amazon – well, lets not even go there.
Ultimately I gave up (I HATE being defeated) but if anyone has come across the same issue – feel free to comment. It is hard to fight the (admittedly OTT) idea of planned obsolescence with Chinese solar lights – they SHOULD be good for decades but never are. I have 3 larg stainless+glass solar lights purchased from the now-defunct MAPLIN store over a decade ago, these had stood the test of time – but at the some were on special offer at £6 each so likely twice that amount normally (sadly no longer available) but typical solar light life-times today are a fraction of that.
RPi5 WIN
I couldn’t really justify a full blown entry for each of these headings – but anyone upgrading from RPi4 32 bit Bullseye to RPi5 64 bit Bookworm, may, like me depend heavily on RPI-CLONE. I’ve talked about it a lot in here – meanwhile a pal of mine is busy convincing me that if I don’t keep up to date I could end up with dead code… so – my current home control was until yesterday (update April 15, 2024) RPi4 with MQTT, Node-Red, Zigbee2MQTT and SO much more – all put together on an even earlier Pi OS and earlier RPi, thanks to THE SCRIPT which you’ll see in the blog – with help from others I developed all of this – The Script and my home control setup over a very long time.
So my pal Antonio said I should consider – despite the work, upgrading to RPI5 with the latest Bookworm 64 bit OS – faster, better etc – and it IS faster. I bought an RPi5, loaded 64 bit Bookworm onto it and Antonio started to put together some DOCKER images for Node-Red, MQTT etc etc.. all GREAT – but for one thing. We did this on an SD and I put my usual SSD onto the RPi with a USB adaptor. We got the VERY basics up and running – then hit a BIG SNAG.
The original RPi-Clone no longer works on this new setup – RPi5 and the new Bookworm… worse – BillW who developed it hasn’t updated it for some time. I went off to two other repositories – guys who had started working on updates of rpi-clone. Their ISSUES sections were both CHOCK-FULL of comments – by the time I was finished I could not make head-nor-tail of which one if any worked – so I asked questions and ended up with this simple install:
https://raw.githubusercontent.com/geerlingguy/rpi-clone/master/install | sudo bash
All very nice but it would not work – I spent DAYS on it – conflicting comments about UUIDs possibly not matching and all sorts of potential issues – I was about to throw in the towel even with the install above – my SSD clone simply would not boot (dead- nothing but 2 solid lights) – when another fellow suggested it might help if I attached a monitor to the RPI5 (something I never do as I use Mobaxterm on the PC to access my RPis by SSH). I did the clone from SD to SSD, powered down the RPi5, removed the SD and powered back up with the monitor connected. Lo and behold – a message popped up on-screen – boot failure – your power supply isn’t powerful enough. I was using an official 4A 5V RPi supply – but the message insisted that with USB boot I need 5A – never seen that before. The same message also told me how to get around this by making a change to config.txt (SSD mounted on my PC)… a simple addition anywhere in that file – add this line:
usb_max_current_enable=1
With that, I put the SSD back onto the RPi5 and powered up – perfect. I tried the new version of rpi-clone again to create an SD from the SSD – no problem – even my old shortcuts I’ve referred to in the blog work perfectly.
Now that I can easily (one-liner) clone my work just as before – I can calmly get on with the task of ripping out and checking many thousands of lines of old code – but at least now I can do that safe in the knowledge that I can make backup clones at any time. I’m very happy.
Indeed, almost everything is now working on the new RPi5 setup in Docker including my old ESP-GO-based controllers (I developed that extensive ESP8266 firmware long before Tasmota appeared on the scene – it works well but the web interface leaves something to be desired and I can’t compete with the army of support that Tasmota attracts, so today the latter is my ESP8266/ESP32 firmware of choice).
I hope this helps someone else.
The post Tasmota Autonomous Auto-OFF, Solar Troubles and RPI5 WIN appeared first on Scargill’s Tech Blog.
