light.color does not return the actual colour of the LEDs

[stuart12]

Summary

It appears that light.color just returns the last colour written to the device rather than the actual colour of the LEDs. My Agile Innovative BlinkStick Strip has a (hardware?) problem in that not all LEDs change colour even if all LEDs are targeted. Sometimes when I call light.off() not all LEDs are switched off. If I read light.color when my BlinkStick Strip is in this state it incorrectly indicates that all LEDs are off. Could light.color be modified to read the device's state or another method added that does so? In stuart12/busylight-hass@606971f I added code to call light.off() repeatedly. The problem is that the number of times it is necessary to call light.off() is not constant. If the device's actual state was available, the code could stop calling light.off() when all LEDs are finally off. stuart12/busylight-hass@c87abd7 did not indicate that light.color was ever updated with device's actual state even when it took several seconds for all LEDs to be off.

Platform

Linux 6.17.0-6-generic x86_64 GNU/Linux

Version

0.15.3

Python version

Python 3.13.7

[JnyJny]

Most of the hardware supported by busylight-core doesn't support any sort of interrogation of light state, however it appears that the BlinkStick family does. My current thoughts are to read back the state of the hardware in the __bytes__ method, update the busylight_core.vendor.agile_innovative.implementation.state.State and then use the existing methods to determine the state of the light. This could slow down updates to the light since there are two I/O operations (write the new state, read it back) but then we'd have some idea about what LED changes took and what didn't. I'll have to dig into how to read data out, I expect I'll have some time to look at it over Christmas.

[stuart12]

I am not sure that changing the current behaviour is the best solution. I would suggest:

1. the documentation of Light.color be changed to make it clear that it just returns the colour of the first non black LED passed to the most recent call of light.on or light.off.
2. a new method be added that explicitly interrogates the state of a light, given a LED number, and returns the colour. If no LED is passed it could return an array of the colours of each of the LEDs.
3. an attribute be added so that code can determine if a given light supports the new method

[JnyJny]

Coming from the perspective of the BlinkStick family of devices, your approach makes some sense. What I'm thinking of is a more general approach::

• Device state implementations grow a method for reading state from the hardware, if supported.
• Expose a read-only attribute Light.can_synchronize: bool that families of devices set or clear.
• Conditionally synchronize in-memory and hardware state on writes to hardware.
• Expose a read-only attribute Light.colors: list[tuple[int, int, int]]
  This list will contain a color tuple per addressable LED with a minimum of one color tuple present and update from the state.
• Update the documentation for Light.color to describe its behavior for devices with addressable LEDs.

Devices that support reading hardware state will automatically acquire the ability to have updated in-memory representation of hardware state and the remainder of devices continue to behave as they do today.

While not exactly the interface you proposed, I think it would satisfy my desire to have a unified Light API while providing the hardware-coherent introspection that you can use.