Expose panel resolution, physical size and colour scheme - #86
Conversation
|
Can you resolve conflicts. |
f3ef75a to
1ac6854
Compare
|
Rebased onto the current The only real conflict was the import block in Verified: full test suite passes locally (134 tests), and |
|
Recommend merge after clearing conflicts. |
The panel reports its pixel dimensions, physical size, colour scheme and rotation in the display config packet, but none of it reached Home Assistant: __init__.py reads the pixel dimensions to build the device model and then discards them whenever the diagonal is known, and the diagonal it shows is itself derived from the millimetres. Consumers were left string-parsing a human-facing display name, and could not get the resolution at all. That blocks a real use case: an automation that renders an image at runtime and pushes it with opendisplay.upload_image needs the panel's resolution and colour scheme to size and quantise the render. A template can only read entity state, so the values have to live on an entity. Adds sensor.<device>_resolution, state WIDTHxHEIGHT, with the pixel and physical dimensions, colour scheme and rotation as attributes. Diagnostic and disabled by default, like the other device-fact sensors. - One sensor per device, reporting displays[0]. The config packet is repeatable (max 4), but upload_image and drawcustom take no display argument and both use displays[0] — unlike activate_led/activate_buzzer/play_melody, which do take an instance. A sensor for display 1..3 would describe a panel nothing can draw on, and a consumer sizing a render from it would silently produce an image for the wrong panel. If display addressing is added to those services, this grows to match, keyed the same way. - The state is the panel's NATIVE resolution and is never transposed for rotation. Resolution and rotation are independent facts; folding one into the other would make a panel's resolution change when someone rotates it, and a consumer that wants the rotated extent can combine the two. - Rotation is reported in degrees rather than the firmware's index, and is None when the raw value maps to neither, so an index can never be mistaken for an angle. - The config is re-read on every access. delivery.py replaces runtime_data.device_config wholesale on a wake-time resync without reloading the entry, so a snapshot taken at construction would serve stale geometry. - Stays available while the panel sleeps, since the value comes from config rather than from advertisements. value_fn becomes optional on the description: last_seen already passed a dead no-op to satisfy it, and this sensor would have been a second one.
1ac6854 to
0aa630b
Compare
|
Love this! May I suggest calling the entity |
|
Thanks for taking a look! For my use case either shape works — I just need some template-readable way to reach a panel's specs, so state vs attributes isn't really the deciding factor for me. What makes me lean toward keeping a narrow |
3 participants
Closes #85
Adds
sensor.<device>_resolution— stateWIDTHxHEIGHT, with the pixel and physical dimensions, colour scheme and rotation as attributes. Diagnostic and disabled by default, like the other device-fact sensors.Tested on two panels (7.3" BWGBRY and 7.5" BWR):
800x480, correct millimetres,BWGBRY/BWR, rotation180/0.