tlaukkan / zigbee4java

Zigbee API for Java provides simple Java interface to ZigBee network.
Apache License 2.0
144 stars 68 forks source link

Unknown and random device types #29

Closed cdjackson closed 9 years ago

cdjackson commented 9 years ago

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.

chris-hatton commented 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.

cdjackson commented 9 years ago

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

tlaukkan commented 9 years ago

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

cdjackson commented 9 years ago

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

tlaukkan commented 9 years ago

Hi

Merged the pull request.

-Tommi

tlaukkan commented 9 years ago

Important fix :+1: