Type Security System is not reacting on changes from openHAB

[EjvindHald]

I have tested the security system, and it is working fine, when a change is done in the Homekit app.

However, if the change is initiated from openHAB the app just displays 'Activating...' This would be the case if the security system changed state as a part of the original intended usage for that system - eg. keypad or similar.

It is working fine both ways in openHAB native Homekit add on , and there is more about that here

I am submitting this, because I would like to transfer all my items to Homebridge, so I am no longer dependent on native openHAB support. Thanks.

[EjvindHald]

After having used the Security System now for 24 hours, I get a lot of “No response” on this item only in the Homekit app. All other items respond as normal.

[steilerDev]

Could you please elaborate a little bit more and share your configuration, steps to reproduce and debug log of home bridge?

[EjvindHald]

I am on vacation, so I cannot share the configuration. But I simply created 4 new Switch items in openHAB and made them visible in sitemap. These 4 new switches called HomebridgeHomeItem, HomebridgeAwayItem, HomebridgeSleepItem and HomebridgeAlarmItem was then connected to the security system using config.json. Then it is quite easy to see the changes of openHAB states.

By following that approach it is easy to see that change from the iPhone works fine, but if you change anything from openHab it is not working. And I still encounter 'No response' from that particular item on my iPhone. The rest of the items in Homebridge is responding immediately with no problems.

[EjvindHald]

Instead of creating log files, I suggest that you simply create new Switch items in openHAB and then connect these to the Accessory in openHAB Complete. Then it is much easier for you to get the info needed. So far I have these obervations:

Accessory type lock, garage and security does not react properly on a change in the underlying openHAB item.

Accessory type valve does not react properly on a change initiated from Homekit.

In these 4 situations, the Homekit app displays "Locking...", "Activating..." or similar and it never finalizes.

The types security and valve has been implemented in native openHAB binding and they are working correct there, so a change can be initiated from both openHAB and Homekit app without problems.

Thanks.

[steilerDev]

These are two distinct "problems":

Tackling the easy one, which is expected behavior: Lock, Garage and Valve are all kinds of CurrentState and TargetState, both are cached by homebridge. Therefore if you change the state of the item in openHAB, you only change the CurrentState but not the cached HomeKit value of TargetState. The animation for "Locking...", "Activating..." etc. is based on the difference between TargetState and CurrentState. Therefore if you change the CurrentState without affecting the TargetState (which is only possible through the HomeKit system) you will see those UI elements.

If you change the value in openHAB it will show "Locking...", then you can completely quit the Home.app and relaunch it, to then see the "Locked" state (because if HomeKit requests the TargetState from homebridge, my plugin will serve the CurrentState in this case).

Now to the security system. This has always been a tricky item, due to the multi-item nature and the lack of multi state items in openHAB. Changing the values to a valid state and then relaunching the Home.app should work. Everything else is very hard to realize within homebridge. If you have suggestions on how to solve this problem, feel free to let me know!

[EjvindHald]

It seems that the TargetState can be modified outside Homekit app. In this thread arachnetech writes: "As discussed in the pull request, your suggestions were very helpful. I was wrong in my belief that target state couldn't be changed outside HomeKit. The Home App doesn't like to show it when it changes, but closing and re-opening it does show a new externally-set target state. Version 1.0.15 now supports external setting of target states for garage door and security system."

Also see this pull request for an example of implementation. Both of these are using the Homebridge framework like your solution does.

You have implemented Security System with mulitple switches to represent multiple state items. Another method could be to have simply to strings called CurrentSecuritySystemState and TargetSecuritySystemState. The current state would then contain one of the values STAY_ARM, AWAY_ARM, NIGHT_ARM, DISARMED or TRIGGERED. The target state should be modifed by a openhab rule and contain one of these values STAY_ARM, AWAY_ARM, NIGHT_ARM or DISARM. This has been implemented in native openhab Homekit, and it is working fine. See this link

[steilerDev]

@EjvindHald thanks for your input, I think from an openhab-complete standpoint I should implement the string based approach, in order to support your linked pull request. However I am currently very busy and barely keeping up fixing 'real' issues for this project, therefore I am not quite sure when I will get around working on this (as well as the other issues marked as 'enhancements'). If you want to, feel free to propose a pull request :) Otherwise I want to apologize in advance.

[EjvindHald]

@steilerDev - thanks for your reply. Unfortunately, I do not know how to do this, so I guess it will have to be done by someone else. Also, see this link for a discussion about the same. It is also implemented as a string solution with the status from Homebridge.

[steilerDev]

Based on your input I reworked the Security System with my latest commit (2fd07f0) to use a single String item within OpenHAB, this simplifies my logic massively and resolves your issue. Feel free to test it.

Now that all issues should be resolved, I guess I'll push this state to npm later, if I don't run into any problem resetting my HomeKit to my production environment :)

[EjvindHald]

Thank you very much. Well, I do not know how to test this if it is not in npm😗 From npm I install it in my Docker.

[steilerDev]

No worries, about to release, just need to adjust docs and everything. If there are any remaining issues, just open a new one or reopen this one :)

[EjvindHald]

Since you closed this issue opened by me, I cannot re-open it.

The Security System is rather complex, and you need to expose both CurrentSecuritySystemState and TargetSecuritySystemState exactly as I wrote in this thread. TargetSecuritySystemState will be modified by an openHAB rule. Otherwise, the Security System will not work.

From the documentation it seems you have just exposed one string, and I guess that is current state.

Thanks.

[steilerDev]

I mapped Current and Target State to the same String object. Since in theory one of them is reading and one is writing combining them does not seem to cause a problem. It works well for me, even changing from openHab the correct state is instantly reflected in the Home.app

Have you tried it and ran into any problems? This fox is part of my released 1.0.0 from yesterday.