Disable light transition time number entities by default#742
Disable light transition time number entities by default#742TheJulianJES wants to merge 2 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #742 +/- ##
=======================================
Coverage 97.63% 97.63%
=======================================
Files 62 62
Lines 10814 10817 +3
=======================================
+ Hits 10558 10561 +3
Misses 256 256 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Rarely yes but I think this it is good example why some users choose migrate aware from ZHA and move to Zigbee2MQTT when config entitie are disabled by default ZHA. It may only require a single niche edge case to make a user move to Z2M if it offers configutation options for that by default. The same arguments can probably can also be applies to PR that will disable light default move rate config entity by default:
Would it not be better to change the way these are exposed on the frontend-side in ZHA's UI so that they are not removed but instead hidden by default so that a user can still relativly easily access them if wanted in ZHA instead of pushing those users to feel like they need to migrate to Zigbee2MQTT if they want to get access to all advanced configurations? For reference. this issue on the Open Home Foundations's roadmao talks about further shaping ZHA partially due to concerns that has been raised about ZHA missing feature parity with Z2M, and removing config entries is kind of the opposite, or? |
There was a problem hiding this comment.
Comment-only since this is still a draft — sharing observations as early feedback.
The code change is minimal and clean: three _attr_entity_registry_enabled_default = False lines on the existing OnOffTransitionTimeConfigurationEntity / OnTransitionTimeConfigurationEntity / OffTransitionTimeConfigurationEntity classes, matching the established pattern in binary_sensor/sensor. The regen ripples cleanly through 39 light snapshots — only the three target *_transition_time unique_ids flip entity_registry_enabled_default: true → false. The behavioural note in the description (existing paired devices aren't affected because the registry only honors the default at first-add) is correct.
On the open question (disable all three, or conditionally?)
Per ZCL R8 §3.10.2.2.11/§3.10.2.2.12, OnTransitionTime and OffTransitionTime default to 0xFFFF (non-value), and the spec explicitly says "If this command is not implemented, or contains a non-value, the OnOffTransitionTime will be used instead." So on a typical light that implements all three, the active attribute out-of-the-box is OnOffTransitionTime — the On/Off pair are only meaningful once the user sets them away from the non-value, which (as your description notes) the number entity disallows anyway because max_value = 0xFFFE.
That suggests the opposite asymmetry to the one floated in the description: if anything were to stay enabled, it'd be OnOffTransitionTime (the active one), not the On/Off pair (the inert-by-default ones). A conditional rule like "disable OnOff only when both On+Off are supported" would leave the less useful entity enabled on the most common case. I'd lean toward keeping the PR as drafted (disable all three) unless there's a concrete user workflow where the On/Off pair is more discoverable than OnOff.
Orthogonal but related: the max_value = 0xFFFE cap making the non-value (0xFFFF) unsettable from the entity is a real UX gap — a user who enables OnTransitionTime to set a value and then wants to revert to "use OnOffTransitionTime" has no way to do so via the entity. Worth a follow-up (raise max_value to 0xFFFF and treat it as the documented non-value, mirroring how a few other configuration entities handle sentinels), but out of scope here.
Needs a rebase
The diff against current dev includes six incidental entity_registry_enabled_default: false → true flips for default_move_rate on bega/inovelli-vzm30-sn/ledvance-flex-rgbw/ledvance-outdoor-accent-light-rgb/legrand-dimmer-switch-w-o-neutral/schneider-electric-lk-dimmer. Those are exactly the six files touched by #741 (merged 2026-04-29), which added _attr_entity_registry_enabled_default = False to DefaultMoveRateConfigurationEntity (currently at zha/application/platforms/number/__init__.py:404). This PR's merge-base predates #741, so the snapshots regenerated here reflect the pre-#741 code and read as re-enabling default_move_rate against current dev. A rebase onto dev + rerun of tools/regenerate_diagnostics.py should drop those six flips and leave a transition-time-only diff.
On Hedda's parity concern
Worth a separate note since it was raised explicitly: I checked how Z2M actually exposes these attributes to Home Assistant via MQTT discovery (zigbee2mqtt/lib/extension/homeassistant.ts, zigbee-herdsman-converters/src/lib/exposes.ts + modernExtend.ts). The picture for the attributes in scope of this PR (and #741):
on_off_transition_time,on_transition_time,off_transition_time,on_level,current_level_startup,default_move_rate— none of these become controllable HA entities in Z2M. They live as nested features of eitherlevel_config(a composite inside thelightexpose) or aren't exposed at all. Z2M's HA discovery iterates only top-level exposes, and thecase "light":branch produces a singlelightentity without breaking out nested config features. Users who want to change these in Z2M use the Z2M frontend or hand-craft MQTT publishes — there is nonumber.foo_on_off_transition_timeentity.withLevelConfig()is opt-in per device inzigbee-herdsman-converters(~41 of ~155 light-bearing device files). The modernm.light()extend defaultslevelConfigtoundefined. So even for lights that do support these attributes, most Z2M device handlers don't surface them.- The Z2M attributes that do become writable HA entities are
power_on_behavior(top-level Enum →select) and a handful of similar top-level config exposes — none of which are in scope here.
Net effect: ZHA today is strictly more permissive than Z2M on every attribute this PR touches, and after the PR it's still strictly more permissive (the entity exists and can be enabled in HA with one toggle, vs. Z2M where these attributes have no HA-side handle at all). So the "users will migrate to Z2M because it offers these as defaults" framing doesn't hold for the specific attributes being disabled here. The broader "make ZHA discoverable but de-emphasized rather than disabled" suggestion is reasonable as a UX direction, but worth noting that entity_registry_enabled_default: false already makes the entity one click away from usable — and that's notably more accessible than what Z2M gives the HA UI for the same attribute.
No blockers; happy to re-look once you've decided on "all three" vs "conditional" and rebased onto dev.
|
@Hedda Thanks for the feedback. To answer some of your questions or concerns:
Z2M does not expose entities for these exact attributes in HA at all. With ZHA, you can still just enable them in HA.
That entity is basically completely useless for everyone, unless you want to bind a remote to a light AND have a remote that sends move commands without an explicit value AND you then want modify that.
They're still on the device page in HA. They're just disabled by default because they caused a lot of unnecessary noise.
We're not removing anything. This works towards the overarching goal of making Home Assistant more approachable this year. These config entities being enabled by default is not friendly for anyone using Home Assistant. We could likely even remove them entirely and nobody would complain, but we won't do that, of course. There might be one person using them. 😄 |
3 participants
DRAFT. Do not merge yet – see question at the bottom.
Proposed change
This disables the various transition config entities for lights by default.
Additional information
These entities are rarely used, as it also depends on how you turn on the light (e.g. with a brightness, or without), whether these apply, or the global ZHA option.
It also depends on the light when the individual "On transition time" and "Off transition time" entities are used, versus the "On/off transition time" entity. E.g. for most lights (and per spec), "On/off transition time" should not be used, unless both "On transition time" and "Off transition time" have a non-value, so
65535. We disallow setting this value via the number entity, for some reason.Notes
The entity is not disabled for existing (paired) devices, only for ones paired with this version of ZHA (and newer).
The entity can still be enabled using Home Assistant.
Thoughts / Question
I'm not completely certain we should disable all these entities by default. Maybe we can conditionally only disable the "On/off transition time" entity if both the "On transition time" and "Off transition time" entities are supported as well? (Because in that case, the devices do not use the on/off entity, unless the on + off entities are set to none values.)