candeo development

> Correct me if im wrong but identity cluster is **moderate** by Zigbee standard on at least the first endpoint, Indeed, but these devices are permanently sleepy (unless reporting an...

@puddly We reinstated the Identify Cluster as requested. Please let us know if anything further is required?

@TheJulianJES thanks for the feedback! We're out of our depth a bit with the unit test, but took a stab at it with this: ``` """Tests for Candeo.""" from zigpy.zcl.clusters.measurement...

@TheJulianJES we (eventually) added a unit test for the lux_calibration which seems to work fine, please let us know if anything further is required.

@TheJulianJES, this all looks good to us! Thanks for the pointers on the unit test, hopefully in the future we'll get code for these more inline with what you're expecting....

@puddly thanks for the fast reply! Unfortunately I've only got the zigpy-znp log snippet from the customer for their TI based radio, so can't see the raw packet contents. There's...

@puddly I've gathered some more information now. I'm testing in two separate HA instances in different docker containers, both with ZHA, one with a TI radio and one with an...

Indeed, it's another somewhat buggy device :-( Unfortunately we missed the issue during testing as we're only using ember radios internally so the issue did not present itself. I wasn't...

Hi again @puddly! We may have a workaround from our side, it transpires that if you bind the Cluster to the cordinator with a valid endpoint then it sends an...

Thanks for the pointers @TheJulianJES! > You should be able to just use `await self.endpoint.in_clusters[0xFF03].bind()` in your example. Ah, I thought there'd probably be a way to do it without...