Parent
#89
What to build
Expand a widget for a light that is off. Today the brightness slider sits hard left and claims 0%, which is a lie: Home Assistant is reporting no brightness at all. It nulls brightness, color_temp_kelvin and every colour attribute whenever the light is off, and nulls color_temp_kelvin on its own whenever the light is in some other colour mode.
After this ticket, an axis Home Assistant reports as null renders as absent rather than as minimum: the controls block dims to around 40% opacity and the slider knob is not drawn at all. A missing knob says "this axis has no value right now" in a way that cannot be read as "the value is at the minimum", which is exactly the confusion the current fallback creates.
The controls stay operable. Touching one still turns the light on and sets it.
Deliberately not chosen: remembering the last non-null value. That shows 4000K on a light currently glowing blue, with no signal that it is history.
This is a defect in what #87 shipped, and #89 needs the rule to exist before a colour surface can inherit it.
Acceptance criteria
Testing
Red first at S2: drive the application with the attribute blob Home Assistant sends for a light that is off, and assert the widget offers no value for the brightness axis rather than offering zero. Then feed a blob where the light is on and assert the value comes back.
This is the first test to land at S2, so it also builds the harness the later tickets reuse: Snapdash::new(), a wiremock server standing in for the Home Assistant REST endpoint with the connection pointed at it, and a helper that builds an entity state from a real attribute blob.
The "still operable" criterion is the one that needs the wiremock half: drag a dimmed axis and assert a service call was actually posted.
Blocked by
Parent
#89
What to build
Expand a widget for a light that is off. Today the brightness slider sits hard left and claims 0%, which is a lie: Home Assistant is reporting no brightness at all. It nulls
brightness,color_temp_kelvinand every colour attribute whenever the light is off, and nullscolor_temp_kelvinon its own whenever the light is in some other colour mode.After this ticket, an axis Home Assistant reports as null renders as absent rather than as minimum: the controls block dims to around 40% opacity and the slider knob is not drawn at all. A missing knob says "this axis has no value right now" in a way that cannot be read as "the value is at the minimum", which is exactly the confusion the current fallback creates.
The controls stay operable. Touching one still turns the light on and sets it.
Deliberately not chosen: remembering the last non-null value. That shows 4000K on a light currently glowing blue, with no signal that it is history.
This is a defect in what #87 shipped, and #89 needs the rule to exist before a colour surface can inherit it.
Acceptance criteria
Testing
Red first at S2: drive the application with the attribute blob Home Assistant sends for a light that is off, and assert the widget offers no value for the brightness axis rather than offering zero. Then feed a blob where the light is on and assert the value comes back.
This is the first test to land at S2, so it also builds the harness the later tickets reuse:
Snapdash::new(), awiremockserver standing in for the Home Assistant REST endpoint with the connection pointed at it, and a helper that builds an entity state from a real attribute blob.The "still operable" criterion is the one that needs the wiremock half: drag a dimmed axis and assert a service call was actually posted.
Blocked by