Feedback on lock item

[EjvindHald]

Hi

Try creating a lock item in config.json and connect it to a switch item in openHAB. Open a browser pointing to openhab while having your Iphone Homekit also open at the same time.

Now you can lock and unlock using Homekit and it works fine - you should be able to see in the browser that the switch in openHAB goes on and off.

Then try clicking on the switch in browser - which is what would happen if you locked using whatever lock system you may have. Then watch the app, and you will se 'Locking...' or 'Unlocking...' instead of just a switch of lock state as before.

I guess this is not intended.

Thanks!

Ejvind

[neutmute]

I'm playing with using a sonoff SV as garage door opener. The trick I realised is that HomeKit for garage door (and it appears lock too) - sets a target state and expects the mechanism to actuate to conform to the target state. By having an external actor (OpenHab, wireless remote) change the lock/garage door state then the current state of the lock no longer matches the target state and HomeKit decides the lock must be moving toward the state it still expects - hence "opening/closing/locking/unlocking".

The question I came to ask steilerDev about is - can we drive HomeKit from OpenHab? My idea is that once the door sensor is out of sync because someone pressed an old remote control - can we update homekit with a new target state? I tried but it appears that homebridge flow is one way - from HomeKit to openHab item binding.

Or alternatively can the manuMode on Window be used on garage? EDIT: Looking at the source, it appears not as garage is missing the required characteristic - assuming that follows Apple spec

[EjvindHald]

I can confirm that the behaviour of the garage is the same as lock. So it has the same problem.

[steilerDev]

Yes, @neutmute this is exactly the behavior, a little bit frustrating but hard to work around. The way I handle it (and in my opinion it works well enough in practice) is the following: Every time HomeKit starts it will check with the accessory (or in this case homebridge) what the TargetState is. If there is no TargetState stored it will use CurrentState as TargetState. That is also the way manuMode works, it never uses the stored TargetState but always asks for the CurrentState when asked about the TargetState.

I don't know rn if manuMode would be feasible for GarageDoor, however, I currently have very limited time to work on this unfortunately. If you come up with a Pull Request I would be happy to integrate it!

[EjvindHald]

I can see that this is closed, but the problem still remains in the latest version 0.10.2.