OH2, Z-Wave and Locks Reverse Status

[nolan_garrett]

Hello,

It appears to me that switching from OH1 (with security) to OH2 (with security) has changed the “direction” of locks. Previously in OH1, a locked door was represented by an “ON” status, which makes logical sense when using a switch item. Now a locked door is an “OFF” status.

Is there any simple way to reverse these behaviors?

[ptmuldoon (Paul Muldoon)]

Only a thought and unsure but maybe try that with a transformation?

ON = OFF
OFF = ON

[nolan_garrett]

I’m not certain how, with UI-configured items in OH2, I could apply a transform to only my locks but not all switches. Maybe I’m missing something though, still learning OH2 for sure.

[Mike_Bagdanoff]

Probably a good idea to ask/report in the security testing thread:

OH2 Z-Wave refactoring and testing... and SECURITY

The latest version of the development binding dated 8th Sep 2018 is here. Toward the end of last year I spent some time doing some initial refactoring of the ZWave binding in OH2. This focussed on rewriting the way transactions work as this is an enabler for other areas of the code. At the same time I also restructured the different layers of the binding to make things cleaner, and done some changes to support a system of autocoding the command classes directly from the Z-Wave standard which s…

[chris (Chris Jackson)]

@nolan_garrett

It appears to me that switching from OH1 (with security) to OH2 (with security) has changed the “direction” of locks.

I never used OH1 with locks so I don’t know what was implemented there - OH2 is a complete rewrite, so it could be different.[quote=“nolan_garrett, post:1, topic:26731”]
Now a locked door is an “OFF” status.
[/quote]

Yes - or, you could say “An Open door is ON” - made sense to me ;).

[rossko57]

This is going to become a debate similar to the value or meaning of Contact Items As a general principle in security industry, “off” states are used for “insecure” (so that “on” gives a positive signalling of secure), and so that failed or error states are naturally interpreted as “insecure” as well.

[chris (Chris Jackson)]

@rossko57

This is going to become a debate similar to the value or meaning of Contact Items

Agreed

Personally, I don’t mind - what I do think though is that there should be a common implementation across OH - so that if ZWave locks use ON=locked/OFF=unlocks, Nuki locks, and other locks all do the same thing.

Maybe we should have a specific item type (but I guess that won’t happen) for this…

Can someone see what other systems within OH are using?

[nolan_garrett]

They other thing to consider is how locks get represented in HABpanel and such - I think even most icons are going to treat “on” as the locked state and “off” as the unlocked state. Maybe instead of a debate, there could be a binding setting that sets the directionality of locks?

[chris (Chris Jackson)]

@nolan_garrett

They other thing to consider is how locks get represented

Yes - this is basically my point earlier that there should be a common way to define things like locks (and other items) so that each binding doesn’t have to decide itself and users ultimately have to figure it out for each binding. It should be the same - systemwide.

@nolan_garrett

Maybe instead of a debate, there could be a binding setting that sets the directionality of locks?

IMHO this smells of a system that doesn’t know what it wants ;). Best is to properly define at system level how a lock is meant to be defined (ie, we should have the debate, and not just add a configuration option for everything - this gets confusing for users, and painful for developpers).

[nolan_garrett]

@chris

Best is to properly define at system level how a lock is meant to be defined (ie, we should have the debate, and not just add a configuration option for everything - this gets confusing for users, and painful for developpers)

Fair enough. Well, I am not sure if this thread is where we are having it, but from my perspective if a lock is engaged, that’s “ON” in my opinion.