I'm a big fan of the IoT/smart home products from Shelly and use a bunch of their WiFi switches around the house. Shelly has always been friendly to the maker community, equipping their products with useful things like programming headers to make it easy to flash alternative firmwares. And, indeed, I run the excellent Tasmota firmware on most of mine.
When I got into home automation the Tasmota firmware was, if not the only, certainly a tried and tested way of getting a Shelly WiFi relay talking to MQTT. It worked, and continues to work, a charm. So much so that I've flashed Tasmota onto every WiFi switch I have, immediately upon unboxing it.
If it works so great, what's the problem?
The native Shelly firmware has grown much more fully-featured. For example, now it supports MQTT natively.
Shelly has put a variety of over-temperature and over-current protections into their firmware. I might be able to recreate these protections in Tasmota but it's additional work.
While Shelly has its own IoT cloud, the devices support local control so the cloud features can simply be ignored.
Now I have Home Assistant at the heart of my IoT world I can use its integrations to connect to devices instead of doing it all homebrew.
I decided there are compelling reasons to run the stock firmware on Shellys. But I have Shellys with Tasmota. Surely it's a simple case of re-programming with the Shelly binary, right?
It wasn't as easy as I expected. There is a vast amount written on the Internet about programming third-party firmwares onto the Shelly, but precious little about reverting back to the factory firmware.
Finding the device
To download the firmware, first I needed the Shelly product code. This was easy enough to find using the Shelly support site's knowledgebase. I have Shelly 2.5 relays which identify as device model SHSW-25.
Finding the firmware
There is a firmware archive at archive.shelly-tools.de which offers the download, but it feels a bit third-party so I decided to try to find the firmware from Shelly directly. I failed to find an easy download link on their website but through judicious Googling I eventually found it available by manually forming the download URL:
https://api.shelly.cloud/firmware/SHSW-25.zipYou can probably change the device model on the end to get other versions.
Unpacking the firmware
The firmware ZIP containes not one single binary (like Tasmota has) but 4 separate .bin files and a manifest.json file that describes them.
esp_init_data_default_v08.bin
fs.bin
rboot.bin
switch25.bin
manifest.json
Hooking up the Shelly
I use a SparkFun Beefy 3 USB programmer from Pimoroni. It installs as a COM port under Windows using the FTDI drivers.
The Tasmota website has an excellent guide on how to hook the Shelly up for programming but connecting the Shelly is a bit tricky because the programming header is too small for regular Dupont wires. I connected it via a breadboard and used stripped off sections of Cat5 wire stuffed into the Shelly header. Unglamorous but it worked.
The yellow wire is +3.3V, with a connector in it so I can interrupt the power to reboot the Shelly. Also the Shelly needs the GPIO pin connected to ground on boot up in order to enter programming mode, this pin is exposed on the header as well so I just connected this on the breadboard.
Important: Never connect the Shelly to mains while the programming header is connected. Mains voltages are present on the header.
Programming the firmware
Because the Shelly firmware comes in multiple parts, it's not possible to use the convenient all-in-one programmers like the Tasmota web installer or the ESPHome programmer. I tried. It ended badly.
Instead I needed a programmer that can be told the offset in memory at which to program a given binary. I found the NodeMCU Flasher could do this.
The memory offsets are all defined in that manifest.json file. The relevant sections are the addr arameters:
"parts": {
"boot": {
"addr": 0,
"src": "rboot.bin",
},
"fs": {
"addr": 765952,
"src": "fs.bin",
},
"fw": {
"addr": 32768,
"src": "switch25.bin"
},
"sys_params": {
"addr": 2080768,
"src": "esp_init_data_default_v08.bin",
}Note the src filenames too.
Note: There are some other sections in the manifest that seem to be directives to clear out some blocks of memory, but I didn't do anything with these and so far, so good.
Armed with the offsets, now I configured the NodeMCU flasher with the 4 firmware files (converting the binary offsets in the manifest.json file to hexadecimal):
The settings I found that worked are:
NodeMCU Flasher selected the right COM port for me so it was then just a matter of hitting Flash on the Operation page. Programming was quite slow at 56k.
Results
Once the programming header was removed the Shelly booted up and presented its configuration WiFi hotspot. I connected my phone and navigated to the Shelly's configuration page at http://192.168.33.1/ to configure it with the WiFi credentials. The Shelly rebooted and popped up on the WiFi.
Presto! The Shelly seems completely happy running the latest official firmware:
That was quite a journey.
Комментарии