OH2, Z-Wave and Locks Reverse Status


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?

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


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.

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

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.

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

This is going to become a debate similar to the value or meaning of Contact Items :slight_smile: 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.

Agreed :wink:

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?

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?

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.

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).

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.