Firstly, I will say that I’m not trying to be a pain here and thanks for the constructive conversation.
There’s a problem (IMHO) with your reasoning. For each parameter you can change, you increase the number of possible variations significantly - randomly changing things is really not a good way to deal with things, and I understand your point that if you don’t know what’s wrong you just want to be able to change things, but really there is no substitute for understanding what is happening.
You also need to understand what’s happening because you may or may not have worked out that for configuration changes to actually take effect, the device needs to be awake. Zigbee works very differently in this area to ZWave - so this needs to be managed. The binding tries to do this, but if you are just able to change everything, you’d need to understand this yourself.
Well, I disagree that this must be done by me. As I said earlier - there is no substitute for understanding what is happening. Randomly changing things until it works doesn’t mean it will continue to work. If something is broken, understand what’s wrong - the logs help here, and if you have the time to randomly change things until hopefully it works, then I’d suggest that you hopefully could put some of that time into trying to understand what is happening. It’s educational, and probably a lot less frustrating than randomly changing numbers
Yes, and of course this is correct - I agree. This is what I target, and when the binding was first written for Deutsche Telekom / Qivicon this was the balance we tried to hit. Adjusting things like reporting periods is useful, and is something I started to add on some channels, but the reality is that it probably won’t help your issue when a device doesn’t work.
We are testing on an inexpensive early production stick which may have issues. The threads on other sites indicate people do have issues with this stick so it might be bit premature to assume the device will not work or that changing any settings will help. It could be a stick firmware issue.
It will be interesting when we get more sensors on these sticks if we see issues on devices people know are good.
The real unknown is how the firmware has been programmed. I don’t know how much these guys know, but there are a bunch of configuration settings that need to be made to improve performance.
In general though the stick should be fine from a general networking perspective - there’s not really a lot they can do to screw it up for small networks at least. The commercial systems I’ve supported have thousands of gateways deployed - all with Ember chips and they are all running basically the same firmware.
Agree, but then again understanding this is way easier for you as it requires in-depth ZigBee and implementation knowledge (you to know the binding’s behavior which we do not) we do not have to the extent it takes to understand what’s going on.
As you probably see in my posts I’m not keen on shooting at the dark either, of course I am looking to systematically test things, systematic to the extent possible but that is limited by my understanding of ZigBee and knowledge of the binding’s behavior. And hard enough as we also need to take all the non-binding factors such as RF hardware effects and controller firmware into the equation.
My reasoning there also is that more flexibility will also help people with educating themselves on ZigBee by just trying out things (something I myself keep telling end users on about every other aspect of OH, too).
I’m convinced enabling them and us to ‘play’ more will help pacing speed of Zigbee adoption and even OH reputation.
Ok, back to work
Testing the illuminance sensor. There’s three channel detail settings (four when ‘advanced’)
Upfront, when I change any of it, the thing drops into unknown state and takes quite long to recover. While in ‘unknown’, channel details disappear completely from UI but reappear when back online (irritating but ok).
I’ve set the first channel detail parameter ‘minimum reporting period’ to 20 but I see messages coming in every 5 secs. So does that mean the sensor ignores the setting ?
At least it’s a regular 5 secs report interval now, before it seems to have reported any change.
The last parameter is ‘report on charge The minimum change of the attribute value needed to trigger a device state update’ it has a default of 5000 (5000 what ? lux?) and does not allow to set less than 10. At the same time the sensor reports even minor lux changes less than 10. Does not make sense, does it.
Next irritating thing is, everything(?) seems to be duplicated. All channel details are listed twice in UI.
When I change one parameter, the other changes, too so it might also be a UI problem only, then again a typical message like below indeicates double processing, too. Apparently one active and another not-so-active channel ? Maybe that started happening when I changed channel details, maybe only when I disabled+reenabled the thing.
It is something I saw with other sensors, too. Will restart and try to reproduce and identify what’s triggering the duplicates to appear.
2021-04-23 14:23:42.790 [DEBUG] [converter.ZigBeeConverterIlluminance] - 04CF8CDF3C78B536: ZigBee attribute reports ZclAttribute [cluster=Illuminance Measurement, id=0, name=Measured Value, dataType=UNSIGNED_16_BIT_INTEGER, lastValue=20970, lastReportTime=Fri Apr 23 14:23:42 CEST 2021, implemented=false]
2021-04-23 14:23:42.790 [DEBUG] [converter.ZigBeeConverterIlluminance] - 04CF8CDF3C78B536: ZigBee attribute reports ZclAttribute [cluster=Illuminance Measurement, id=0, name=Measured Value, dataType=UNSIGNED_16_BIT_INTEGER, lastValue=20970, lastReportTime=Fri Apr 23 14:23:42 CEST 2021, implemented=false]
2021-04-23 14:23:42.792 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 04CF8CDF3C78B536: Channel zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_illuminance updated to 124.02590302177201
2021-04-23 14:23:42.792 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 04CF8CDF3C78B536: Channel zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_illuminance updated to 124.02590302177201
2021-04-23 14:23:42.793 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - null: Updating ZigBee channel state zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_illuminance to 124.02590302177201
2021-04-23 14:23:42.794 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 04CF8CDF3C78B536: Updating ZigBee channel state zigbee:device:sonoff:04cf8cdf3c78b536:04CF8CDF3C78B536_1_illuminance to 124.02590302177201
2021-04-23 14:23:42.795 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ZigBeeThingHandler of thing zigbee:device:sonoff:04cf8cdf3c78b536 tried updating channel 04CF8CDF3C78B536_1_illuminance although the handler was already disposed.
2021-04-23 14:23:42.796 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:sonoff:04cf8cdf3c78b536
2021-04-23 14:23:42.796 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ZigBeeThingHandler tried updating the thing status although the handler was already disposed.
2021-04-23 14:23:42.797 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker cancelled task for thingUID=zigbee:device:sonoff:04cf8cdf3c78b536
2021-04-23 14:23:42.799 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:sonoff:04cf8cdf3c78b536 in 7230 seconds
2021-04-23 14:23:42.800 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:sonoff:04cf8cdf3c78b536
2021-04-23 14:23:42.802 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker cancelled task for thingUID=zigbee:device:sonoff:04cf8cdf3c78b536
2021-04-23 14:23:42.804 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:sonoff:04cf8cdf3c78b536 in 7230 seconds
EDIT: restart made duplicates go away. Dis+Enable did not make them reappear.
‘Report on change’ was set to 5 after restart but clicking into the frame made the display jump to 5000
Then there is a constraint that you have to enter values from 10-20000, it seems to be an UI constraint.
According to several web sources, the luminance value of that sensor can be 0-100000.
Why is it there ? Can I change it ? (another example of things I’d like to modify/“mess” with).
FYI, xsp1989 (ITead firmware developer for this dongle) wrote that he only changed parameters for Address Table Size, Child Table Size, Source Routes and CTUNE value, and that “The remaining parameters are at the default values.”. I collected the info he wrote and submitting PR to his readme:
FWIW, someone requested to add openHAB as a category just some minutes ago.
I guess this will happen in one way or another so I’d like to encourage everybody to read this to have your experiences ready at hand to put up your success reports as soon as OH gets listed.
Yes I have (although I don’t know what you refer to by “temperamental”).
For comparison, I have moved my Aqara test sensors to my Conbee controller and use the deCONZ binding, it supports many sensors including mine.
No issues since I moved it to deCONZ, the weather sensor now is reporting as often as expected whenever temperature is changing.
Would love to use the zigbee binding instead but see up my current issue with the weather sensor not answering / finally dropping offline and for the time being I don’t know what to try.
I logged three attempts. First two were with Elelabs ELR023 coordinator, third back to iTead.
In the beginning I created a new coordinator thing (twice to check different Pan ID generations, too - all fine) then in all attempts I’ve reset and paired the Aqara/LUMI weather sensor.
In all attempts, pairing seemed to have worked (sensor properly identified), but the thing always remained ‘unknown’ after pairing period ended.
Didn’t work on 1st and looked very much the same as on iTead before so I believe it’s not specific to the coordinator but the binding. @chris please have a look at this log below. If this is insufficient let me know what I shall enable in debug.
Here’s the 2nd attempt this time also with com.zsmartsystems debug.LUMIweather_pairing.txt (780.5 KB) enabled.
Here’s the 3rd attempt showing how I went back to the iTead stick: LUMIweather_pairing_iTead.gz.txt (81.5 KB)
1st attempt nothing happened even when I linked the thing to an item there was another message
but no response from the sensor. So I believe it didn’t work.
On 2nd attempt (txt above), sensor thing did not get online until I’ve pushed the button (last seconds of log). Unlike 1st attempt, it seems to be working since (delivering values).
Same on 3rd attempt (back to iTead stick) worked (although took pretty long and some clicks on the sensor) but seems to be working since.
Log thing creation & sensor pairing:
2021-04-25 14:41:49.184 [DEBUG] [ng.zigbee.ember.handler.EmberHandler] - Initializing ZigBee Ember serial bridge handler.
2021-04-25 14:41:49.185 [DEBUG] [ng.zigbee.ember.handler.EmberHandler] - ZigBee Ember Coordinator opening Port:'/dev/ttyUSB0' PAN:e58d, EPAN:FECEEB5267DFC4A0, Channel:11
2021-04-25 14:41:49.187 [DEBUG] [ng.zigbee.ember.handler.EmberHandler] - Ember end device poll timeout set to (169 * 2^9) = 86528 seconds
2021-04-25 14:41:49.188 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Scheduling ZigBee start
2021-04-25 14:41:50.189 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee network starting
2021-04-25 14:41:50.190 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Initialising ZigBee coordinator
2021-04-25 14:41:50.192 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - Creating ZigBee persistence folder /var/lib/openhab/zigbee/zigbee_coordinator_ember_elelabselr023/
2021-04-25 14:41:50.194 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Connecting to serial port [/dev/ttyUSB0] at 115200 baud, flow control FLOWCONTROL_OUT_XONOFF.
2021-04-25 14:41:50.194 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - null: networkStateUpdated called with state=INITIALISING
2021-04-25 14:41:50.258 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Serial port [/dev/ttyUSB0] is initialized.
2021-04-25 14:42:04.341 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Mesh Update Period 86400
2021-04-25 14:42:04.360 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee Initialise: Previous device configuration was: channel=CHANNEL_11, PanID=65535, EPanId=8B63AB674BE43728
2021-04-25 14:42:04.362 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Link key initialise 5A6967426565416C6C69616E63653039
2021-04-25 14:42:04.363 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Network key initialise F29FA93CC6BA32E948B5793AA8846AAA
2021-04-25 14:42:04.364 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - Config: zigbee_trustcentremode=TC_JOIN_INSECURE
2021-04-25 14:42:07.590 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - ZigBee initialise done. channel=CHANNEL_11, PanId=58765 EPanId=FECEEB5267DFC4A0
2021-04-25 14:42:07.630 [DEBUG] [bee.handler.ZigBeeCoordinatorHandler] - null: networkStateUpdated called with state=ONLINE
2021-04-25 14:42:07.899 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - CCCCCCFFFEA5F167: ZigBee saving network state complete.
2021-04-25 14:42:10.130 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - CCCCCCFFFEA5F167: ZigBee saving network state complete.
2021-04-25 14:42:22.812 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_INPUT_REGISTERS, start=4999, length=37, maxTries=3]). Will try again soon. Error was I/O error
, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: ModbusIOException Premature end of stream (Header truncated). [operation ID 8d53fee5-d7f7-4c83-a701-21a229ad7f20]
2021-04-25 14:42:56.841 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - Starting ZigBee scan for zigbee:coordinator_ember:elelabselr023
2021-04-25 14:43:00.902 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Starting ZigBee device discovery
2021-04-25 14:43:00.906 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Creating ZigBee device zigbee:device with bridge zigbee:coordinator_ember:elelabselr023
2021-04-25 14:43:00.909 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zigbee:device:elelabselr023:00158d00067c0e16' to inbox.
2021-04-25 14:43:00.911 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Node discovery not complete
2021-04-25 14:43:01.166 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - 00158D00067C0E16: ZigBee saving network state complete.
2021-04-25 14:43:15.264 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_INPUT_REGISTERS, start=4999, length=37, maxTries=3]). Will try again soon. Error was I/O error
, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: ModbusIOException Premature end of stream (Header truncated). [operation ID 12e3fb99-73ce-45f4-9b8f-e73f6971473b]
2021-04-25 14:43:16.684 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Starting ZigBee device discovery
2021-04-25 14:43:16.687 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Creating ZigBee device zigbee:device with bridge zigbee:coordinator_ember:elelabselr023
2021-04-25 14:43:16.691 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: ZigBee node property discovery start
2021-04-25 14:43:16.693 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: ZigBee node property discovery using basic cluster on endpoint 4B69/1
2021-04-25 14:43:16.980 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - 00158D00067C0E16: ZigBee saving network state complete.
2021-04-25 14:43:23.122 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: Node doesn't support OTA cluster
2021-04-25 14:43:23.124 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: ZigBee node property discovery complete: {zigbee_logicaltype=END_DEVICE, zigbee_powerlevel=FULL, zigbee_manufacturercode=0x1037, modelId=lumi.weather, zigbee_networkaddress=19305,
zigbee_powersource=DISPOSABLE_BATTERY, zigbee_stkversion=2, zigbee_datecode=20191205, zigbee_zclversion=1, vendor=LUMI, zigbee_powermode=RECEIVER_ON_IDLE, zigbee_powersources=[DISPOSABLE_BATTERY], hardwareVersion=30, zigbee_applicationVersion=5}
2021-04-25 14:43:23.125 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Checking endpoint 1 channels
2021-04-25 14:43:23.135 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Initializing channel zigbee:device:elelabselr023:00158d00067c0e16:00158D00067C0E16_1_temperature with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterTemperature@139f
fd
2021-04-25 14:43:29.606 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Initializing channel zigbee:device:elelabselr023:00158d00067c0e16:00158D00067C0E16_1_pressure with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterAtmosphericPressure
@13ee2d4
2021-04-25 14:43:39.325 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Initializing channel zigbee:device:elelabselr023:00158d00067c0e16:00158D00067C0E16_1_humidity with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterRelativeHumidity@17
05b53
2021-04-25 14:43:45.813 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D00067C0E16: Update ZigBee device zigbee:device with bridge zigbee:coordinator_ember:elelabselr023, label 'LUMI lumi.weather'
2021-04-25 14:43:46.126 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - 00158D00067C0E16: ZigBee saving network state complete.
2021-04-25 14:44:04.183 [ERROR] [d4j.internal.RRD4jPersistenceService] - Could not create rrd4j database file '/var/lib/openhab/persistence/rrd4j/Ertrag.rrd': null
2021-04-25 14:44:04.186 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'Energiemanagement-5' failed: Character n is neither a decimal digit number, decimal point, nor "e" notation exponential mark. in Energiemanagement
2021-04-25 14:44:08.879 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Initializing ZigBee thing handler zigbee:device:elelabselr023:00158d00067c0e16
2021-04-25 14:44:08.883 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Coordinator status changed to ONLINE.
2021-04-25 14:44:08.884 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Coordinator is ONLINE. Starting device initialisation.
2021-04-25 14:44:08.902 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Start initialising ZigBee Thing handler
2021-04-25 14:44:08.910 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: ZigBee node property discovery start
2021-04-25 14:44:08.917 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: ZigBee node property discovery using basic cluster on endpoint 4B69/1
2021-04-25 14:44:08.919 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: Node doesn't support OTA cluster
2021-04-25 14:44:08.920 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D00067C0E16: ZigBee node property discovery complete: {zigbee_logicaltype=END_DEVICE, zigbee_powerlevel=FULL, zigbee_manufacturercode=0x1037, modelId=lumi.weather, zigbee_networkaddress=19305,
zigbee_powersource=DISPOSABLE_BATTERY, zigbee_stkversion=2, zigbee_datecode=20191205, zigbee_zclversion=1, vendor=LUMI, zigbee_powermode=RECEIVER_ON_IDLE, zigbee_powersources=[DISPOSABLE_BATTERY], hardwareVersion=30, zigbee_applicationVersion=5}
2021-04-25 14:44:08.930 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Checking endpoint 1 channels
2021-04-25 14:44:08.938 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Dynamically created 3 channels
2021-04-25 14:44:08.941 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Updating thing definition as channels have changed from [] to [zigbee:device:elelabselr023:00158d00067c0e16:00158D00067C0E16_1_temperature, zigbee:device:elelabselr023:00158d00067
c0e16:00158D00067C0E16_1_pressure, zigbee:device:elelabselr023:00158d00067c0e16:00158D00067C0E16_1_humidity]
2021-04-25 14:44:08.991 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Initializing device
2021-04-25 14:44:08.995 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Initializing channel zigbee:device:elelabselr023:00158d00067c0e16:00158D00067C0E16_1_temperature with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterTemperature@1167
102
2021-04-25 14:44:48.892 [DEBUG] [converter.ZigBeeConverterTemperature] - 00158D00067C0E16: Failed to bind temperature measurement cluster
2021-04-25 14:44:48.896 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Initializing channel zigbee:device:elelabselr023:00158d00067c0e16:00158D00067C0E16_1_pressure with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterAtmosphericPressure
@1db2181
2021-04-25 14:45:28.894 [ERROR] [r.ZigBeeConverterAtmosphericPressure] - 00158D00067C0E16: Error 0xffff setting server binding
2021-04-25 14:45:28.897 [INFO ] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Channel zigbee:device:elelabselr023:00158d00067c0e16:00158D00067C0E16_1_pressure failed to initialise device
2021-04-25 14:45:28.900 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Initializing channel zigbee:device:elelabselr023:00158d00067c0e16:00158D00067C0E16_1_humidity with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterRelativeHumidity@11
6aab6
2021-04-25 14:46:48.909 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Channel initialisation complete
2021-04-25 14:46:48.911 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Thing is RFD, using long poll period of 1800sec
2021-04-25 14:46:48.912 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Setting ONLINE/OFFLINE timeout interval to: 14430
2021-04-25 14:46:48.913 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker added for thingUID=zigbee:device:elelabselr023:00158d00067c0e16
2021-04-25 14:46:48.914 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:elelabselr023:00158d00067c0e16
2021-04-25 14:46:48.915 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:elelabselr023:00158d00067c0e16 in 14430 seconds
2021-04-25 14:47:08.924 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Error getting binding table
2021-04-25 14:47:08.929 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Polling initialised at 1881148ms
2021-04-25 14:47:08.930 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D00067C0E16: Done initialising ZigBee Thing handler
2021-04-25 14:47:09.255 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - 00158D00067C0E16: ZigBee saving network state complete.
events.log:
2021-04-25 14:41:01.134 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:humiditysensor:00212E06D557:00158d00067c0e16010405' changed from OFFLINE (BRIDGE_OFFLINE) to UNINITIALIZED
2021-04-25 14:41:01.153 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:humiditysensor:00212E06D557:00158d00067c0e16010405' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2021-04-25 14:41:01.157 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:pressuresensor:00212E06D557:00158d00067c0e16010403' changed from OFFLINE (BRIDGE_OFFLINE) to UNINITIALIZED
2021-04-25 14:41:01.178 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:pressuresensor:00212E06D557:00158d00067c0e16010403' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2021-04-25 14:41:01.181 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:temperaturesensor:00212E06D557:00158d00067c0e16010402' changed from OFFLINE (BRIDGE_OFFLINE) to UNINITIALIZED
2021-04-25 14:41:01.202 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:temperaturesensor:00212E06D557:00158d00067c0e16010402' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2021-04-25 14:41:01.256 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:humiditysensor:00212E06D557:00158d00067c0e16010405' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2021-04-25 14:41:01.259 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:pressuresensor:00212E06D557:00158d00067c0e16010403' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2021-04-25 14:41:01.261 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'deconz:temperaturesensor:00212E06D557:00158d00067c0e16010402' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2021-04-25 14:43:00.911 [INFO ] [openhab.event.InboxAddedEvent ] - Discovery Result with UID 'zigbee:device:elelabselr023:00158d00067c0e16' has been added.
2021-04-25 14:44:08.836 [INFO ] [openhab.event.InboxRemovedEvent ] - Discovery Result with UID 'zigbee:device:elelabselr023:00158d00067c0e16' has been removed.
2021-04-25 14:44:08.864 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:elelabselr023:00158d00067c0e16' changed from UNINITIALIZED to INITIALIZING
2021-04-25 14:44:08.883 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:elelabselr023:00158d00067c0e16' changed from INITIALIZING to UNKNOWN
2021-04-25 14:44:09.279 [INFO ] [penhab.event.FirmwareStatusInfoEvent] - Firmware status of thing zigbee:device:elelabselr023:00158d00067c0e16 changed to UNKNOWN.
2021-04-25 14:47:08.927 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:elelabselr023:00158d00067c0e16' changed from UNKNOWN to ONLINE
Moved the illuminance sensor back to the iTead stick.
I needed two attempts, on first, it never paired successfully (I kept clicking the sensor and there were packets too but it never identified the sensor correctly in the OH thing).
Can you see why ?
You need to keep the device awake for some time after it joins. These devices are well known for sleeping very quickly after they join. The binding needs to discover the devices features - it doesn’t use any sort of database so it needs to download quite a bit of information from the device before it can discover it’s name and features.
Include the device, then quickly create the thing - all the time keeping it awake, and probably for about 30 seconds or so after it is created as a thing.
These issues are well documented with other systems as well, but the binding is a bit more susceptible for two reasons - firstly it doesn’t use a database so needs to discover all the devices features, and secondly the way the binding currently works is part of the discovery is done on join, but the actual initialisation is done when the thing is created, so the device needs to be awake for both parts. I’m changing the binding so that the initialisation is done during the discover rather than when the thing is created, but this will have other potential issues for devices that are created through the database.
which log do you mean ? I use the following debugs let me know if they’re not right.
Yes for the weather sensor on 1st attempt log I had forgotten the first of those settings.
openhab> log:get|grep zigb
com.zsmartsystems.zigbee x DEBUG
org.openhab.binding.zigbee x DEBUG
Exactly how - by hitting the button every few seconds ? I wasn’t sure if that could disturb the process.
Does discovery have to finish before I can add the thing (i.e. does a discovered device need to have changed from ‘unknown’ to its name) ? If scan finishes with ‘unknown’ name, can I simply restart a scan or do I have to delete the half-discoverd thing from the inbox first ?
Can I already create the thing while scan is still ongoing (as soon as it shows the name) ?
I mean the log that you provided in the email I think it was part of the openhab log file - the events log is normally of no use, and the openhab log that you pasted in had no zigbee traffic at all. I was just trying to understand what it is you wanted to show as you asked me to look at it…
Exactly how - by hitting the button every few seconds ? I wasn’t sure if that could disturb the process.
Yes, you need to continue to press the button every second or so to keep it awake or the device will sleep. Once it’s asleep, it’s not going to complete discovery.
Can I already create the thing while scan is still ongoing (as soon as it shows the name) ?
Yes - this is fine and probably needed to get into the second stage of discovery (ie the initialisation part). I’ll try and get the PR finished to improve this in the coming days.
ah ok, you read via mail. My initial post had a single log only but I added more by editing the post that’s why to me it wasn’t clear which one you mean.
Yes in that 1st log I had forgotten to enable com.zsmartsystems debug and hoped the binding.zigbee debug is sufficient to see what happened, because after that the sensor was paired and I could not reproduce the problem.
Logs 2&3 essentially show successful pairing so probably not worth examining.
To be on the safe side, again my question if these are the debugs you would need in case:
Do I have to wait for the displayed device name to change from ‘unknown’ to its discovered name first before I click it to add it as a thing ? (i know it would give me a bad thing name but that I change anyway)
FYI, one of the reason Aqara/Xiaomi devices are relatively stable in Home Assistant’s ZHA and Zigbee2MQTT despite not 100% following standard Zigbee Cluster Library specifications is that those applications both an additional device handler/converter layer for ‘quirk’ workarounds which translate non-standard attributes/parameters into attributes/parameters that are compliant standard ZCL specifications.
ZHA in Home Assistant depends on “ZHA Device Handlers” and zigbee-herdsman (used by Zigbee2MQTT and IoBroker) depends “zigbee-herdsman-converters” for modified Zigbee device compliance which has similar concepts of converting/translating non-compliant device attributes to follow ZCL (Zigbee Cluster Library) standards.
ZHA device handlers and it’s provided Quirks allow Zigpy, ZHA and Home Assistant to work with non standard Zigbee devices. If you are reading this you may have a device that isn’t working as expected. This can be the case for a number of reasons but in this guide we will cover the cases where functionality is provided by a device in a non specification compliant manner by the device manufacturer.
What is a device in human terms
A device is a physical object that you want to join to a Zigbee network: a light bulb, a switch, a sensor etc. The host application, in this case Zigpy, needs to understand how to interact with the device so there are standards that define how the application and devices can communicate. The device’s functionality is described by several descriptors while the device itself contains endpoints and endpoints contain clusters. There are two types of clusters an endpoint contains:
in_clusters - are “Server” clusters in ZCL terms. These clusters control the device, e.g. a smart plug or light bulb would have an on_off server cluster. in_clusters are also the ones which also send attribute reports and/or you can read an attribute from a in_cluster.
out_clusters - are “Client” clusters. These clusters control some other device, as “Client” cluster sends commands to “Server” cluster. For example an On/Off remote would have an on_off client cluster and will generate cluster commands and send those to some other device. Zigpy needs to understand all these elements in order to correctly work with the device.
This is how ZHA exception and deviation handling is explained to new users and Zigbee novices:
"The ZHA implementation in Home Assistant relies on a library called “ZHA Device Handlers” to resolve issues with Zigbee devices that do not fully conform with the Zigbee standards. The few devices that deviate from the Zigbee specifications set by the Zigbee Alliance may therefore require proper bug reports with debug logs from users to assistant the developers in writing custom ZHA Device Handlers for all of a device functions to work properly with the ZHA integration.
Such a custom “ZHA Device Handler” are Python scripts that internally are also referred to as a “quirk” because they fix “quirks”, like deviations from the standard specifications. ZHA Device Handles do this by transparently, acting as a translator, translating and converting non-compliant device messages and instead present them to the application as coming from a virtual compliant device. These ZHA Device Handlers for Home Assistant can thus be used to parse custom messages to and from Zigbee devices. The ZHA Device Handlers that are made can then be reused by all users in future versions of Home Assistant.
That is a complex way to have to do things and a lot of work to maintain.
Not sure I buy into adding all sorts of fixes.
I think I prefer to find devices that comply even if they cost a little more as the end result will be a lot more stable. Having layer on layer of fixup things will be more likely to break on big upgrades. Very clever but not sure good for long term stability.
and thanks for the constructive conversation.
