Closed cdjackson closed 9 years ago
I would add that the ZLL lights I have been connecting erroneously appear as 3 devices; only one of which has any clusters/functionality. Of the three devices created, it seems random which 'index' is the functional device id. Please excuse brevity, at work. Thanks, Chris
On 13/04/2015 7:41 am, Chris Jackson wrote:
I finally got around to chasing down why I get a random device being discovered each time the stack starts for my Hue. My Hue bulbs show an endpoint 242 - it's always been there, and it's a little frustrating in that every time the stack starts it gives this endpoint a different device type - I want to stop this! :)
There are really two issues here - firstly, the random selection of device type. This is just plane bad news - in the case of the Hue, where the device isn't known anyway, it doesn't matter, however it means even if the device is known, if it somehow happens to come up with the same score when the factory is evaluating a match, then next time it might evaluate to a different device if it matches two devices with the same score. In my case, the reason for the randomness is that this device doesn't come up with any score from the factor 'hasMatch'. So, the first class in the factory is the winner and the order isn't defined, so we end up with a random selection each time. This issue is easily solved by using a map that has a defined order - I've made this modification and will generate a PR soon.
The other issue is that returning any device type when the score is 0 is wrong - it hasn't matched any clusters, so we can't really say that this is the device (well, not one that we know!). So, to resolve this I propose to return null from getBestDeviceProxyFactory which stops the device being constructed.
PR to follow.
— Reply to this email directly or view it on GitHub https://github.com/tlaukkan/zigbee4java/issues/29.
Hey Chris, It might be worth you grabbing my PR to see if it fixes your problem - I would guess that you will just end up with a single EP now...
Chris
Would you like to merge to main branch? If the device type is unknown then we could add unknown device type to the list instead of null.
Br, Tommi
Hey Tommi, I think I generated a PR for this - I didn’t merge as I thought I’d let you have a look first :) I’m happy to merge it though if you like...
Chris
Hi
Merged the pull request.
-Tommi
Important fix :+1:
I finally got around to chasing down why I get a random device being discovered each time the stack starts for my Hue. My Hue bulbs show an endpoint 242 - it's always been there, and it's a little frustrating in that every time the stack starts it gives this endpoint a different device type - I want to stop this! :)
There are really two issues here - firstly, the random selection of device type. This is just plane bad news - in the case of the Hue, where the device isn't known anyway, it doesn't matter, however it means even if the device is known, if it somehow happens to come up with the same score when the factory is evaluating a match, then next time it might evaluate to a different device if it matches two devices with the same score. In my case, the reason for the randomness is that this device doesn't come up with any score from the factor 'hasMatch'. So, the first class in the factory is the winner and the order isn't defined, so we end up with a random selection each time. This issue is easily solved by using a map that has a defined order - I've made this modification and will generate a PR soon.
The other issue is that returning any device type when the score is 0 is wrong - it hasn't matched any clusters, so we can't really say that this is the device (well, not one that we know!). So, to resolve this I propose to return null from getBestDeviceProxyFactory which stops the device being constructed.
PR to follow.