Core: Zwave lock switch is now reversed 0.73 beta

[omriasta]

Home Assistant release with the issue:

0.73b3

Last working Home Assistant release (if known):
0.72.1

Operating environment (Hass.io/Docker/Windows/etc.):

Hassbian
Component/platform:

Zwave lock

Description of problem:

My zwave lock switch on the UI used to be "on" (blue) when the device was locked. After update to 0.73 beta "on" (blue) is displayed when the lock is unlocked. The lock icon is correct for the state (closed lock when locked and open shackle when unlocked). I have a schlage connect BE469NXCEN. The lock still functions and there are no issues but it may cause issues for people with automations or scripts.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

[MuppetOwl]

Can also confirm exact same issue on 0.73 beta. Danalock V3 Z-wave

[turbokongen]

This is also the same on Verisure platform. Lock states are reversed in the ui. Tha actual state is correct.

[turbokongen]

This is a change, but not a breaking. All service work as before. It is being changed to support group.turn_on/off service. Before lock would be unlocked with the group.turn_off service. Now it does lock the door. Imagine this together with lights and switches. You will turn off lights and switches and lock the lock. It will be mentioned in the release notes.

[Bahnburner]

This is a very counter-intuitive change to fix an edge use case.

[omriasta]

It's not in the release notes. Also imagine someone has an automation that references the lock and now when they leave their house the lock will be unlocked for them... It does not affect me but a change that pertains to a home lock should be introduced with a very visible warning.

[mattsch]

I agree, this is a pretty significant change in behavior and will be extremely confusing from a UI standpoint. On/off really doesn't apply to locks IMO, they should be treated as security devices only, not switches.

[c727]

@omriasta stop spreading false information please

[Bahnburner]

@c727 I'm not sure what false information @omriasta could possibly be spreading. This isn't in the release notes. I also had to stop and explain to my wife that the lock status has been flipped to make sure she's not manually unlocking the doors everyday when she leaves the house. There was absolutely no communication regarding this change.

[omriasta]

@c727 I apologize if I missed it but I honestly went through the release notes and didn't see it... Maybe a different icon would also help as the "gap" in the shackle of the current icon is kind of hard to see. Maybe also changing the lock Color to yellow would help to make the status more clear

[c727]

it DOES NOT effect automations

switch is not suitable for locks, as @mattsch already mentioned

if you have a binary_sensor.door the ON-state is also door open and not locked

[omriasta]

I think I understand now...apologize for the confusion. I thought that it was a switch as it is displayed that way in the UI but it actually uses the service to lock/unlock and that is pretty clear so it shouldn't be confused. I was merely stating that @turbokongen said it would be in the release notes but not under breaking and I could not find it there...

[Bahnburner]

if you have a binary_sensor.door the ON-state is also door open and not locked

It sounds like the binary sensors are wrong then, as an OPEN circuit would be OFF.

This is an extremely user-ignorant change. No layperson is going to look at the UI and think that an off switch means locked. This is going to cause consistent problems for secondary and tertiary users.

[gregg098]

I agree that this change is counter-intuitive and will confuse a lot of people. Last night I spent 45 minutes trying to figure out why my locks were "unlocking" when I set my Night Mode which arms everything, locks doors, etc.

Maybe we need a customization option to invert the switch on the front end (I would default it to the way it was before though).

Another option is to change the display of a lock altogether to something...more lock-like?

EDIT: Yes, I know. A quick walk to my door would have told me it was actually locked, but I was already in bed and that seemed like the hard option! :)

[lmamakos]

if you have a binary_sensor.door the ON-state is also door open and not locked

My doors are not binary sensors - they are sensors that have values "Normal" and "Violated" (and in theory, if you exported all the semantics from the alarm system there could be a third "Trouble" state which indicates a busted alarm loop. I can see the attraction of trying to simplify, but you I'd think that matching expectations and historical behavior are important considerations.

I think of a lock as a security device, and "ON" means "secured", that the device is engaged and performing its primary function.

I'll just comment that in casual observation of the process of reviewing changes and commits to the repository, there seems to be a big gap in the process in considering changes to the user experience, having adequate documentation that's useful to someone that didn't write the code, and that also extends to the release notes as well.

I'm not sure if it's only Z-Wave devices that seem to get dinged by these significant changes, seemingly out of the blue. The implement implementation of the entity registry was a really significant regression in Z-Wave functionality which also didn't seem to get any mention in the release notes, either. I would think that these sorts of things could be considered breaking changes and have a bit more consideration and subsequent notification/communication to the user base, which is increasingly less characterized as "early adopter".

My two cents as just an end-user.

[c727]

Last thing I say to this: there was a PR laying around since 6 months to change locks to NOT use the toggle. And it's NOT obvious that on means locked and btw: you still have the state icon that indicates the lock-state. Also why has none of you beta tested the release to report this issue if you care that much?

So locks will no longer use toggle in next release as you can see in the linked PR above.

But funny that even our moderators upvote trash comments like the one with the wrong binary sensor...

[Bahnburner]

there was a PR laying around since 6 months to change locks to NOT use the toggle.

Do you really expect non-developers to casually browse through every single PR? Do you think most of them would understand half of what they're reading? You can't pretend to be user friendly with distros like Hass.io and then complain about users being upset about a MAJOR change that was not communicated to end users at all and use the argument that they should have read the PR. Half of them probably don't even know what that is.

you still have the state icon that indicates the lock-state

Many of us use custom icons, so no, we don't have state icons that reflect the lock status.

And it's NOT obvious that on means locked

In what world is it not obvious that on=locked? On = Activated. An activated lock is LOCKED.

It's clear that your intention is to steamroll everyone on this without taking even a moment to consider other's opinions. Referring to other's comments as 'trash' just solidifies this. My interaction with you regarding this is honestly the first time I've ever been disappointed by the Hass community. This component that has functioned as expected since at least v0.23 when I started with Hass. I'm not sure why after 2 years we are suddenly completely reversing the state.

EDIT: It looks like this isn't your first time forcing your opinions about locks on everyone...

[metbril]

I don't have any locks but stumbled into this by coincidence. If we end users, not being developers, want to change something, we are forced to do this through the feature requests forum and discuss it over there. I honestly think that a major user facing change regarding home security should have been proposed and discussed where the users live: in the community, not in the repo.

And I agree that a lock being locked / armed should have the the binary state of 'ON'.

[MuppetOwl]

Also agree that ON should be locked state.

[omriasta]

@c727 if you look at the title of the thread, I did mention this prior to the release while I was on the beta. Once I was told that it would be in the release notes, I didn't add anything until the actual release. Even then it was only because it wasn't stated in the release notes as I was told...

[brad999]

I agree with the majority here that ON should be the locked state.

Also, not a huge fan of how argumentative @c727 has been with this group and what seems like others. Debate is good and productive but clearly you're outright ignoring other's opinions (even when they are giving you the benefit of the doubt) and coming back to them with an unwarranted level of aggression.

Kudos to everyone else for keeping it civil in spite of some polarizing comments!

[Bahnburner]

I can't even find the original PR for this change. Anyone have a link? I'm debating on rolling back the commit and building my own frontend.

[omriasta]

@bahnburner I believe it is the one referenced above #1407 but not sure use the link above, not sure why mine is linking elsewhere.

[Bahnburner]

Nah, #1407 is @turbokongen's requires to fix this mess.

[metbril]

Perhaps it was this PR:

https://github.com/home-assistant/home-assistant/pull/11980

and this related one:

https://github.com/home-assistant/home-assistant-polymer/pull/845

Update: probably not, is was tagged 0.66

[Bahnburner]

Yeah, #11980 was merged in 0.66 and #845 was closed and never merged (partly because @c727 hounded the dev to get his way until the dev gave up and abandoned PR.)

[awarecan]

It was home-assistant/home-assistant-polymer#1337

[Bahnburner]

That's the one. No wonder I couldn't find it. There's no mention of the actual change in the review since it was rolled into a group of Lovelace improvements.

I can't imagine it would be normal process for a major breaking change to be listed as "also fixed some logic in the old ui". Can you confirm @balloob?

[turbokongen]

Fixed in 0.73.1. Now it is only teext.

[Bahnburner]

Well, that's mildly better, I suppose.

[ryanwinter]

Thanks for getting this resolved so quickly. I actually really like the new lock/unlock text. I always thought I switch was really confusing.