An Exciting Shelly and Sonoff Friday

It’s Friday and I got up VERY early this morning and in this entry I have new devices from SHELLY – a pair of SHELLY MOTION devices (about which I’m quite excited) – and a not-so-new but handy Shelly RGBW PM Led Controller.. but I’ll get to these further down!

But first – Sonoff Zigbee

What’s new? Not new devices – but new uses… in the last blog entry I started to talk about my UK SMLight SLZB-06 ETHERNET Zigbee coordinator which I left functioning over there and I’m currently awaiting the same for here in Spain – expect a new article soon. As I have a pair of Sonoff Zigbee ZB-dongle-E USB devices and a ZB-dongle-P, I got out of bed first thing, eager to ponder what to do with these when the new Ethernet-based device turns up.

One option would be to sell them, another option: they can be converted to run as ROUTERS instead of COORDINATORS (if you’re new to Zigbee, it is natural to think of the COORDINATOR as a ROUTER and routers as REPEATERS but never mind – not my idea).

I’m not going to go into detail about how to flash these as ROUTERS – suffice it to say that using a Windows PC, the E dongle was DEAD EASY to flash as a router – the P-dongle not so… ultimately for the P-dongle – eventually I used this post and the embedded video which wasn’t that bad compared to others and in particular compared to Sonoff’s abysmal attempt to explain the process. In both cases the process is the same – just a different file for the firmware (be sure to get the ROUTER file, not the COORDINATOR file). That link above – for the P dongle – Python – no opening up / internal button pressing needed – the plan was for it to back up the original COORDINATOR code, flash the new ROUTER code and verify it – well, here I suffered – the backup procedure produced:

  File "C:\Users\pete\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.12_qbz5n2kfra8p0\LocalCache\local-packages\Python312\site-packages\serial\serialwin32.py", line 475, in exclusive
    raise ValueError('win32 only supports exclusive access (not: {})'.format(exclusive))
ValueError: win32 only supports exclusive access (not: False)

So that failed – but I kept going and the verify failed with:

Connecting to target...
CC1350 PG2.0 (7x7mm): 352KB Flash, 20KB SRAM, CCFG.BL_CONFIG at 0x00057FD8
Primary IEEE Address: 00:12:4B:00:24:C2:77:2B
    Performing mass erase
Erasing all main bank flash sectors
    Erase done
Writing 360448 bytes starting at address 0x00000000
Write 104 bytes at 0x00057F988
    Write done
Verifying by comparing CRC32 calculations.
    Verified (match: 0x9877ee56)
ERROR: int() can't convert non-string with explicit base

BUT HEY – the router code WORKS so I’m not worried – I put these backup and verify errors in here for your benefit.

I now have a SONOFF type E and a type P ROUTER. You’ll probably know if you use ZIGBEE that any mains powered ZIGBEE device is also, automatically, a router – and so extends the mesh.

GOOD – but your light bulbs and sockets might not be ideally placed for acting as repeaters (ROUTERS) – and so I ended up with the odd otherwise unused Zigbee smartplug acting merely as a router… because my main Sonoff COORDINATOR was (still is) on a Raspberry Pi 5 (USB) in the corner of my office – which in turn is in the far corner of the building. Not ideal. The new Ethernet coodinator will change all that as I can put it smack in the middle of the building – and these Sonoff devices (with aerials therefore presumably better than simple bulbs or sockets) can then be strategically placed to improve the upstairs and downstairs extremes of our solid-rock-based cavehome!! (as an aside I just improved WIFI upstairs by the use of a decent WiFi 6 router/access point downstairs – which worked a lot better than an attempt at using Powerline devices to extend the range).

And now – SHELLY!!

So this morning, a pair of SHELLYBlu MOTION smart motion detection devices arived along with their RGBW PM (Plus) device (12v or 24v) up to 240w capacity. This device is for non-smart LED strip(s).

I’m so glad I took that photo before opening the box – as I ended up shredding the lid – anyway, the device has power measurement – odd for a LED controller.

The device can control up to 4 different strips (light mode), a single LED strip (RGBW mode) and RGB strip (RGB mode).

No mention of my new favourite topic, using the setup Bluetooth for BLE beacon purposes (it is a powered device after all so why not) – but never mind.

I like this already – take a look at the device itself… the device will work in Shelly Cloud and of course locally and with Home Assistant – not tested that yet as I’m eager to get onto the motion sensors..

Shelly Blu Motion

I tried my best to show you the red light flashing on the motion device but failed. Out of the box the unit was flashing red on movement – which to me gives an indication of their confidence in the battery life. Oh, there’s a light (lux) sensor as well as the motion sensor – that’s good. AND yes it does (apparently) support BLE for broadcasts. There’s a button inside for setup and the device has it’s own web interface and works with the Shelly APP.

With Shelly devices, I’ve found I need to give them a fixed IP address to have them work with the Shelly integration for Home Assistant – but that’s easy enough. To install I put a screwdriver carefully into the slot indicated and removed the top half, there’s a button inside, I pressed it briefly and SHELLY BLU MOTION appeared in my device list in the APP. All went well until the final part – ADD device -“Please press device button” – again. Nothing happened for a worrying moment then the page popped up to let me change the device name if I wanted – fine.

And now I got the list of my devices with the “Shelly Blu Motion 1” showing as “pending connection”. First shocker “device is offline – ensure there are Shelly Bluetooth gateway devices around”. I’d been given the option to use one of my other Shelly devices as a BLE gateway but ignored it – bad move. It just so happens I have a Shelly Plus 1PM device so I backtracked. I plugged in my SHELLY PLUS 1PM which in the APP showed up as a BLE OBSERVER (you can use other shelly devices as gateways).. yet the motion sensor still showed up as pending for a few seconds then as I was writing this – it appeared properly (and detecting motion)… and with light value “78” whatever that means (lux?)…

Settings – update – well, you have to have the latest firmware don’t you 🙂 – so off with the back again as this required another button press. “Initializing update”… Not the fastest update so off I went for more coffee. Chat with my wife – coffee and… still initializing update… 10 minutes – 15 minutes – something wrong there surely?

I was about to give up – I had a dead Blu Motion but on emailing had a quick reply from Shelly – they pointed me to their shelly BLE debug APP but I needed more than that… so I created a support ticket and within minutes the support guys clarified that the Shelly BLE debug APP would get me out of a jam – it did – very quickly and I could run the other motion device and update it to the latest firmware.

Here’s an extract from their reply:

If the update hasn't been successfully completed, the device remains in bootloader state. 

You need to update it. 

To update your Shelly BLU Motion to the latest firmware version. 
You have to download Shelly BLU Debug App first from Google play or App Store. 

Then, follow these steps:
1) Remove the battery from the device
2) Hold the device's button
3) Insert the battery, without releasing the button for 2 seconds
4) Release the button 
5) Go to Shelly BLU debug app, link your smartphone with the Shelly BLU Motion  and click the OTA button

While I’m here – the battery is a monster – CR2477.

I need to do some long term testing of the MOTION devices but they also sent the Shelly RGBWPM (RGBW + Power Monitoring) device – and I’ve opened that up. I could of course have gone for the web interface – which is fine – but I was more interested in how it works in Home Assistant – my new fanatical interest.

Ok, so here’s the tile in HA with the RGB device – all I had to do was give it a fixed IP (I also turned on MQTT – not sure if that was essential – but I’m used to doing that for Tasmota)… you can hardly see the colour wheel here as I turned the brightness down – seems daft but there you go.

The actual RGB board is being fed 12vDC and I’ve a standard WS2812b roll or part of one attached – brilliance turned down just for the camera. The controls work perfectly and you have 3 options of how to use the RGBW channels… in HA, pretty much as I’d control other RGB lamps but this seems a bit more linear than usual.

It would have been nice if they could have squeezed another + connection for the strip – save me bodging the connection but then that’s common to many products – most ESP32 boards could do with far more grounds but that would make them bigger – you can’t win.

In case you are wondering – in the photo below that’s 12v not mains coming in…. OOH the power monitoring, how do I get to that? in HA I’m seeing entities for light, updating, 4 events and button – nothing about power monitoring…. over to Shelly for that….

Back to the Shelly APP… I’m seeing power consumption in the APP…1Wh – but then I do have it set to DIM… no power monitoring appearing in HA though – I guess that’ll be a firmware update needed – I’ve informed Shelly…