More Zigbee Learning (or not)

Peter ScargillGeneral9 Comments on More Zigbee Learning (or not)
Zigbee

Elsewhere I’ve just started to write about Zigbee – the low-energy RF communication alternative to WiFi and 433Mhz radio control of various smart devices.

To make a start, I’m using my normal Raspberry Pi arrangement with the addition of a small pre-programmed dongle from Itead which works with the widely available zigbee2mqtt software on the RPi.

Initially I used the Node-Red MQTT nodes directly and debug nodes for monitoring. I’m heading towards using node-red-contrib-zigbee2mqtt – but before I get into that, here’s an issue that’s bugging me right now…

Given a simple setup with the Sonoff pre-programmed Zigbee dongle, a Sonoff Zigbee DIY Smart Socket and a ZemiSmart Zigbee Smart Socket, I succeeded in quickly using Node-Red on the Raspberry Pi to control both sockets and two connected Zemismart E27 RGBW lamps as well as monitoring the state change of the lamps and both sockets as Node-Red turned them on and off.

Where I’m currently having issues is seeing, in Node-Red, the status changes when turning the Zemismart socket on and off manually or physically cycling mains power to it. The Sonoff status information works just fine, but not, it seems the Zemismart status nor does power cycling of the Zemismart light units provide any status information back to MQTT.

Zigbee

Note the devices by number information in the image below – not yet quite as friendly as Tasmota WiFi devices. You see the Sonoff socket followed by the Zemismart socket. The bottom two devices are lights and of course you can create friendly names for these devices.

Update June 19, 2020

After a reasonable start, things went downhill rapidly with those Zemismart E27 Zigbee lamps. To move them from one repeater to another setup, you are supposed to turn them off and on 5 times in a row – at which point they start flashing – except when they don’t. I’ve just wasted 2 hours (one light at a time) flicking them off then on – I’ve tried all combinations – 5 times, quickly, slowly – makes no difference – no flashing, no change whatsoever. I now have 2 expensive bright blue lights.

My Sonoff and Zemismart Zigbee smart sockets are however working fine along with my Ikea £8 repeater.

9 thoughts on “More Zigbee Learning (or not)”

  1. Hi, I might have missed your reasoning on why switching to Zigbee now.
    I will soon have to make the decision for my own home. I am wondering if using wifi for every smart sockets and other IoT isn’t going to overcrowd the wifi bandwidth. I wouldn’t want to decrease the quality of the signal for computers and other high bandwidth needs.
    Is this the reason you are getting interested in Zigbees?

    1. Hi

      I’m not switching to Zigbee – I’m testing Zigbee in case it is useful for outdoor or awkward positions where sensors must be battery powered. For indoors I’m more than happy with WiFi.
      Depending on the position of the Zigbee gateway it could make sense to have a mains powered Zigbee REPEATER which might also act as a switch or socket, hence the interest in that.

      As an example, door sensors are often not attached to power and I’ve been experimenting with 433Mhz and Zigbee sensors.

      Regards

      Pete

      1. Ok, so it’s mainly for its low-power advantage. Nice.
        Thank you for your response.
        (And thank you for your blog, tweets and videos btw. I’m been one of these millions of silent followers you certainly have for years 😉 )

      2. WiFi battery operated devices tends to exhaust battery soon, or tends to react slower as the connection to the router and getting an IP address with DHCP costs time.
        On the other hand Zigbee uses less battery and wakes up faster, it means faster reaction time with door contacts and buttons with battery for example. Although Zigbee uses the same 2.4Ghz band as WiFi, so in congested environment i think that 868Mhz mesh Z-Wave is the winner at the end. 🙂 I am also happy with WiFi if mains is available.

  2. Or you could just add a friendly name in the zigbee2mqtt yaml file for each device, Tasmota wants to call every device tasmota which is even less friendly

    1. tasmota wants nothing, you can go in its web gui and rename them as you want, then (in case of home assistant) remove the device from HA, go in tasmota console and issue again: “SO19 1” to have them back with proper names 🙂

      1. My point was that there is a way to change the unfriendly name in zigbee2mqtt. Tasmota also gives devices unfriendly names that you can change

Comments are closed.