Inconsistent handling of Matter 'null' attribute values

[jvmahon]

The problem

Currently, there's an inconsistency in the handling of 'nullable' Matter attributes and HomeAssistant value representations, this can be seen in the number input fields for values such as OnLevel (nullable using the value 255), and OnTransitionTime, OffTransitionTime, OnOffTransitionTime (not currently nullable, but presumably you'd use 65535 to null).

From some work I'm doing with Inovelli, users seem to be quite confused about the 255 value for OnLevel since Hubitat normally uses 255 as a valid level value.

A short-term fix for this could be that 'null' for any nullable values be represented by a "-1" instead of 255 / 65535 to more clearly call a user's attention to the fact that something is 'different' about this number. A long-term fix would be for the HomeAssistant Numbers entity to have an _allow_nullable = true type option so there can be "blanks" in the input box or an explicit null checkbox type of arrangement and symbol (e.g., a Ø symbol)(how does one get a proposal for that going?).

I'd also suggest that the Matter "On Level" permitted range 1-254 maps to the full Hubitat range of on values, 1-255 (using whatever scaling is currently used for the Matter Level Control CurrentLevel attribute and commands)

What version of Home Assistant Core has the issue?

2024.10.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Matter

Link to integration documentation on our website

https://www.home-assistant.io/integrations/matter

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @home-assistant/matter, mind taking a look at this issue as it has been labeled with an integration (matter) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of matter can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign matter Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

matter documentation matter source _{^{(message by IssueLinks)}}

[marcelveldt]

I have no idea what Hubitat has to do with Home Assistant. I find this report very confusing. We should not do things because Hubitat handles that differently.

Home Assistant is Home Assistant and not Hubitat

[jvmahon]

I have no idea what Hubitat has to do with Home Assistant. I find this report very confusing.

Yeah, that was pretty confusing. I didn't mean to reference Hubitat at all. That's what happens when posting on not enough sleep! I've corrected /updated the post.

As a cut-to-the-point, what I'm suggesting is that changing some of the lambda functions in number.py. for example, for OnLevel, changing:

            measurement_to_ha=lambda x: 255 if x is None else x,
            ha_to_native_value=lambda x: None if x == 255 else int(x),

to something like

            measurement_to_ha=lambda x: (-1) if x is None else x,
            ha_to_native_value=lambda x: None if x == (-1) else int(x),

would give a user a bit more of a heads-up that something is a bit different about the value. Using 255 looks too much like a valid / regular value.

and similarly use -1 in other places where a value should be nullable, at least until such time as the number entity gives an ability to have a blank / null value.

[marcelveldt]

I choose 255 as that was already used for this by zigbee and z-wave but I'm fine with -1 as well. On the other hand I think this is a rather advanced value that most people wont even touch. Real solution is indeed the nullable. I'll ask around how far away that would be and otherwise change to -1

[jvmahon]

Thank you!

Yeah, 255 made sense to me when this was first done, but then I realized that there are also 16 bit nullables and realized that I had read the standards so I had information that may be less apparent to the average user.

I agree that the real solution is to have a true nullable capability for the input and if that is on the horizon, might as well wait.

For your consideration, I was also thinking about this some more as to how this might appear on the web UI. I think the current "level control" UI might give a good direction (at least for the slider version of the number input) where you have an On / Off switch (Off = null) and click the switch to get a adjustment to set the level. That UI convention would be something a user is already familiar with. Sort of a "wish list" feature, but thought I'd mention it just in case it was an "easy to do" given a similar UI already exist for the dimmer level control.

In any case, I appreciate that you are considering the suggestion.

[jvmahon]

This is off-topic, but if you have the patience for it ... I have a more "serious" concern that I raised on the Front End issues list. This came up as I was trying to user the Matter "number" entity, but I don't think its just a Matter issue. I've not heard anything - could you advise, did I raise the issue in the wrong forum. https://github.com/home-assistant/frontend/issues/21744

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[marcelveldt]

Coming back to this. If we want to resolve this, we need to open an architecture discussion discussing that we want to have "nullable" number entities. Basically we want to be able to "reset" the entity to its default value. In case of Matter, this is an actual null value but for example Z-Wave knows the concept of 255 to define "device default".

[jvmahon]

I think its worth proposing a change.

I had contemplated two different architecture changes for the "number" entity, https://developers.home-assistant.io/docs/core/entity/number:

Approach 1: the "number" entity would have a new property "is_nullable" which defaults to "False" (current behavior), but if set to "True" then the number entity can be left blank. I think the relevant code that checks for this is at lines 104-114 here https://github.com/home-assistant/core/blob/dev/homeassistant/components/number/init.py where a test would be add to see if the number entity has a True "is_nullable" property and, if so, the value is set to None.

Approach 2: Another approach would be to have a "default_when_blank" property which you could set to values like "None" for Matter or "255" for Z-Wave. This would then be the value used if the number entity was a blank.

A weakness in both these approaches is that they only work for the "box" input type, not the slider. A better implementation might be if some kind of a "null" icon could be selected on the UI for the slider / box, but I don't know anything about how to tweak the UI like that.

What are your thoughts?

[marcelveldt]

Once we pick a solution in an architecture proposal, this also means we account for the UI changes. So I can imagine something like a reset button next to a slider or something alike.

I think approach 1 is enough. The integration can decide to convert the None/null to its own internal default value.

[jvmahon]

So I can imagine something like a reset button next to a slider or something alike.

I like that idea of a reset button. I could enter a proposal, though I think it would be more credible and get more traction coming from you.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.