I am seeing some irregular updates without triggering the motion sensor now, however, a large change in brightness doesn’t trigger an update of luminance.Takes a few minutes to come through.
Hi @chris,
I have redone my changes on the color channels to support XY, using your last implementation of ‘discoverAttributes’ in ‘ZclCluster’ as I was working on a previous one. Will send the pull request today or tomorrow, but I found a small issue in ‘ZclCluster.discoverAttributes(…)’ that should be fixed first:
index += response.getAttributeInformation().size();
Should probably be replaced by something like:
int last = response.getAttributeInformation().get(response.getAttributeInformation().size()-1).getIdentifier();
if(last >= index) index = last + 1;
else break; // just to prevent a bad zigbee implementation from making us loop forever
The reason is that, at least according to the zigbee cluster library manual, the requested index in the command is the one of the first attribute id to be included in the response (not related to the amount of attributes received in the list, as they are not correlative). As a result, my Tradfri light (with supported attribute id 65533) is receiving >6k AttributeDiscovery commands before the discovery finishes… 
Just for this couple of lines, it may not be useful to fork, etc, to send a pull request. Could you please apply this change without a PR?
Also, you may want to replace the two ‘break’ statements in the loop (including the one above), by a ‘return false’ so that the caller knows the discovery has not suceeded (which I supose is the reason for returning a Boolean)
Doing some checks on my changes on the color channel converters, and will send the PR for these, but of course it depends on discoverAttributtes being fixed first.
1 Like
Hi Pedro,
Yes - I also saw this issue yesterday and opened an issue here -:
https://github.com/zsmartsystems/com.zsmartsystems.zigbee/issues/152 https://github.com/zsmartsystems/com.zsmartsystems.zigbee/issues/152
I think this is the same thing you are talking about, but in my case it was not looking for an attribute of 65k 
I will take a look at fixing this.
I probably won’t merge anything more into the 2.2 version (other than fixes) so I might not merge your changes until after 2.2 is released - I hope this is ok? I also did some tidy up today (sitting on a plane for 12 hours!), but maybe I’ll try and merge your changes first if possible.
Cheers
Chris
No issues 
Will send today the PR for the color channels, but anyway there is no point / urgency in merging till the attribute discovery is fixed, as it would impact the working RGB lights (so it would do more harm than good)
Last night I pushed some changes that I hope fix the attribute issue. I’ve not tested it as I’m away, but if you want to pull the branch then please feel free.
Cheers
Chris
I tried with my ST motion & contact sensors and no luck with my husbzb-1. It shows the same behavior as before with the light on the sensor flashing green during pairing but not succeeding. I’ll try to gather a set of logs and submit them this weekend but I know you are on vacation so I’m in no hurry.
Ok, I’m not overly surprised as I didn’t get the chance to test this on the Ember before I went on holiday. I’ll look at this when I’m back - shouldn’t be hard to resolve I think.
If you want to post a debug log then I’ll be happy to have a look (as you said - no hurry ).
Hi @chris,
Yes, the changes you did fix the issue. I have just sent a pull request with the changes in the color channel converters. I understand these will not be on time for 2.2 merge (or will they? )
Probably it won’t be merged, but let’s see. I want to get the updates from the library included so we have a clean version there. If I get time to review your PR I will try, but time is short, and internet here is very poor so no promises I’m afraid.
Hello! I’ve a similar issue, I’ve a husbzb-1 and an Iris contact sensor, no luck on discovery phase. Zigbee dongle is not recognizing the sensor.
Here is the log if it helps.
Thanks for all your work guys, I really like what you are doing 
If it’s a SmartThings sensor, then it will likely be the same problem. I know the issue, and just need to test this out on the Ember NCP, but it will be a couple of weeks before I get to look at this.
I didn’t get your PR into the 2.2 release - time was a bit short with cutoff at 6pm CET today. I did update the library to fix the bug with the attribute and a couple of other NPEs (just in time) thanks @5iver for testing.
@puzzle-star I think your PR is against my repo - can you create a PR directly to the openhab zigbee repo please and I’ll take a look at it after 2.2 goes out.
OK! Will create the PR directly against the openhab zigbee repo.
Happy that the attribute discovery is fixed for the 2.2 release (will make patching the color channels easier while these are merged)
I understand it was too late for merging the XY color changes into 2.2 - too tight a timing, and better to give enough time for testing and checking it does not break anything else
This one turned up in the log, not in Karaf! If I was in debug, I wouldn’t have found it… but if I was in debug, you may have something more to go on. 
This is the same one I was reporting earlier thoguh, which you have some logs for.
2017-12-18 17:36:36.178 [ERROR] [artsystems.zigbee.internal.ZigBeeNetworkDiscoverer] - 4292/1: Error during endpoint discovery:
java.lang.NullPointerException: null
at com.zsmartsystems.zigbee.internal.ZigBeeNetworkDiscoverer.updateEndpoint(ZigBeeNetworkDiscoverer.java:598) [16:org.openhab.binding.zigbee:2.2.0.201712170307]
at com.zsmartsystems.zigbee.internal.ZigBeeNetworkDiscoverer.getSimpleDescriptor(ZigBeeNetworkDiscoverer.java:565) [16:org.openhab.binding.zigbee:2.2.0.201712170307]
at com.zsmartsystems.zigbee.internal.ZigBeeNetworkDiscoverer.access$800(ZigBeeNetworkDiscoverer.java:61) [16:org.openhab.binding.zigbee:2.2.0.201712170307]
at com.zsmartsystems.zigbee.internal.ZigBeeNetworkDiscoverer$3.run(ZigBeeNetworkDiscoverer.java:340) [16:org.openhab.binding.zigbee:2.2.0.201712170307]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
I can’t find any logs that I can really correlate with this. It’s probably specific to a device and there are no responses in the logs I look at for address 4292. If you can get a debug log showing this it would be really good.
I have debug turned back on now. I see this happened a couple times today, so it should turn up soon. This is the same NPE that goes with the logs in ticket (QN8cXFZjqbD).
I don’t think we ever actually caught the exception AND the log leading up to it did we? I looked back through some of your logs posted in this ticket last night and couldn’t find anything. At the time I added protection around the error and this one looks slightly different than the previous one so I’d like to see the full discovery of the node causing the problem.
You’re right… this is the SimpleDescriptorResponse NPE! We never had logs for this one. I logged one this morning and have put it into the ticket.
Thanks.
@chris I still got the CEL MeshConnect ZigBee usb sticks. Did you manage to get them working and do you have new firmware for those usb sticks that works with the 2.2 version of the ZigBee binding?