#Zwave 'Opening state' replacing binary sensors for doors/windows?

1 messages · Page 1 of 1 (latest)

zinc gust
#

Before updating to latest 1.1.0 app, I need to know/understand what is going to happen with my existing binaries, and the automations that feed off those...

Add a new synthetic Opening state variable with 3 states to represent door/window state: Closed/Open/Tilt

why would those binaries be removed in a future update?

The old binary sensors are still supported, but will be hidden by default and removed in a future release. Switch to the new Opening state sensor as soon as possible.

None of my doors/windows have a tilt, nor do the devices that check for those states provide a tilt state. only open/closed.
So, I'd prefer to keep the binaries...

#

Zwave 'Opening state' replacing binary sensors for doors/windows?

austere lantern
zinc gust
#

yeah I noticed that, but I dont get why the current binaries would have to go. seems the current binary is a perfect implementation for doors/windows being open or closed...

austere lantern
#

The Z-Wave JS Discord would likely be the better place to ask.

zinc oriole
#

That change was made due to HA usability issues. One step forward, two steps back.

native furnace
#

Half the binary sensors never worked with no simple way to see which one is which (there are two of each with the same name in HA).
There were binary sensors for "Closed" and "Open"

#

I've been getting requests from manufacturers who also couldn't explain to their customers how it's supposed to work.

#

Also, if the window is tilted, is it open or not? There were two sensors that disagreed, both with the same name.

zinc oriole
#

How many devices are out there that support tilt vs not?

#

According to the z-wave spec, if it's tilted it's open

#

FYI I already mentioned that the duplicate "Closed' and "Open" entities were bugs introduced during last summer. Those did not previously exist until discovery "refactoring" was performed. The other entities were still confusing though.

native furnace
#

FWIW there are other integrations which also use a 3-state sensor for windows.

zinc oriole
#

But no device class

zinc gust
#

I can confirm having more than a handful of binary entities for the same device... some I havent enabled, as I only need the one at the top, which I renamed. But I do need to keep that as binary, not a tri state entity? tht would be a regression of proportion imho

Schermafbeelding_2026-03-24_om_23.16.46.png
#

this one now even shows a lock, which it isnt. so there are 4 entities irrelevant/duplicate here. All are binary btw.

zinc gust
zinc oriole
#

Yep, tilt is indicated along with the open notification.

zinc gust
#

so what do you think, any chance we can keep the binary for open/closed ? I sincerely hope so. Expect even...

harsh egret
#

JM2C, I understand how keeping binary could be helpful, but i for one am really glad they are moving to tri-state, having about a dozen door sensors, this always confused me. yes i have automation tired to it and when it rolls out i have to change my blueprints but overall i think it a good thing.

zinc oriole
#

Which devices do you have that benefits from this?

harsh egret
#

all my door sensors, i don't really understand why i need 6 sensors to know if open, closed, or tilted? why do i need is open and is closed? like if it not open it closed right. maybe it just get the use cases, and maybe for me one is better and other people need them all. i love to hear how people are using them all

image.png
zinc oriole
#

Which door sensors do you have that support Tilt?

#

The debate is the tri-state sensor vs binary_sensor, there is no debate about removing all the duplicate sensors, that's a given.

#

The open vs closed are simply a bug in HA, the closed sensors where never meant to exist. So that removes 2 of the 6. The duplicate sensors are also due to never being fixed in HA (which this change is doing), that part is arguable. The tilt sensors are the troublesome one.

harsh egret
#

oh okay maybe then i don't understand why 3 state sensor is much different then 2 state when comes to automating things? why changing it to a 3 state is issues, can you explain that to me. i think i am missing some context

#

also i not sure just HA bug, in zwave-js there not 6 but 3 say the same thing

image.png
zinc oriole
#

Here's a summary of my concerns:

  1. it sounds like there is maybe one z-wave device that supports tilt, so this helps a few users and hurts everyone else
  2. requires everyone to rewrite their automations to switch from on/off to new states
  3. AFAIK, binary sensor can be used in groups, but enum sensors can't, how will that impact users who group these? Does it affect other usages like labels and areas (I don't know)
  4. a new wholesale entity means everyone fixes their dashboards (may not be avoidable in all cases even if consolidating to one of the existing binary sensors)
  5. The new entity has no device class, which means no icon (this might be fixable to a non-configurable icon), so you lose the icon open close state. there's no possibility to reconfigure it as something like a door or window, etc.
  6. The new sensor's third "tilt" state doesn't exist until the device actually triggers it, so for most users this will never happen and they will be left wondering what the change was for
#

Door state and Door state simple are what are going to be removed in the future

#

HA could support a backwards-compatible binary on-off sensor by just supporting "value != closed" that would work for everyone. And allow anyone with tilt support to use the other one. Maybe such users don't even care about the tilt value.

harsh egret
#

ahh i get it more now

native furnace
#

We're discussing how to improve this.

zinc gust
zinc oriole
#

FWIW the repairs were not even triggering for me

native furnace
#

Did you use the entities in automations?

zinc gust
#

if it's any consolation, I had 4 repairs 😉 and theyre gone now!

#

have quite a few more binary_sensors though so why those werent triggering a repair will remain a question forever hah

zinc gust
native furnace
#

The plan is to replace them with a single binary open and a single binary tilt sensor (optional) that actually work.

zinc gust
#

great. btw, why a binary 'open', and not just a plain binary, without that open/closed in the name.
it will always ignite discussion . the device_class will take care of it anyway

zinc oriole
#

Also, haven't gotten to submitting an issue yet, but I see this for sensors that have not been updated since the update. The Opening State on is understandable (although couldn't the driver migrate it?), but the others have valid values. Persists over restarts, but once the update is triggered all the entities update.

image.png
native furnace
native furnace
native furnace
zinc oriole
#

Makes sense

zinc gust
native furnace
#

To be honest, I'm not sure about the implications of that. Sounds reasonable

zinc oriole
#

That works if there aren't other binary sensors, unless you could identify it's the "primary" feature

native furnace
#

that's the thing - having additional binary sensors is always an option in Z-Wave

zinc oriole
native furnace
#

Uh can you see where it comes from?

zinc oriole
#

It's the Opening State value ID

#

On my 2026.03 HA instance

native furnace
#

how is the entity ID?

#

there should be 7 entities - 6 legacy and the new one

zinc oriole
# 
      {
        "domain": "binary_sensor",
        "entity_id": "binary_sensor.guest_bedroom_window_sensor_open",
        "original_name": "Open",
        "original_device_class": "lock",
        "disabled": false,
        "disabled_by": null,
        "hidden_by": null,
        "original_icon": null,
        "entity_category": null,
        "supported_features": 0,
        "unit_of_measurement": null,
        "value_id": "261-113-0-Access Control-Opening state",
        "primary_value": {
          "command_class": 113,
          "command_class_name": "Notification",
          "endpoint": 0,
          "property": "Access Control",
          "property_name": "Access Control",
          "property_key": "Opening state",
          "property_key_name": "Opening state",
          "state_key": 1
        }
      },
#

Wait, that might be wrong

#

fixed

native furnace
#

Oh no

#

This looks like the default discovery path that derives all notification binary sensors from their notification value.

#

But it should be disabled for this one

#

This does look weird, I give you that:

image.png
#

better

image.png
#

wdyt, "Tilted" or just "Tilt"?

austere lantern
#

Should tilted better be a generic on/off?

native furnace
#

maybe? But this way it shows up on the security dashboard:

image.png
austere lantern
#

A window being open and tilted being closed sounds off.

zinc gust
#

I think Tilt entity should show on/off as state?

native furnace
#

but then I can't make it show up on the security dashboard automatically, can I?

austere lantern
#

Does it need to be, if the window sensor is also open when tilted?
From a security standpoint completely open and tilted are both not safe states, so no real need to differentiate. I think the tilted state is more interesting in automations for example. But just my 2 cents.

native furnace
#

oh, yeah...

#

good point

#

yeah that's better

image.png
zinc gust
#

Personally I’d prefer Tilt instead of Tilted. It’s the Tilt binary , not the Tilted ( but that might be my language sensitivity barrier acting up…)

zinc oriole
#

Open -> Closed

#

Tilted seems right

zinc oriole
#

Although not exactly the same as it's not the state value, so whatever.

zinc gust
native furnace
#

Should be live soon

#

Thanks for your feedback folks

zinc gust
#

hmm not sure this is what I had hoped for, deprecating my only used binary..... but I guess I can rename the new _open binary to the same name I used before..

Schermafbeelding_2026-03-31_om_11.39.21.png
#

also, theyre all still there? in this case, the binary_sensor.achter_deur being deprecated, does that mean it will be taken out in 6 months? because like it is I can not delete it (it is created by the integration), nor can I rename the new to my preferred naming, because that already exists

Schermafbeelding_2026-03-31_om_11.42.15.png
#

in which case my MO would probably be, rename existing entity_id to something else, rename new binary_sensor.xxx_open to my preferred entity_id, and then disable the existing/now deprecated?

#

which is a pain really as I have to move all labels to those too... arrgh

#

Doable though 🙂

#

Well except for deleting the deprecated ones

native furnace
#

These are new entities because they are derived from a different Z-Wave value. And yes, the old ones still exist and will continue working. They are deprecated, and will now be discovered as hidden by default.

#

I'm slightly confused by the IDs - they should be the opposite of what the repair issue says

#

@crimson scroll do you understand why this results in an entity ID with suffix _open? None of the integration tests had that.

zinc gust
#

fwiw, I just edited them all (had a few of these repairs for my doors) and it was less of a hassle than I feared, so dont worry on my behalf 😉
but yes, the repair says it like it was, the new one was the _open, so I renamed (and changed their entity_id's) to be what I had

native furnace
#

Hmm maybe that was an automatic naming thingy because the non-suffixed ID was already taken

crimson scroll
#

There's no automatic deduplication using an _open suffix. If the wanted entity_id is already taken we just add an integer, like _2.

#

Could it be an existing entry in the entity registry for this value that was restored?