Skip to content

feat: Home Assistant: Use operational_status for cover state - #32803

Open
burmistrzak wants to merge 8 commits into
Koenkk:devfrom
burmistrzak:feat/add-operationalstatus-ha
Open

feat: Home Assistant: Use operational_status for cover state#32803
burmistrzak wants to merge 8 commits into
Koenkk:devfrom
burmistrzak:feat/add-operationalstatus-ha

Conversation

@burmistrzak

@burmistrzak burmistrzak commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Allows HA to use operational_status to provide opening and closing states for covers.

Requires Koenkk/zigbee-herdsman-converters#12872

Also included:

  • Change entity category of identify to diagnostic.
  • Add discovery metadata for motor_state, operational_status, calibration_button_hold_time, calibration_closing_time, calibration_motor_start_delay, and calibration_opening_time.

As well as assigning missing entity categories and icons.
@Koenkk

Koenkk commented Aug 10, 2026

Copy link
Copy Markdown
Owner

Can we not use motor_state for this?

@burmistrzak

Copy link
Copy Markdown
Contributor Author

Can we not use motor_state for this?

@Koenkk Well, that would require renaming operational_status, which is a documented attribute of certified Ubisys devices. We followed their naming convention everywhere else, so... 馃槄

If this was a random uncertified product without any technical documentation, I would however agree with you that we should reuse motor_state.

@Koenkk

Koenkk commented Aug 12, 2026

Copy link
Copy Markdown
Owner

Maybe we can put in the expose description that its the operational_status? I prefer to have consistency across devices in z2m.

@burmistrzak

Copy link
Copy Markdown
Contributor Author

Maybe we can put in the expose description that its the operational_status?

@Koenkk Hmm, feels kinda wrong, tbh. Also, motor_state allows more/different values than operational_status, so would make the whole thing even more confusing.

I prefer to have consistency across devices in z2m.

I'd agree with that, but then we would need to somehow unify motor_state, moving, and operational_status because they all basically provide the same information (with slight variations).

This PR more or less does that to some extent, allowing (at least) HA to treat them all the same.

@Koenkk

Koenkk commented Aug 13, 2026

Copy link
Copy Markdown
Owner

I'd agree with that, but then we would need to somehow unify motor_state, moving, and operational_status because they all basically provide the same information (with slight variations).

That sounds good, but I think it's good not to add another one, so I would prefer to merge it with motor_state.

@burmistrzak

burmistrzak commented Aug 13, 2026

Copy link
Copy Markdown
Contributor Author

That sounds good, but I think it's good not to add another one, so I would prefer to merge it with motor_state.

@Koenkk I mean it's ultimately your call, but Koenkk/zigbee-herdsman-converters#12872 has already been merged, thus adding operational_status as a new payload key.

This PR here simply improves HA discovery, and does not add a new key.

So if you want me to rename that payload key for Ubisys devices from operational_status to motor_state, it will have to happen on the ZHC side.

Just let me know if that's what you've intended and you can consider it done. 馃槈

@Koenkk

Koenkk commented Aug 14, 2026

Copy link
Copy Markdown
Owner

I think its best to rename on the ZHC side, the change is also not in a z2m release yet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants