Testing popular ZigBee devices (and coordinators)

Hardware Home Automation
1

First zigbee device arrived. Stick is in a USB3 port of a Pi4 direct with no extension cable. ncp-uart-sw_679_115200 firmware

Device is a Gledopto bulb. I bought this on the basis of reviews showing general compatibly with other hubs. Cheaper than a hue. Will try Ikea next.

Included at first try with device and controller 6m apart so not long range.

2021-04-22 14:16:16.141 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 60A423FFFE023BC6: Starting ZigBee device discovery

2021-04-22 14:16:16.142 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 60A423FFFE023BC6: Creating ZigBee device zigbee:device with bridge zigbee:coordinator_ember:0963bb1626

2021-04-22 14:16:16.148 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 60A423FFFE023BC6: ZigBee node property discovery start

2021-04-22 14:16:16.152 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 60A423FFFE023BC6: ZigBee node property discovery using basic cluster on endpoint 9D7E/11

2021-04-22 14:16:16.363 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 60A423FFFE023BC6: Node doesn't support OTA cluster

2021-04-22 14:16:16.365 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 60A423FFFE023BC6: ZigBee node property discovery complete: {zigbee_logicaltype=ROUTER, zigbee_powerlevel=FULL, zigbee_manufacturercode=0x1002, modelId=GL-B-008P, zigbee_networkaddress=40318, zigbee_powersource=MAINS, zigbee_stkversion=0, zigbee_datecode=, zigbee_zclversion=3, vendor=GLEDOPTO, zigbee_powermode=RECEIVER_ON_IDLE, zigbee_powersources=[MAINS], hardwareVersion=0, zigbee_applicationVersion=0}

2021-04-22 14:16:16.368 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 60A423FFFE023BC6: Checking endpoint 242 channels

2021-04-22 14:16:16.379 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 60A423FFFE023BC6: Checking endpoint 11 channels

2021-04-22 14:16:16.439 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - 60A423FFFE023BC6: ZigBee saving network state complete.

2021-04-22 14:16:17.263 [DEBUG] [er.ZigBeeChannelConverterFactoryImpl] - 60A423FFFE023BC6: Removing channel zigbee:switch_onoff in favor of zigbee:switch_level

2021-04-22 14:16:17.264 [DEBUG] [er.ZigBeeChannelConverterFactoryImpl] - 60A423FFFE023BC6: Removing channel zigbee:switch_level in favor of zigbee:color_color

2021-04-22 14:16:17.266 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 60A423FFFE023BC6: Initializing channel zigbee:device:0963bb1626:60a423fffe023bc6:60A423FFFE023BC6_11_colortemperature with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterColorTemperature@126793e

2021-04-22 14:16:17.641 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 60A423FFFE023BC6: Initializing channel zigbee:device:0963bb1626:60a423fffe023bc6:60A423FFFE023BC6_11_color with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterColorColor@1724b96

2021-04-22 14:16:17.646 [DEBUG] [.converter.ZigBeeConverterColorColor] - 60A423FFFE023BC6: Device supports Hue/Saturation color set of commands

2021-04-22 14:16:18.648 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 60A423FFFE023BC6: Update ZigBee device zigbee:device with bridge zigbee:coordinator_ember:0963bb1626, label 'GLEDOPTO GL-B-008P'

2021-04-22 14:16:18.938 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - 60A423FFFE023BC6: ZigBee saving network state complete.

Happy to test other type of device if anyone has any recommendations of good ZigBee devices of any type.

2

Aqara devices are fine in terms of hardware and very cheap so everybody wants to use them hence good candidates.

@chris you mentioned you did zigbee heating for a hotel chain.
Did you use any thermostats (TRVs) there that you can recommend ?
(I myself have been trying with the Tuya TRVs but have been failing so far)

3

Is it this one? https://www.amazon.co.uk/Viesky-Zigbee3-0-Thermostat-Thermostatic-Radiator/dp/B08SK1K1MW/ref=sr_1_7?adgrpid=104673512813&dchild=1&gclid=Cj0KCQjwvYSEBhDjARIsAJMn0li-5_3P7NWIsOCuUNYS6lD8xdTtkP5-bvRuWaBw86II7bYjWBjHPMcaAhUwEALw_wcB&hvadid=450678687243&hvdev=c&hvlocphy=9045641&hvnetw=g&hvqmt=e&hvrand=3841008940497625067&hvtargid=kwd-966935172877&hydadcr=18213_1724307&keywords=tuya+trv&qid=1619106730&sr=8-7

Q&A:
1. Q: Can I use my own hub to connect with the -valve?
A: No,this radiator thermostat can only be used with our Tuya ZigBee wireless gateway hub. We also offer the set of the hub for your choosing.

Who knows if that is correct.

4

yes (albeit who knows how many variants there are)
According to this it should do: Shojzj Thermostatic Radiator Valve Controller 378RT Zigbee compatibility
With PAN ID thing resolved Iā€™d give it another try, but for now Iā€™m failing to reset it.
Thereā€™s some YT tutorial that used to work once or twice for me but now no longer does.

5

I have the weather, illumination and window magnet and use the latter for most tests.
It works in principle but it keeps dropping offline after 31 minutes.
See last 4 lines below: the 86430 is what Iā€™ve set (1 day) as ā€˜Maximum Reporting Periodā€™ on the channel plus 30 secs added by the system. But I donā€™t find the setting for the other timeout (1800).
Any idea on that ?

Also I see several settings such as the Reporting Period or the ā€˜initialize deviceā€™ button twice in UI.
EDIT: That now seems to be gone after a OH restart so letā€™s see if that makes the difference.

PS if you feel we are getting off-topic let me know and Iā€™ll split the thread.

2021-04-22 18:44:00.667 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D00025816C2: Channel zigbee:device:sonoff:00158d00025816c2:00158D00025816C2_1_switch updated to ON
2021-04-22 18:44:00.668 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D00025816C2: Channel zigbee:device:sonoff:00158d00025816c2:00158D00025816C2_1_switch updated to ON
2021-04-22 18:44:00.668 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00025816C2: Updating ZigBee channel state zigbee:device:sonoff:00158d00025816c2:00158D00025816C2_1_switch to ON
2021-04-22 18:44:00.669 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00025816C2: Updating ZigBee channel state zigbee:device:sonoff:00158d00025816c2:00158D00025816C2_1_switch to ON
2021-04-22 18:44:00.670 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ZigBeeThingHandler of thing zigbee:device:sonoff:00158d00025816c2 tried updating channel 00158D00025816C2_1_switch although the handler was already disposed.
2021-04-22 18:44:00.672 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:sonoff:00158d00025816c2
2021-04-22 18:44:00.673 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker cancelled task for thingUID=zigbee:device:sonoff:00158d00025816c2
2021-04-22 18:44:00.674 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:sonoff:00158d00025816c2 in 86430 seconds
2021-04-22 18:44:00.677 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:sonoff:00158d00025816c2
2021-04-22 18:44:00.678 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:sonoff:00158d00025816c2 in 1830 seconds
2021-04-22 18:44:00.976 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D00025816C2: Channel zigbee:device:sonoff:00158d00025816c2:00158D00025816C2_1_switch updated to OFF
2021-04-22 18:44:00.977 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00025816C2: Updating ZigBee channel state zigbee:device:sonoff:00158d00025816c2:00158D00025816C2_1_switch to OFF
2021-04-22 18:44:00.978 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D00025816C2: Channel zigbee:device:sonoff:00158d00025816c2:00158D00025816C2_1_switch updated to OFF
2021-04-22 18:44:00.978 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:sonoff:00158d00025816c2
2021-04-22 18:44:00.979 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00025816C2: Updating ZigBee channel state zigbee:device:sonoff:00158d00025816c2:00158D00025816C2_1_switch to OFF
2021-04-22 18:44:00.979 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker cancelled task for thingUID=zigbee:device:sonoff:00158d00025816c2
2021-04-22 18:44:00.981 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ZigBeeThingHandler of thing zigbee:device:sonoff:00158d00025816c2 tried updating channel 00158D00025816C2_1_switch although the handler was already disposed.
2021-04-22 18:44:00.982 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:sonoff:00158d00025816c2 in 86430 seconds
2021-04-22 18:44:00.984 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:sonoff:00158d00025816c2
2021-04-22 18:44:00.985 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker cancelled task for thingUID=zigbee:device:sonoff:00158d00025816c2
2021-04-22 18:44:00.986 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:sonoff:00158d00025816c2 in 1830 seconds
6

Many thanks for the advice on devices. Will report back when I get the Aqara devices.

Possibly a new thread ā€œTesting the ITead 3.0 USB Dongleā€ may prevent this thread becoming too long.

7

This is offtopic in this thread, but anyways (edit: well after mstormi splited the thread not so offtopic);
I have three Lumi/Aqara devices I got working after much pain.
They are terrible to include. Two of them shows in UI as offline (but are working).
And all have nonstandard ways to report battery status, so that is not seen in OH.
I will not buy more of them (as long as they are not zigbee certified).
People can do whatever they want, I simply can not recomend them.

8

oops a bad investment :rofl:

This is one of the reasons that Chrisā€™s z-wave database has so much potential and would be nice for zigbee. We could rate the ones that work well and those that do not work so well with openHAB.

9

Any luck with ITead?

10

You want things both ways!!

In another thread you said the database was a liability and @chris explained he wrote the Zigbee binding to work without one due to OH changes. OH definitely does not have a reliable method for updating bindings containing databases.

If you think things could change, please submit a PR.

11

I really like the Philips Hue devices.
They are priced at premium, but you get what you pay for.
I must add that the coordinator and its firmware is important.
The newest certified zigbee v3.x devices (not only Hue) simply demand a up to date coordinator.

I look for ā€œzigbee certifiedā€ when I buy something.
It lokks like it is more than enough devices that are troublesome under that flag too.

12

Iā€™m a bit undecided about the LUMI/Aqara weather sensor. I think it does not update at times (and in time so it doesnā€™t get marked as offline).
It does not show anything under ā€˜Channel detailsā€™ (just the title string ā€˜Configurationā€™ then blank for the Temperature channel and not even the title for the other 2).
So practically I cannot change anything not even the min-max polling times !?
Overall, Iā€™m missing many of the possibilities I have in zwave such as thresholds when to report, calibration and the like. Is it ZigBee in general or these particular cheap sensors that there are no parameters to tune ? Or is it a bug or lack of implementation ?

13

I certainly did not.

1 Like
14

They didnā€™t use any thermostats (well - TRVs). They just had the control element not the bit that goes on the radiator (which I think is what you mean by TRV?).

The Hilton system used 3 different thermostats, but I forget what they were now and they are currently still en-route from the UK to NZ.

1 Like
15

But why do you want to mess with this sort of thing??? The binding does this for you - sit back and relax :slight_smile:

ZigBee has a standard way to do this sort of thing which is (IMHO) a lot better than Z-Wave. However much of the reporting is hard coded in the binding rather than being available. So for example IIRC temperatures will automatically report if they change by 0.1 deg. Some are probably configurable, but most arenā€™t at the moment.

1 Like
16

Iā€™d love to however the reason I was looking for that is this Aqara weather sensor dropping offline.

It did again tonight after 3,5hrs (no sensor reports during these).
Log shows polling attempts after it went offline but just for one of its 3 channels and no other messages.
Dis+enabling the thing makes it return online but still not sending reports. This is all of that sensor from events.log (note the strange ā€˜firmwareā€™ message)

2021-04-23 10:02:41.091 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:sonoff:00158d00067c0e16' changed from OFFLINE to UNINITIALIZED
2021-04-23 10:02:41.126 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:sonoff:00158d00067c0e16' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2021-04-23 10:02:47.628 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:sonoff:00158d00067c0e16' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2021-04-23 10:02:47.654 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:sonoff:00158d00067c0e16' changed from INITIALIZING to UNKNOWN
2021-04-23 10:02:47.670 [INFO ] [penhab.event.FirmwareStatusInfoEvent] - Firmware status of thing zigbee:device:sonoff:00158d00067c0e16 changed to UNKNOWN.
2021-04-23 10:03:35.633 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:sonoff:00158d00067c0e16' changed from UNKNOWN to ONLINE

Dis+Enabling also showed this:

2021-04-23 10:02:47.691 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: 2021-04-23 10:02:47.649 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Initializing ZigBee thing handler zigbee:device:sonoff:00158d00067c0e16
2021-04-23 10:02:47.653 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Coordinator status changed to ONLINE.
2021-04-23 10:02:47.655 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Coordinator is ONLINE. Starting device initialisation.
2021-04-23 10:02:47.667 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Start initialising ZigBee Thing handler
2021-04-23 10:02:47.670 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: ZigBee node property discovery start
2021-04-23 10:02:47.673 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: ZigBee node property discovery using basic cluster on endpoint 2EEE/1
2021-04-23 10:02:47.675 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: Node doesn't support OTA cluster
2021-04-23 10:02:47.677 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: ZigBee node property discovery complete: {zigbee_logicaltype=END_DEVICE, zigbee_powerlevel=FULL, zigbee_manufacturercode=0x1037, modelId=lumi.weather, zigbee_networkaddress=12014, zigbee_powersource=DISPOSABLE_BATTERY, zigbee_stkversion=2, zigbee_datecode=20191205, zigbee_zclversion=1, zigbee_routes=[], zigbee_lastupdate=, zigbee_stkcompliance=0, vendor=LUMI, zigbee_powermode=RECEIVER_ON_IDLE, zigbee_powersources=[DISPOSABLE_BATTERY], hardwareVersion=30, zigbee_neighbors=[], zigbee_applicationVersion=5, zigbee_device_initialised=true, zigbee_devices=[]}
2021-04-23 10:02:47.679 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Checking endpoint 1 channels
2021-04-23 10:02:47.689 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Dynamically created 3 channels
2021-04-23 10:02:47.691 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Device initialization will be skipped as the device is already initialized

and shortly thereafter

2021-04-23 10:03:26.029 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Channel initialisation complete
2021-04-23 10:03:26.031 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Thing is RFD, using long poll period of 1800sec
2021-04-23 10:03:26.032 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Setting ONLINE/OFFLINE timeout interval to: 14430
2021-04-23 10:03:26.033 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker added for thingUID=zigbee:device:sonoff:00158d00067c0e16
2021-04-23 10:03:26.034 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:sonoff:00158d00067c0e16
2021-04-23 10:03:26.035 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:sonoff:00158d00067c0e16 in 14430 seconds
2021-04-23 10:03:35.628 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Error getting binding table
2021-04-23 10:03:35.630 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Polling initialised at 1924809ms
2021-04-23 10:03:35.632 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Done initialising ZigBee Thing handler

Iā€™ll reset that thing. Letā€™s see if that makes a difference.

(EDIT: just did.
Now the ā€˜Configurationā€™ headline in channel details is gone. That without any frame below to enter anything had looked like a bug. But question remains, is there really no parameters to tune ?
Given (see below) the illumination sensor does feature thresholds, Iā€™d suspect the weather sensor does, too. But OH does not show anything.

Meanwhile with another (illumination) sensor I have the problem that itā€™s reporting too often, battery drain is foreseeable.
That one has ā€˜minimum reporting periodā€™ and a ā€˜Report On Chargeā€™ threshold but setting those does not have any impact, it seems to keep reporting every change .

17

Iā€™m not sure I understand how changing the reporting period will change anything?

Often these Chinese devices donā€™t respect the reporting configuration, so changing it might not help. Like ZWave devices, you canā€™t poll a Zigbee battery device, so polling is typically avoided and wonā€™t work in any case unless the device is awake (which is nearly impossible).

18

To not confuse things: I was thinking of ā€˜reporting periodā€™ to be a sensor parameter like it is with the illumination sensor and like there often are in other devices in other technologies like ZWave.
That is it would force the sensor to wake up and send a status every n seconds and if it did that would prevent it from dropping offline, too.

In the end Iā€™m just a user that wants this damn thing to work, and as all of us cannot change hard- or firmware, the only way around is to have tweaks and if necessary workarounds in the binding, isnā€™t it ?
(yeah or to dump them, but given theyā€™re cheap I think that is a short-sighted strategy as Iā€™m sure more and more people will keep raising this ever and ever again).

19

Thatā€™s true - it will cause hte device to wake up and send. However the binding knows the reporting period, so it knows how often the device should be reporting, and the binding only sets the device offline if the device doesnā€™t report for (2 x reporting_period) + 30 seconds. So changing the reporting period wonā€™t help since it also changes the offline period.

Fine, but my point is the binding tries to help you with this. Giving you more things to play with doesnā€™t in any way mean itā€™s going to work better - it likely just means you have lots more things to change, but you probably donā€™t know what they do and itā€™s best to leave them to the binding?

Iā€™m not really sure what you mean? If a device isnā€™t compliant to the way Zigbee is meant to work, then changing the binding may or may not help. It really depends on what doesnā€™t work and without knowing that, I canā€™t comment. The binding doesnā€™t deal with low level stuff - it networking. Thatā€™s done by the dongle, so if the device has problems connecting, or routing, or rejoining when parents change, then the binding will not be able to do anything about it.

Iā€™m not sure what strategy you mean? Are you talking about the fact that the binding doesnā€™t allow you to change some settings like the reporting? If so, as Iā€™ve already said, this probably wonā€™t help. If you know what the problem is, then please let me know and we can discuss it, but I think that a ā€œstrategyā€ where the binding provides you lots of things to change, is not a strategy - itā€™s just wishful thinking.

20

I agree and honor your user friendly approach when the binding takes care of this but itā€™s sort of a chicken-egg problem when we try getting new stuff to work.
When a new device does not work out of the box, noone of us knows where the problem technically is located in the first place, if in sensor firmware, unsuitable parameter settings, bad binding/OH processing of messages or hardware, and to find out, we (testing users, early adopters) need extensive logging and the ability to try out some things.
From that perspective, speaking general, Iā€™d prefer to have anything changeable that can be changed, to be able to use it in testing to see if I can get some HW to work that doesnā€™t with defaults, even if that means to violate standards, but maybe we get it to work that way. At least this would provide more insight which never hurts.
Note the alternative is that every tester can just take logs and show them to you for analysis, over and over again. This is slowing down pace of development in the first place.
You also become the bottleneck to save the (Zigbee) world and probably get frustrated fast, too, which also is what I clearly want to avoid.
So Iā€™d think a path somewhere in the middle of the flexibility spectrum would be a good idea.