Zigbee binding

[AFromD (Arno)]

@chris

It’s not in the binding at this point. Please add an issue to the issue tracker and I will take a look at adding a channel - it’s not too hard to do.

Thanks for adding this!

[chris (Chris Jackson)]

As discussed, I’ll now remove it again …

[weakfl]

@chris

I’ve added the XML so this should be in the build in the next day or so.

Great, thanks.
I’ve noticed one thing that doesn’t work yet, if i use the physical switch to turn the relay on or off, the change of state is not reflected in openhab.

[chris (Chris Jackson)]

That should work in the most recent binding - during initialisation the binding should send a “bind” command to the device to tell it to report its status. It’s possible this didn’t work, or that the device doesn’t support this - can you grab a log of the initialisation of the binding and send it over?

[chris (Chris Jackson)]

@weakfl

to get the battery powered switches working too

Just a note on this - I’ve ordered up a switch for testing which should arrive in the next day or so, so I’ll try and look at getting something into the binding next week to provide some level of support for this (no promises though as I go on holiday for 2 weeks after that and no doubt my partner will have other ideas for my time ).

[weakfl]

@chris

Just a note on this - I’ve ordered up a switch for testing which should arrive in the next day or so, so I’ll try and look at getting something into the binding next week to provide some level of support for this (no promises though as I go on holiday for 2 weeks after that and no doubt my partner will have other ideas for my time ).

That’s incredibly nice of you, thanks. And whenever you have time is fine with me, enjoy your holiday!

[weakfl]

@chris

That should work in the most recent binding - during initialisation the binding should send a “bind” command to the device to tell it to report its status. It’s possible this didn’t work, or that the device doesn’t support this - can you grab a log of the initialisation of the binding and send it over?

I’ve installed snapshot 2.2.0~20171203035709-1 but it’s still not working.
I don’t know if that snapshot already contains your latest changes, so I’ve created an issue with the requested log.

[chris (Chris Jackson)]

Thanks. I wouldn’t expect any changes relating to this issue with the latest version. Can you tell me what node ID, or IEEE address the device is?

[asemev (Emre Evinc)]

Hi Chris,

Thanks so much for working on this. I am super excited to add zigbee capabilities to my openhab and get rid of the smartthings hub completely. Would you please let me when the dresden zigbee usb stick is fully working?

all the best,
Emre

p.s. i wrote this same message to your another post by mistake…

[weakfl]

@chris

I wouldn’t expect any changes relating to this issue with the latest version. Can you tell me what node ID, or IEEE address the device is?

Ah ok, I thought the coordinator should already send a “bind” command to the relay with the latest version of the binding.

I currently have two relays in the network:

D85DEF11A1002826: ZigBee node property discovery complete: {zigbee_logicaltype=ROUTER, zigbee_powerlevel=FULL, modelId=RM01, zigbee_networkaddress=45692, zigbee_powersource=MAINS, zigbee_stkversion=1, zigbee_datecode=20161209, zigbee_zclversion=1, vendor=Busch-Jaeger, zigbee_appversion=1, zigbee_powermode=RECEIVER_ON_IDLE, zigbee_powersources=[MAINS, RECHARGABLE_BATTERY, DISPOSABLE_BATTERY], hardwareVersion=0}

and

D85DEF11A1001973: ZigBee node property discovery complete: {zigbee_logicaltype=ROUTER, zigbee_powerlevel=FULL, modelId=RM01, zigbee_networkaddress=31084, zigbee_powersource=MAINS, zigbee_stkversion=1, zigbee_datecode=20161209, zigbee_zclversion=1, vendor=Busch-Jaeger, zigbee_appversion=1, zigbee_powermode=RECEIVER_ON_IDLE, zigbee_powersources=[MAINS, RECHARGABLE_BATTERY, DISPOSABLE_BATTERY], hardwareVersion=0}

[chris (Chris Jackson)]

@weakfl

I thought the coordinator should already send a “bind” command to the relay with the latest version of the binding.

Yes - but that was also in the previous version… So, no change from the previous version, but I still would have expected it to work…

Thanks - I’ll take a look at the logs now…

[chris (Chris Jackson)]

Let’s continue this discussion on the GH issue…

[mwick83 (Manuel)]

@chris: I got myself a Qivicon stick now, because I got pretty frustrated with the TI dongles when experimenting with other zigbee frameworks to get my Xiaomi devices to some use. I found some instructions on flashing the Ember stack onto those devices as well. So, my question is: which stack is your preferred one for the OH binding?
After a quick test, I saw that the stick (with the DTAG Telegesis fimrware) stayed in “initializing” state, but I could definitly see some communictaion going on in the logs. I didn’t investigate depper, but I wanted to know what’s your currently preferred stack before taking any other actions with the stick.

Is there any progress on getting the Xiaomi devices to work? A quick glance at the log output suggests that the devices don’t seem to get completetly discovered, because they seem to not respond to some queries during discovery.

[puzzle-star (Pedro Garcia)]

Hi @chris, I have been busy these days, but I finally could dedicate some time to this. Detection of attributes is working fine (even if for RGB color vs Color Temperature the right check would probably be looking at ColorMode attribute instead).

Just one question, what is the best way to share the new code and modifications? (Color helper class for XY to Hue/Sat conversions and diffs for the ZigBeeConverterColor classes). Maybe sending you a personal message with the new ColorHerleper class and the diffs for the others ?

BTW, I noticed that when reloading the binding (by updating the jar) I see the following message in the logs:

2017-12-08 12:39:49.342 [WARN ] [ome.core.thing.internal.ThingManager] - Disposing handler for thing 'zigbee:coordinator_cc2531:461477c7' takes more than 5000ms.

And the old instances of the converters get still called after the reload (this was driving me crazy as I thought there was something wrong in my code due to some strange related behaviours).

This was not happening to me in the previous snapshot of the binding, and I have worked it around by setting ‘initialised = false’ in ‘disposeConverter()’ and then checking for its value in ‘attributeUpdated()’, but this makes me think there is something wrong in the underlying code.

On the changes made, I am checking for color attribute compatibility early in ‘getChannel()’ so that we can return ‘null’ for ColorTemperature channel in RGB bulbs, and also the other way round. This way a dummy, useless channel is not created for this kind of bulbs.

I also added a helper ‘supportsAttribute()’ method for checking specific attribute compatibility in ‘ZigBeeChannelConverter’, so that it can be used in all converters, but I think it would probably fit better in ‘ZclCluster’ directly.

[chris (Chris Jackson)]

@mwick83

So, my question is: which stack is your preferred one for the OH binding?

Right now, the Telegesis stick is the most tested.

@mwick83

I found some instructions on flashing the Ember stack onto those devices as well.

The binding can do this too

@mwick83

After a quick test, I saw that the stick (with the DTAG Telegesis fimrware) stayed in “initializing” state

Feel free to provide a log. The DTAG firmware is the same (roughly) as the standard Telegesis firmware, and is heavily tested by me now using different versions of the DTAG firmware and they all work fine for me. IF you have an issue, please provide the log and I’ll have a look.

@mwick83

Is there any progress on getting the Xiaomi devices to work?

No - not by me anyway. I’m focusing on standard ZigBee devices at the moment.

[chris (Chris Jackson)]

@puzzle-star

Just one question, what is the best way to share the new code and modifications?

The best approach would be to provide a PR into the repo on Github…

@puzzle-star

Maybe sending you a personal message with the new ColorHerleper class and the diffs for the others ?

If you prefer, then I can also look at this, but a PR would be better.

@puzzle-star

BTW, I noticed that when reloading the binding (by updating the jar) I see the following message in the logs

Can you tell where it’s blocking? I don’t think the shutdown should do much that takes any significant time.

@puzzle-star

And the old instances of the converters get still called after the reload

Maybe the shutdown code isn’t called - I’m not sure about this, but I’ll check…

@puzzle-star

On the changes made, I am checking for color attribute compatibility early in ‘getChannel()’ so that we can return ‘null’ for ColorTemperature

Ok, why can’t CT be used? Do some bulbs not support this?

We might need to have a think if this is ok or not. I also want to do some attribute checks in the getChannel method, so this needs to be done, but we need to ensure that we don’t end up with things waiting too long, or being called twice while these checks take place as it can take many (many!) seconds to perform in some cases depending on the device

@puzzle-star

I also added a helper ‘supportsAttribute()’

Yes, this should be in the cluster class - if you want to add it, please create a PR, althernatively if you prefer I can add it as it’s only a couple of lines of code…

Thanks.

Cheers
Chris

[puzzle-star (Pedro Garcia)]

I will check with the PR. Not using git too much, and I need to check how to do it, but probably the good way to go.

@chris

Can you tell where it’s blocking? I don’t think the shutdown should do much that takes any significant time.

I see that the disposeConverter is called at least (because it does set ‘initialised’ to false in my code), but there must be something after it that gets blocked. Will have a look at it, but will have to dig further into the openhab / binding code

@chris

Ok, why can’t CT be used? Do some bulbs not support this?

Lights that support ColorControl cluster, in my understanding, support either Color or CT, but not both at the same time (ColorMode attribute is either 0 for Hue/Sat, 1 for XY, 2 for CT).

But anyway the check in getChannel is done both in ZigBeeConverterColorTemperature and ZigBeeConverterColorColor, so if for some reason a light supports both, both channels will be created.

@chris

I also want to do some attribute checks in the getChannel method, so this needs to be done, but we need to ensure that we don’t end up with things waiting too long, or being called twice while these checks take place as it can take many (many!) seconds to perform in some cases depending on the device

The implementation I have done of the supportsAttribute method caches the result (so discoverAttributes will be called only once per channel if in ZigBeeChannelConverter, or once for all if in ZclCluster).

@chris

Yes, this should be in the cluster class - if you want to add it, please create a PR, althernatively if you prefer I can add it as it’s only a couple of lines of code…

Agreed, also putting it in the cluster class makes the cached info available for all calls, so it will not be repeated, i.e, for each channel. Also the code is simpler there, and we can benefit of the (looks like currently unused) isImplemented() method in ZclAttribute. I will move it there then.

[chris (Chris Jackson)]

@puzzle-star

Lights that support ColorControl cluster, in my understanding, support either Color or CT, but not both at the same time (ColorMode attribute is either 0 for Hue/Sat, 1 for XY, 2 for CT).

Yes, but… While they only control one mode at once, you must still provide both CT and color channels as the bulb can switch between the two modes at any time. We can’t have channels randomly changing - only if a device doesn’t support the CT command would it be safe/correct not to provide the CT channel. Likewise - only if it doesn’t support any of the color commands and only supports the CT command would it be correct not to provide the color channel.

@puzzle-star

The implementation I have done of the supportsAttribute method caches the result (so discoverAttributes will be called only once per channel if in ZigBeeChannelConverter, or once for all if in ZclCluster).

I’m not completely sure what this means (no problem though - I’ll see later ), but my concern is that if the binding updates the node while the channel discovery is occurring, then we could end up with multiple threads running this code if it takes time. If the device is a battery device, it will take some time for this to respond.

[puzzle-star (Pedro Garcia)]

@chris

only if a device doesn’t support the CT command would it be safe/correct not to provide the CT channel. Likewise - only if it doesn’t support any of the color commands and only supports the CT command would it be correct not to provide the color channel.

That’s excatly what I am doing

@chris

If the device is a battery device, it will take some time for this to respond.

I understand. Will check if there may be any concurrency issues but, are there many battery powered lights that would be sleeping during discovery ? I would expect this for switches, buttons, etc, but not for lights.

[chris (Chris Jackson)]

@puzzle-star

That’s excatly what I am doing

Perfect

@puzzle-star

are there many battery powered lights that would be sleeping during discovery ?

Who knows - probably not. However, as I said before, I also have this requirement for other sensors - IAS requires this as in order to find out if it’s a motion sensor, water sensor etc, we need to read some attributes. This is what I was looking at yesterday (specifically, adding an IAS CIE to process the ST multisensors).