Pin secured switch needs to be pressed again to activate

[ertanden]

I have a switch widget which is pin secured. When I press it, the PIN dialog appears, I enter the PIN but the switch is not activated. I expect the switch to be activated because I already pressed it.

Similarly for PIN secured and "protected" switches, first the progress appears and then asks for PIN, but after succesful PIN the switch is not activated.

I would expect for "protected" switches first to immediately ask for PIN and if PIN correct then the progress to appear and then I can cancel if I want, if I don't cancel switch should activate without needing to press again.

I hope I was clear.

Very good job by the way. The best openhab UI I have seen so far. I hope this gets open sourced some day...

[igorgladkov]

@ertanden Need some more info, because I don't see the described behavior:

• device OS
• device model
• switch sitemap config
• switch item config

[ertanden]

Nexus 6P, with Android 7 latest release candidate.

Rotini version 0.22.99

The following is an example sitemap with the problems I described.

sitemap rotini label="Alarm" {

  Text label="Alarm" {

    Frame label="Alarm {widget:switch,icon:security}" {
      Switch item=Alarm_armed
      Text label="{item:pin} [enter-some-pin-hash-here]"
    }

    Frame label="Siren {widget:switch,protected:true,icon:security}" {
      Switch item=ZW_Siren
      Text label="{item:pin} [enter-some-pin-hash-here]"
    }
  }
}

[igorgladkov]

Will check if that's Android 7 related. The app does not officially support Android 7 yet, so it wasn't specifically tested on it.

[igorgladkov]

@ertanden The issue with required additional press has been fixed for the next release.
Regarding the combination of protected and pin: while I agree that reversed behavior makes more sense, I don't see it as common use case, since entering a pin provides a user to cancel it if not wanted, which is the main purpose of protected function.
If you have other points on this, please post, so we can discuss it further.

[ertanden]

@igorgladkov thanks for the fix. If not very tricky to implement I would prefer to have the "reversed behavior" on protected and pin secured switches, since you also agree that it makes more sense. While it's not a common use case, I believe me and a few other people may benefit from that. Maybe you can keep this issue as a low priority one.

Thanks again.

[igorgladkov]

@ertanden My point was mainly of why would someone want to combine protected and pin? What additional benefits "protected" state gives in that case?

[ertanden]

@igorgladkov When PIN protection is once entered correctly, it's not asked again for password (until refresh I guess?). So, suppose you activate a switch, it asks for PIN, enter PIN correctly and then pressing on the switch deactivates it immediately. Instead having a protected pin would allow a time to cancel operation.

I would like to secure my switches (with pin), but also would like to prevent accidental activate/deactivation, like manually activating the Siren etc...

It's your call, but I believe this may be a pretty common use case especially for alarm related switches etc.

By the way, while not exactly the same thing alarm panels has sort of this pin+protected behaviour. When you enter PIN to activate alarm, a timer of 30 seconds starts to count and then after 30 seconds the alarm is activated. It gives you time to leave the house and lock the door before alarm activates. Maybe you can add a "timeout" parameter to protected switches, which we can use to implement this behaviour.

Just brainstorming... :)