Upgrading an old Tasmota and MUCH MORE

When it comes to upgrades, updating old IOT devices with the latest Tasmota can be quite a satisfying way to spend a Sunday. I was just tidying up my wiring in the office and noted a Tasmota’d Sonoff BASIC, so old it doesn’t even have an ID – check this out…

Not so much as an ID or version number. Back in 2019 I put the firmware Espurna on this unit – a project which seems to have now gone stale – though I notice you can define up to FIVE networks – I’ve never understood why Tasmota is limited to two. Let’s say Espurna has a few things going for it – but I prefer to stick with the actively developed Tasmota (Espurna last nightly built – 2022-06-13, Tasmota last nightly build half an hour ago). In both cases you are looking at local control of devices – no APPS needed and no far-eastern cloud dependency though it is easy with either a fixed external IP and a VPN to access this stuff from anywhere in the world. I’ve been using Tasmota for years now and it is so good that some time ago I ceased work on my own ESP8266 firmware (ESP-GO).

Enough history. I’m sitting in front of the board which is plugged into mains power. To start the ball rolling I checked out the free “Advanced IP Scanner” on my PC to look for any device added to the network that wasn’t there 5 minutes ago as I wasn’t entirely sure if this old board was running Espurna or Tasmota. Turns out it was the latter, so I COULD have found it with “Tasmota Device Manager”. AIS reported that the device was on internal address 192.168.1.159.

In the end, I simply punched http://192.168.1.159.lan into my browser – you might use a different suffix for local devices – I remember my old Vodaphone router back in the UK came set up to use .broadband – My router here is easily programmable and I set it to .lan as I’m lazy. I suppose I could have used .l to be REALLY lazy. The Sonoff BASIC appeared and normally I’d have gone to “Upgrade by webserver” to fit in the latest Tasmota.

In this case I had no idea what setup I had in the board and so I did two things – I first did the “Upgrade by Web server” you see above left using the standard URL within. After the board rebooted, I then selected an option I’ve never used before… so from the “main menu” – I chose “configuration” then “reset configuration”.

This completely reset the board configuration including WiFi as I quickly discovered, so off I went to my phone – set the WiFi to the “tasmota-xxxx” access point and in the phone browser went to 192.168.4.1 which is the default tasmota internal access point address.

I put in my “office” Wifi access point and left it at that. After the board rebooted, I could now access the device on my PC as normal – with no settings in there except access point.

I had no need to “configure module” as Tasmota assumes “Sonoff BASIC” by default. I went into “configure WiFi” and this time simply changed the hostname to “spare-old-sonoff”.

The NEXT thing I did after the reboot was to set up the MQTT credentials “Configure MQTT” so I could talk to the board by MQTT (in Node-Red) as well as this simple web interface.

The items I changed were “host”, “port”, “user”, “password” and “topic”. I left the rest as defaults.

At this point in the main menu I could hit “toggle” and hear the relay turn ON or OFF in the Sonoff unit. That left one more setting to change… in “configuration” “other” I set “device name” and “friendly name 1” to “spare-old-sonoff”. Had I gone on under “emulation” to pick the “Belkin Wemo single device” option, my Sonoff would now be seen by my Alexa Echo as “spare-old-sonoff” – but I left that out for now.

At this point from the main menu I often go into “console”. From there I entered a line with the word “time” (followed by ENTER). Now I could see that the device was an hour out. Entering another line from this site…

<a href="https://tasmotatimezone.com/">https://tasmotatimezone.com/</a>

Backlog Latitude 39.3260685; Longitude -4.8379791; TimeDST 0,0,3,1,1,120; TimeSTD 0,0,10,1,1,60; TimeZone 99

The time was now correct on the board. I could simply have entered:

timezone 99
or
tz 99

But this way I ended up with more useful info about my location in the device – all of this took a LOT less time to DO than write up in the blog.

I like purple more than the default colours in my Tasmota webUIs and this page lets you change colours.. I ended up pasting this into the console as above…

WebColor {"WebColor":["#eaeaea","#252525","#282531","#eaeaea","#282531","#d7ccff","#1d1b26","#ff5661","#008000","#faffff","#694fa8","#4d3e7f","#b73d5d","#822c43","#1f917c","#156353","#faffff","#716b7f","#eaeaea"]}

and the result – a pretty new webUI.

Nothing to do now other than to make use of my spiffed up ancient Sonoff BASIC board. And in these units kitted out with Tasmota as against the new BASICR4 units under eWeLink – the green light on the unit is an indicator that the output is on or off. It also conveniently flashes when you power up, turning off when the WiFi connection is made and when there is an MQTT issue – I only just realised that last one – I turned off the RPi for an experiment, so no MQTT and suddenly the Sonoff started to flash. I just wish they’d used an RGB LED there so you could easily distinguish WIFI or MQTT setup/issues. Were it me, I’d use RED for a relay ON and I’d flash to BLUE for MQTT issues and flash GREEN or YELLOW for WIFI set/issues.

One day later I noticed this in the Tasmota page SETOPTIONS:

You can abbreviate SETOPTIONS in the console to so – i.e. so31 0

There is FAR more to Tasmota than this. The default output setup returns the output to it’s previous state after power cycling – that can be changed in a “so” – you have full control of timers, rules and much more – I’ll get to rules in a minute – it’s been a good learning day.

So, using Tasmota, the differences between the old BASIC and the new BASICR4 – the latter can have MATTER integration. Tasmota on the BASICR4 does show up a qrcode to indicate that it is about to intergrate into Matter – something I’m still struggling with – but here’s the thing – the original BASIC, as it is ESP8266-based (not ESP32), does NOT show up the QRcode and hence cannot be intergrated into MATTER.

However, note that I have spare-old-sonoff in front of me and in node-red-contrib-googlehome I can turn it on and off – and of course I can also integrate the device into Alexa as an option in Tasmota so not all is lost.

I note that of course the old BASICs don’t have overheat sensing – so I looked inside the old unit – there’s a connector with gnd, tx, rx, 3v3 and IO2 (which is unused on the old BASIC but comes to a convenient marked PCB hole)…

So, I connected a spare Dallas DS18b20 to the PCB underside gnd, 3v3 and IO2 – no need for a pullup resistor if you go into “console” and enter the line “so74 1” – then go into the “configuration” “configure module” section and set GPIO2 to DSD18B20 – and the result – you now have temperature sensing…

Ok,initially I thought I had to actually monitor that temperature on the Raspberry Pi and choose when to have my Node-Red turn off the output – but that’s no big deal.

Here’s the view from the Tasmota webUI. It works – and just adds more flexibility to an old Sonoff BASIC.

I could of course have used an AM2301 and gotten the humidity out as well but I figured that was overkill. If you buy DS18B20s from AliExpress they’re quite cheap.

AND NOW – thanks to SFROMIS amd PKKRUSTY on Discord…

Overheat protection entirely on the old BASIC board

Set the Tasmota on the BASIC to GENERIC (18) rather than the default SONOFF BASIC (1)

In the Tasmota console:

switchmode1 3 (makes it act as a button)
Set gpio12 to relay 1, gpio13 to LEDi 1, GPIO2 to ds18b20, gpio0 to switch 1

rule1
on ds18b20#temperature>80 do backlog switchmode1 15; power1 0; var1 0 endon
on ds18b20#temperature<70 do backlog switchmode1 3; var1 1 endon
on power1#state=1 do backlog power1 %var1% endon

rule1 1
rule1 5

We did think about possibly adding power1 1 in the lower restore but dismissed it as the primary reason for this code (non-volatile) is for safety….

80 and 70 are arbitrary untested temperature values. I’ll use a small heater as the load soon to test. The board typically sits off-load at 45-55c in my office. We tested button on/off, MQTT on-off and the UI itself (which can be a tad slow to respond but works).

So now, my old Sonoff BASIC has temperature monitoring – and can be set to turn off the output (and stop responding to changes) at temperatures of over 80c (or whatever you substitute for my test values).

If nothing else this is great fun – and in the process, the guys on Discord helped me update my Grafana installation (see update in THE SCRIPT blog entry) – I decided for now I’ll have Grafana monitor this device – I’m using the standard regular TELE info out of Tasmota to feed my RPi4 MQTT input to then fire the current temperature of the old BASIC unit to Grafana – watch…

That’s it for the Sonoff – a diversion with a Wemos D1 board

While I was sitting in front of the computer with half an hour to spare, I grabbed an old Wemos D1 board which happened to have a handy resistive divider attached comprising a 1k to ground and GPIO17 (analog input) and a connector at one end of a 4k7 resistor, the other end of which was also attached to GPIO17. I thought it might be nice to monitor a 12v car battery with this and set about using CONFIGURATION – CONFIGURE MODULE to set the board to GENERIC (18) so I could then set GPIO17 to ADC INPUT – and then in console use the command in CONSOLE:

AdcParam 6, 0, 1023, 0, 1720

That last value 1720 sets the range and on a pair of batteries totalling 3.25v, I got value 325 out. Good but no prize – (the 1722 was found by trial and error to get the range correct for a value of 325 out appearing in the webUI). It did – but when I rebooted the board, that value reset to about half of that. I went onto the TASMOTA Discord forum where once again SFROMIS got me out of a mess. It is still not obviously documented (to me anyway) but instead of selecting ADC INPUT I should have selected ADC RANGE for GPIO17. I did – and it works perfectly.

https://tasmota.github.io/docs/ADC/#commands

If anyone wants to try this (any old ESP8266 board) you need a steady power supply and avoid putting significant loads on any outputs you may have defined. I put a purple LED on GPIO12 which I set to PWM output – and varying that output from off to full in the Tasmota webUI had minimal to no affect on the ADC value. At one point the value crept up from 325 to 327 but not repeatably – most likely a PSU issue.

Anyone trying this and getting a slightly different value (I used standard 5% resistors) just modify that 1720 value a tiny bit.

Why did I use such low value resistors? Well I originally planned to check car battery voltage in the car, not the cleanest electrical environment. Of course, having no WiFi in the car, I realised I’d have to set the Wemos to my phone’s WiFi HotSpot to try this out in a live environment. All very nice but I can’t see what suffix the phone hotspot uses for local devices -duhhh. HOWEVER, turning the hotspot on and having told my wemos to use that hotspot… the hotspot on Android, holding the phrase “mobile hotspot” on the phone shows devices and my WEMOS appears, holding that gives it’s address on the network… and I can go there in the browser – simple – just not as simple as storing wemos2.local for instant recall in the browser – but there you are.. just MORE uses for the venerable and dirt cheap ESP8266. Those Wemos boards are something like €1.50 – and 2 resistors… I used a €1.50 adaptor board on top which takes in 12v power…. On the analog input, the ESP8266 takes 0-14 for full range but the WemosD1 like other board has a divider on-board making that 3v3 full range so my divider will be just fine for measuring car battery voltage (15.5v full range or thereabouts).