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