It works! Awesome job 
2023-02-11 21:04:15.781 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SkalsikringHjemNiko_Alarm' changed from DISARMED to PREARMED
2023-02-11 21:06:15.790 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SkalsikringHjemNiko_Alarm' changed from PREARMED to ARMED
2023-02-11 21:07:16.394 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SkalsikringHjemNiko_Alarm' changed from ARMED to DISARMED
Hi Thomas. I loaded another version. This time, the alarm thing has 4 channels (corresponding to what you requested). You will have to recreate the thing as channel names have changed. This may also be a bit more rough still, as I couldnât test it myself. Fingers crossed.
Hi Mark. All channels seems to be working as intended. I will test more when setting up HomeKit and Google Assistant on the channels. However Iâve noticed that the âTarget Stateâ string says âOffâ while âStateâ string says âDisarmedâ. I believe it would be better if these either both used âOffâ or âDisarmedâ as the string value. Given that they are string, it would make sense to use âDisarmedâ 
Done, and a new version posted.
Note that the target state string channel now can also be used to arm/disarm.
I made the armed switch channel a contact channel. That is the better way for read only binary channels. However, this may make Google Home integration less easy. Let me know.
Hi Mark
The way I see it will be, is that Google will be able to arm and disarm, but wonât be able to tell if it was successful or not, as the switch for the arming will be âOnâ from the moment you press it. So to Google it would seem successful, but NHC might still be trying to arm it.
The only way to solve this, the way I see it, would be to have the armed switch channel be a switch channel again, but should turn back to âOffâ after being set to âOnâ for arming, until that it is successfully armed and then switch back to permanently âOnâ. This way the switch will only be âOnâ if it was successful. Itâs not pretty and I donât believe it would be the right thing to do.
Iâm not sure why the developers of Google Assistant for OpenHAB chose only to have one switch channel and not two: One for arming and one for checking if it was successful. HomeKit does this, which is what the two string channels are for.
What are your thoughts?
I think the whole issues stems from the unclarity in OH between switch and contact item types. In principle, a switch can be controlled, a contact cannot. A switch can be on/off, a contact can be open/closed, which corresponds to on/off. Different developers have made different decisions on what to use at different points in time. My understanding is GH choose to use a switch channel for the target state.
I can go back to a switch for the target state, and that will make Google Home happy. It just does feel less natural, because you cannot directly control it.
I turned the armed channel in a switch channel again. I think that should now satisfy GH. Have a try with the new version loaded.
Hi Mark
The switch for target state must also be able to arm the alarm. When turned on it should send âOnâ signal to NHC and then turn itself back to âOffâ in OpenHAB and then only go back to âOnâ state when NHC has successfully armed the alarm. This is the only way we can fully satisfy Google Homeâs ability to check if the arming was successful. NHC does not behave as a typical alarm would, where it would fail and stop trying to arm the alarm. NHC keeps trying to arm it until successful. This is not how Google Home expect, from what I understand.
So:
If we go with a switch for target state, that when turned on it starts arming the alarm and while doing so it switches back to off in OpenHAB. This way Google Home will âarmâ that switch channel and when checking back after a configured delay, Google will see if it is indeed turned to âOnâ to determine if it was successful. If it is still âOffâ Google Home will see it as failed. However NHC might still be trying to arm it. When NHC is successful arming the alarm, Google Home might be in an inconsistent state until Google Home refreshes. This will only work if you are able to accomplish this more complex behavior.
So the more simple and probably also more reliable option, is if we go with a contact for target state and instead uses the request state switch, Google Home will be able to arm it and will just always assume it was successful, even though NHC is trying to arm it in the background. Google Home will first see the alarm is off when the alarm is indeed turned off in NHC.
If you provide a version that can accomplish the complex behavior as well as a version that uses the contact approach, I can test both versions to see what works best. Let me know your thoughts and we can agree on the proper path to take
Edit: Perhaps it would indeed be best to keep the binding simple and let users solve the complex behavior needed by using a custom item with rules. Let me know your thoughts
Hi Thomas,
Can you check with the version I just loaded? It still has the same channels, but the armed channel can now be used to turn on/off the alarm. When you turn on through this channel, the state should not change immediately, as needed for GH integration. There is no fundamental change to the code, except making the channel read/write and triggering the same command as the control channel. That one will update immediately (and should also update almost immediately when using the armed channel to arm).
Hi Mark
Homekit: It definitely works as expected. However we do get a warning in the console when arming the alarm through Homekit.
2023-02-19 21:33:23.669 [WARN ] [ssories.AbstractHomekitAccessoryImpl] - Wrong value PREARMED for CurrentSecuritySystemState characteristic of the item SkalsikringHjemNikoAlarm_DetailState. Expected one of following [STAY_ARM, ARMED, NIGHT_ARM, DISARMED, ALARM]. Returning DISARMED.
âSkalsikringHjemNikoAlarm_DetailStateâ is the Alarm State string channel.
However this is not a problem and the functionality is as expected, as Homekit should treat the current state as âDisarmedâ when in pre-arm mode, as the target state is different. When they are different, HomeKit will show the state as âActivatingâŠâ and that is what we want. When turning off the alarm there are no warning, as the current state will go straight from âArmedâ to âDisarmedâ which are known states to Homekit. The reason for this is simply that Homekit does not know of the âPrearmedâ state, as this is not defined (nor possible) the the available states of Homekit.
Google Assistant I need to do some more testing. I have some naming convention that I need to figure out. The alarm from Niko shows up as a scene in Google Home and not as a security system, so I have to figure out the best way for me to name them, so they are read-friendly in the Niko app and voice-friendly in Google Assistant, but without having the same name, as Google seems to prioritize the scene rather than security system, when they have the same name. Thanks Niko⊠
Hi 
A new version of NHC II has just been released and there are changes to the API:
Management of APIs and connected services in the programming software instead of via mynikohomecontrol.niko.eu
https://guide.niko.eu/display/NSM/Release+notes+version+2.17.1+Windows
Are you aware of any compatibility issues?
Edit: Perhaps itâs just the actual management of it and not API or MQTT calls 
Hello, pls my Hobby API key expired, and now I canât generate a new one or refresh. Itâs nowhere on the screens available here: https://mynikohomecontrol.niko.eu/
Can anyone pls check and see whether you have this available? Thanks
Not aware of any issue, but I did not try anything yet. I would expect this just allows managing the connected services on the programming software application, rather than doing it on the web.
I also donât see a button or function to create a new key, but my key hasnât expired yet. It still shows the old key and links to the documentation.
I took the jump and updated NHC II to the latest version. I also updated OpenHAB (OpenHABian tried to update to 4.0 for some reason, so I had to wiggle my way back to branch version 3!). I am still using the .jar file you created for me. Have the changes been merged into the official release yet?
You probably have to update to the latest version on your controller. Using the software on your computer you can now manage your API key within the Niko Home Control programming software.
No, they havenât. There is still a PR outstanding for review. The reviewer didnât get it done before the 3.4 release and then it moved on the backburner as more work goes into OH core. Once that one is reviewed, I still have other things in the pipeline. I hope that will all be done by the time we are getting to a 4.0 release. Just keep using the jar for now.
Thank you all, I actually did update while looking for the option, even went to âManage connected servicesâ, but didnât see the âwell hiddenâ Hobby API. Thanks for point me back. Iâm back online
Just a quick headsup:
There is a new Home Assistant integration under active development. You can check it out here:
I have seen that and I follow it from a distance. So far, I have not seen much there that is not possible with OH. I think there are areas where the OH code can do more. Good to see HA is getting better at this as well.
