On / Off switch from HA is unreliable

[carels]

Hi,

I frequently find switching the cololight on/off from HA would be very unreliable. HA would indicate the light is switched on/off, but in reality this would not be the case. It does seem to happen when the light is toggled a few times in a short period of time, e.g.

From an off state, clicking on the light switch in HA 4 times with approx 1s intervals:

click 1: HA indicate light is switched on, Light switches on click 2: HA indicate light is switched off, Light switches off click 3: HA indicate light is switched on, Light switches on click 4: HA indicate light is switched off, Light stays on

I can see the events firing, but no response on the light.

If I leave it alone for a while (about 1 minute) and then try to switch on/off the light starts responding again. Not sure if the light is ignoring too frequent commands perhaps? Is there a way to improve this to get a more reliable response from the light?

In case it matters, on the initial config the light connected to HomeKit which I generally don't use, but the light is still controllable from HomeKit and doesn't have the reliability issue. If I click on the light switch a bunch of times then trying to control the light from HomeKit becomes unresponsive for a bit before it starts working fine again.

Regards, Carel

[BazaJayGee66]

Thanks @carels,

Unfortunately I haven't found a way to prevent this kind on behaviour.

Ideally Home Assistant should be able to poll the light to get the state, rather than relying only on the last state HA set. This would help HA being out of sync with the light if it was controlled by other means, and prevent the need for toggling in HA.

However I haven't found a way for the light to report its state, nor am I sure it does.

I haven't come across the light being unresponsive for a short period of time, but you could be right in thinking that it might be rate limiting the number of requests it allows in a given minute.

Sorry I wasn't able to help more.

[jensandersson]

Just a thought on this -- I have not tried this particular project but I am sending commands on the same format using nc to my device, and I noticed that it was unreliable in changing colour.

Perhaps especially so if I kept sending quite frequent commands to it. Then I noticed that at https://haus-automatisierung.com/projekt/2019/04/05/projekt-cololight-fhem.html he speaks of one byte appearing to be a counter. Instead of always sending 0x01 there, I started sending alternating 0x01 and 0x02. From my quick testing, I would say this made it a lot more reliable, close to 100% from previously being as low as ~50%. I have not collected any proper statistics on this yet, and this was for colour changing (not tested on/off), but I thought it was worth mentioning anyway.

[BazaJayGee66]

@jensandersson great find!

@carels I have implemented the fix mentioned above. This can be found in version v1.2.2, which will now alternate sending 0x01 and 0x02 with each call.

[jens-andersson-2-wcar]

Great! The byte is probably an 8-bit command id, so even safer might be to send an incrementing value (mod 256), or even a random value, although alternating 0x01 and 0x02 was good enough for my purposes.