[nikohomecontrol] Support for accesscontrol action

[toonvl]

I have a doorlock and niko doorbell with videophone ( 550-22001) connected to our niko home control II system. This is controllable in the app, but I would like to be able to link this to openHAB as well so I can control it via homeKit. I have tried sending the corresponding MQTT message, based on the API, and this works fine. I however cannot add it in openHAB as the action type is currently not supported.

Environment

openHAB 3.2 with Niko Home Control Binding
running in Docker container openhab/openhab latest ( OpenJDK Zulu 11.52.13 ) on Docker 19.03.15
running on a rPI 3B+ running raspbian Bullseye

[mherwege]

@toonvl I have included access control in a development branch of the Niko Home Control binding. It should create access control things with 2 channels, the bell and the door lock. I have no access control devices, so cannot test myself, but if you are willing to test, you can download the compiled .jar version here.

This development version has new functionality for NHC I energy and for NHC II access control. I need it tested before I can submit this for review. I have no testers so far for access control. Also, there is still a pending PR with thermostat improvements. These enhancements build on top of that, so I will only submit if the previous PR has been reviewed and the enhancements have been tested.

If you are OK with this, please test the development version specifically for access control and let me know how it goes. Chances are there are still issues. Provide debug logs if there are issues and I will try to resolve.

[toonvl]

Hi @mherwege, thanks! I'm trying to test, I've now installed 3.3.0 snapshot on my pc. I have put the file in the addons folder, but I can't see it in openhab. Do you have an idea of what I'm doing wrong?

[mherwege]

Hi @toonvl . The location looks right to me. You may have to install the mqtt binding as wel to make it work. To check if the binding is active, use bundle:list and search for niko in the karaf console.
Also see what happens in the log.
Does discovery not come up with niko things?

[mherwege]

@toonvl Please download the jar file again (same link) and try once more. I had a bug introduced in the binding because of some refactoring that blocked everything but the bridge from being added. Things were discovered, but failed starting when being added.

[toonvl]

Hi @mherwege I keep getting the following issues, before and after starting over from an empty folder and unpacking 3.3.0-SNAPSHOT again, installing mqtt binding and then adding the jar file when openhab is shut down.
I can add the Niko Home Control II Bridge, I fill in the IP address, the API token, but then on save I get COMMUNICATION_ERROR and in the console I get the following errors:

io.reactivex.exceptions.UndeliverableException: The exception could not be delivered to the consumer because it has already canceled/disposed the flow or the exception has nowhere to go to begin with. Further reading: https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0#error-handling | java.util.NoSuchElementException: No value present
at io.reactivex.plugins.RxJavaPlugins.onError(RxJavaPlugins.java:367)
at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:69)
at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.util.NoSuchElementException: No value present
at java.base/java.util.Optional.get(Optional.java:148)
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.updateAccessState(NikoHomeControlCommunication2.java:663)
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.updateState(NikoHomeControlCommunication2.java:503)
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.devicesListRsp(NikoHomeControlCommunication2.java:289)
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.processMessage(NikoHomeControlCommunication2.java:960)
at org.openhab.core.io.transport.mqtt.internal.Subscription.processMessage(Subscription.java:85)
at org.openhab.core.io.transport.mqtt.internal.Subscription.lambda$1(Subscription.java:81)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at java.base/java.util.concurrent.ConcurrentHashMap$KeySpliterator.forEachRemaining(ConcurrentHashMap.java:3566) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:408)
at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:736)
at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:661)
at org.openhab.core.io.transport.mqtt.internal.Subscription.messageArrived(Subscription.java:81)
at org.openhab.core.io.transport.mqtt.internal.Subscription.messageArrived(Subscription.java:66)
at com.hivemq.client.internal.mqtt.mqtt3.Mqtt3AsyncClientView.lambda$callbackView$1(Mqtt3AsyncClientView.java:76)
at com.hivemq.client.internal.mqtt.MqttAsyncClient$CallbackSubscriber.onNext(MqttAsyncClient.java:303)
at com.hivemq.client.internal.mqtt.MqttAsyncClient$CallbackSubscriber.onNext(MqttAsyncClient.java:288)
at com.hivemq.client.rx.FlowableWithSingle$SingleFutureSubscriber.onNext(FlowableWithSingle.java:406)
at com.hivemq.client.internal.rx.operators.FlowableWithSingleCombine$SplitSubscriber$Default.tryOnNextActual(FlowableWithSingleCombine.java:235)
at com.hivemq.client.internal.rx.operators.FlowableWithSingleCombine$SplitSubscriber.tryOnNext(FlowableWithSingleCombine.java:200)
at io.reactivex.internal.operators.flowable.FlowableObserveOn$ObserveOnConditionalSubscriber.runAsync(FlowableObserveOn.java:649)
at io.reactivex.internal.operators.flowable.FlowableObserveOn$BaseObserveOnSubscriber.run(FlowableObserveOn.java:176)
at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:66)
... 6 more
Exception in thread "RxComputationThreadPool-2" io.reactivex.exceptions.UndeliverableException: The exception could not be delivered to the consumer because it has already canceled/disposed the flow or the exception has nowhere to go to begin with. Further reading: https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0#error-handling | java.util.NoSuchElementException: No value present
at io.reactivex.plugins.RxJavaPlugins.onError(RxJavaPlugins.java:367)
at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:69)
at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.util.NoSuchElementException: No value present
at java.base/java.util.Optional.get(Optional.java:148)
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.updateAccessState(NikoHomeControlCommunication2.java:663)
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.updateState(NikoHomeControlCommunication2.java:503)
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.devicesListRsp(NikoHomeControlCommunication2.java:289)
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.processMessage(NikoHomeControlCommunication2.java:960)
at org.openhab.core.io.transport.mqtt.internal.Subscription.processMessage(Subscription.java:85)
at org.openhab.core.io.transport.mqtt.internal.Subscription.lambda$1(Subscription.java:81)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at java.base/java.util.concurrent.ConcurrentHashMap$KeySpliterator.forEachRemaining(ConcurrentHashMap.java:3566) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:408)
at java.base/java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:736)
at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:661)
at org.openhab.core.io.transport.mqtt.internal.Subscription.messageArrived(Subscription.java:81)
at org.openhab.core.io.transport.mqtt.internal.Subscription.messageArrived(Subscription.java:66)
at com.hivemq.client.internal.mqtt.mqtt3.Mqtt3AsyncClientView.lambda$callbackView$1(Mqtt3AsyncClientView.java:76)
at com.hivemq.client.internal.mqtt.MqttAsyncClient$CallbackSubscriber.onNext(MqttAsyncClient.java:303)
at com.hivemq.client.internal.mqtt.MqttAsyncClient$CallbackSubscriber.onNext(MqttAsyncClient.java:288)
at com.hivemq.client.rx.FlowableWithSingle$SingleFutureSubscriber.onNext(FlowableWithSingle.java:406)
at com.hivemq.client.internal.rx.operators.FlowableWithSingleCombine$SplitSubscriber$Default.tryOnNextActual(FlowableWithSingleCombine.java:235)
at com.hivemq.client.internal.rx.operators.FlowableWithSingleCombine$SplitSubscriber.tryOnNext(FlowableWithSingleCombine.java:200)
at io.reactivex.internal.operators.flowable.FlowableObserveOn$ObserveOnConditionalSubscriber.runAsync(FlowableObserveOn.java:649)
at io.reactivex.internal.operators.flowable.FlowableObserveOn$BaseObserveOnSubscriber.run(FlowableObserveOn.java:176)
at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:66)
... 6 more

I keep the Niko Home Control II Bridge on my 'main' openHAB 3.2.0 installation on the RPI disabled while testing this.

[mherwege]

@toonvl I fixed that error. Try again with the new version, same link as before.
You don't need to disable the bridge on your RPi. In my experience, it works fine with multiple instances of OH talking to the same controller. I do that continuously for testing. Also, while this is compiled as 3.3.0-SNAPSHOT, it should work in a 3.2.0 install. You would just have to uninstall the release binding and copy this one in the add-ons. If I have not made mistakes, it should fully pick up your previous configuration. However, if there are thermostats in your install, you may want to recreate these, as they have been enhanced with additional channels (should still work as before if you do not do this).

[toonvl]

@mherwege I think the problem was running it on a machine with Java 15 instead of 11. I have now installed it on a Mac with Java 11 installed (Zulu build of OpenJDK). Everything is working well on there, I can add the bridge, add the lights, add the access control. I have created things for a light, the access control doorbell and lock. When testing the doorbell and lock however, nothing happens.

I have checked the MQTT topics and I saw that only changing the doorbell state give a command message

{
	"Method": "devices.control",
	"ErrCode": "",
	"ErrMessage": "",
	"Params": [
		{
			"Devices": [
				{
					"Name": "",
					"Uuid": "965cca05-d160-4d58-8191-3c7ad86c328f",
					"Technology": "",
					"Identifier": "",
					"Model": "",
					"Type": "",
					"Online": "",
					"Properties": [
						{
							"BasicState": "Triggered"
						}
					]
				}
			]
		}
	]
}

with the following error message:

{
	"ErrMessage": "Failed to set property 'BasicState' to 'Triggered' for device '965cca05-d160-4d58-8191-3c7ad86c328f'",
	"Method": "devices.control",
	"ErrCode": "INTERNAL_ERROR"
}

when you ask the API for the devices list this is how the access control device looks like:

{
	"Online": "False",
	"Traits": [],
	"Name": "Toegangscontrole",
	"Model": "accesscontrol",
	"Type": "action",
	"Uuid": "965cca05-d160-4d58-8191-3c7ad86c328f",
	"PropertyDefinitions": [
		{
			"Doorlock": {
				"HasStatus": "true",
				"CanControl": "true",
				"Description": "Choice(Open,Closed)"
			}
		}
	],
	"Identifier": "5c22afec-048b-4cbc-8e74-697551481b5a",
	"Technology": "nikohomecontrol",
	"Parameters": [
		{
			"Action": ""
		},
		{
			"LocationName": "Thuis"
		},
		{
			"LocationIcon": "general"
		},
		{
			"ButtonId": "00112a6529c0_001"
		},
		{
			"Ringtone": "Suburbia"
		},
		{
			"IconCode": "entering"
		},
		{
			"DeclineCallAppliedOnAllDevices": "true"
		},
		{
			"LocationId": "674631d1-8c0b-4a88-a7d6-f42cc454de9e"
		}
	],
	"Properties": [
		{
			"Doorlock": "Closed"
		}
	]
}

So for some reason my device is missing the BasicState property, it is in the API documentation however. Do you know if we could do something with that button id somehow?

The MQTT command message that works for me is:

{
	"Method": "devices.control",
	"Params": [
		{
			"Devices": [
				{
					"Uuid": "965cca05-d160-4d58-8191-3c7ad86c328f",
					"Properties": [
						{
							"Doorlock": "Open"
						}
					]
				}
			]
		}
	]
}

But currently the lock channel is not sending out any messages to the controller. I do see events in the events log, but no specific warnings or errors in the openhab log. Do you have any idea why the lock channel is not sending out MQTT messages?

[mherwege]

@toonvl Did you test with the updated version I posted 4h ago? There was an issue with mixing basicState and doorlock properties in my code before.
Reading the api documentation again, the basicState property for accesscontrol device type has a different meaning than for bellbutton device type. For accesscontrol, it is only available with a ring-and-come-in guided action, not the standard access action. Sending "triggered" to such an action would switch ring and come in on/off. For the bellbutton action, it is representing the bell. That's unfortunate. If I can't find a way to also get the bell event, I cannot use the same code for both types. The doorlock should work though, if not, it needs fixing.
I am not sure I can do anything with the ButtonId. I don't think I see events from these buttons. You can try switching on trace logging and pushing the physical bell button, to see of something appears in the logs, but I doubt it. I believe I only see events from actions in NHC, not from the buttons themselves.

[toonvl]

@mherwege I am using the latest version, to be sure I downloaded it again now, and replaced it, but it still has the same effect.
The door is currently not set to ring-and-come-in, maybe that's why the basicState property is missing in the parameters.
To me the most interesting is of course the doorlock property, would be great if we can get that working as well. I don't see anything in the logs or in the console indicating some error though. If there is anything I can check to give you clues, just let me know.

[mherwege]

@toonvl I found another bug, the doorlock channel was not correctly updated. There is a new version loaded.

For further feedback:
I don't expect to see many errors in the logs. But the trace log could give an indication where it fails. My code should send the message to unlock the door exactly as you showed. If it doesn't work, the full sequence of log entries at the moment of trying to unlock the door would be helpful.
And what is in the logs if you unlock the door at the door itself? From the Niko app? I expect to see an event for unlocking and one more for locking again in the log, and the doorstate should update for a while.

I understand unlocking is the most important part. However, I don't want to put something in the code that is half baked. Making the lock work is the first step. I may reconsider the structure afterwards. It would be best if we could always have the bell signal, but that may not be possible.

[toonvl]

@mherwege I definitely agree in getting it right! I'm glad to test.

I have installed the latest version from dropbox, but still the same result. I can't see any of the commands from the Niko app, it must be using a different way of communication.

I have set the log level for niko home control to TRACE and have first switched the state of a light a few times and then the lock:

Changing the lamp:

21:25:51.354 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item '0VERDIEPLampbureau_Vermogen' changed from OFF to ON
21:25:51.365 [TRACE] [ol.nhc2.NikoHomeControlCommunication2] - not acted on received message topic hobby/control/devices/cmd, payload {"Method":"devices.control","ErrCode":"","ErrMessage":"","Params":[{"Devices":[{"Name":"","Uuid":"29c25581-ac05-4c28-a2e6-1565bbac3c51","Technology":"","Identifier":"","Model":"","Type":"","Online":"","Properties":[{"Status":"On"}]}]}]}
21:25:51.552 [TRACE] [ol.nhc2.NikoHomeControlCommunication2] - received topic hobby/control/devices/evt, payload {"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"Status":"On"}],"Uuid":"29c25581-ac05-4c28-a2e6-1565bbac3c51"}]}]}
21:25:51.553 [DEBUG] [mecontrol.internal.protocol.NhcAction] - update channel state for 29c25581-ac05-4c28-a2e6-1565bbac3c51 with 100
21:25:51.556 [DEBUG] [ol.nhc2.NikoHomeControlCommunication2] - setting action 29c25581-ac05-4c28-a2e6-1565bbac3c51 internally to ON
21:25:52.053 [INFO ] [openhab.event.ItemCommandEvent       ] - Item '0VERDIEPLampbureau_Vermogen' received command OFF
21:25:52.055 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item '0VERDIEPLampbureau_Vermogen' predicted to become OFF
21:25:52.058 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item '0VERDIEPLampbureau_Vermogen' changed from ON to OFF
21:25:52.061 [DEBUG] [.handler.NikoHomeControlActionHandler] - handle command OFF for nikohomecontrol:onOff:443b00eeb1cc:29c25581-ac05-4c28-a2e6-1565bbac3c51:switch
21:25:52.062 [DEBUG] [rol.internal.protocol.nhc2.NhcAction2] - execute action Off of type RELAY for 29c25581-ac05-4c28-a2e6-1565bbac3c51
21:25:52.063 [DEBUG] [rnal.protocol.nhc2.NhcMqttConnection2] - connection state CONNECTED for 192_168_0_239-nikohomecontrol_bridge2_443b00eeb1cc
21:25:52.064 [DEBUG] [rnal.protocol.nhc2.NhcMqttConnection2] - publish hobby/control/devices/cmd, {"Method":"devices.control","ErrCode":"","ErrMessage":"","Params":[{"Devices":[{"Name":"","Uuid":"29c25581-ac05-4c28-a2e6-1565bbac3c51","Technology":"","Identifier":"","Model":"","Type":"","Online":"","Properties":[{"Status":"Off"}]}]}]}
21:25:52.071 [TRACE] [ol.nhc2.NikoHomeControlCommunication2] - not acted on received message topic hobby/control/devices/cmd, payload {"Method":"devices.control","ErrCode":"","ErrMessage":"","Params":[{"Devices":[{"Name":"","Uuid":"29c25581-ac05-4c28-a2e6-1565bbac3c51","Technology":"","Identifier":"","Model":"","Type":"","Online":"","Properties":[{"Status":"Off"}]}]}]}
21:25:52.269 [TRACE] [ol.nhc2.NikoHomeControlCommunication2] - received topic hobby/control/devices/evt, payload {"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"Status":"Off"}],"Uuid":"29c25581-ac05-4c28-a2e6-1565bbac3c51"}]}]}
21:25:52.271 [DEBUG] [mecontrol.internal.protocol.NhcAction] - update channel state for 29c25581-ac05-4c28-a2e6-1565bbac3c51 with 0
21:25:52.272 [DEBUG] [ol.nhc2.NikoHomeControlCommunication2] - setting action 29c25581-ac05-4c28-a2e6-1565bbac3c51 internally to OFF
21:25:57.410 [DEBUG] [overy.NikoHomeControlDiscoveryService] - getting devices on 443b00eeb1cc
21:26:07.128 [DEBUG] [NikoHomeControlBridgeDiscoveryService] - discovery broadcast on 192.168.0.255
21:26:07.158 [TRACE] [rnal.protocol.NikoHomeControlDiscover] - bridge discovery response 443B00EEB1CCC0A8008AFFFFFF0019020102000D0001005400
21:26:07.162 [DEBUG] [rnal.protocol.NikoHomeControlDiscover] - IP address is /192.168.0.138, unique ID is 443b00eeb1cc
21:26:07.670 [DEBUG] [NikoHomeControlBridgeDiscoveryService] - NHC II bridge found at /192.168.0.138

Changing the lock status:

21:26:49.349 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Toegangscontrole_Lock' received command ON
21:26:49.383 [DEBUG] [.handler.NikoHomeControlAccessHandler] - handle command ON for nikohomecontrol:access:443b00eeb1cc:965cca05-d160-4d58-8191-3c7ad86c328f:lock
21:26:57.440 [DEBUG] [overy.NikoHomeControlDiscoveryService] - getting devices on 443b00eeb1cc
21:27:07.678 [DEBUG] [NikoHomeControlBridgeDiscoveryService] - discovery broadcast on 192.168.0.255
21:27:07.689 [TRACE] [rnal.protocol.NikoHomeControlDiscover] - bridge discovery response 443B00EEB1CCC0A8008AFFFFFF0019020102000D0001005400
21:27:07.691 [DEBUG] [rnal.protocol.NikoHomeControlDiscover] - IP address is /192.168.0.138, unique ID is 443b00eeb1cc
21:27:08.197 [DEBUG] [NikoHomeControlBridgeDiscoveryService] - NHC II bridge found at /192.168.0.138
21:27:57.473 [DEBUG] [overy.NikoHomeControlDiscoveryService] - getting devices on 443b00eeb1cc

For the lock I'm missing the rol.internal.protocol.nhc2.NhcAction2 and ol.nhc2.NikoHomeControlCommunication2 lines

[mherwege]

What is the status of the item when you give the command? It may be an issue with mapping from on/off to open/closed. I can only give an open command, so it could be it is mapped the wrong way around.

[toonvl]

It's always 'Closed'. When I send the command via MQTT it switches to 'Open' for 5 seconds and then goes back to 'Closed'

in the event topic /hobby/control/devices/evt:
11:55:07PM
{"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"Doorlock":"Open"}],"Uuid":"965cca05-d160-4d58-8191-3c7ad86c328f"}]}]}
11:55:12PM
{"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"Doorlock":"Closed"}],"Uuid":"965cca05-d160-4d58-8191-3c7ad86c328f"}]}]}

So Closed is the normal state in the controller. If you mean in openHAB, I've tried waiting for more than 5 seconds and then switching again, but that gives the same

What I do notice is that I indeed see only something in the logs when changing from OFF to ON. Maybe you can try to change the logic to make it do something when changing from ON to OFF. Maybe that could give a clue?

[mherwege]

@toonvl I think I found the problem. I didn't correctly interpret the feedback I received from the Niko Controller, leaving the door unlocked all the time in the eyes of OH. That should be solved, and you should now see the door locked (switch true) when it is locked, hence giving a command would switch it to on, which is unlocked. Fingers crossed this is the last issue on this part. Then we can look at what to do with the bell. A new version is uploaded.

[toonvl]

@mherwege the lock is now working as expected. Default state locked is now ON in OH and it sends the command if switched to OFF, and state is following properly, switching back to ON when the lock status changes again. I'm just not sure if I would have switched them around, with locked being OFF in OH and ON in OH meaning unlocked. I'm now trying to install it in my main OH installation and using it in combination with the homekit integration, but I'm having issues with it being recognised. I'll keep you posted. Do I need to change the lock behaviour so we can see if in ring and come in mode it will have the basicstate property as well?

[mherwege]

@toonvl I used the locked = ON convention also used in the Homekit, Google and Alexa integrations. Bindings I looked at with locks also use this convention. And so does NHC itself.
It would be useful to indeed test with ring and come in. However, I think the basicState property will actually be used to enable/disable ring and come in, not for a bell signal. While it could still be useful to integrate this with OH, it still leaves no way to detect the bell. It looks like I will end up with 3 different (but related) thing types, the basic accesscontrol, accesscontrol with ring and come in and last the bellbutton action type that has a bell and lock. You don't see anything in the logs currently when the bell button is pressed? I would very much like to get that signal, as I believe that would be a useful thing to have in OH.

[toonvl]

@mherwege makes sense if that's the convention 😄

I have pressed the bell button and I found these messages in the evt topic:

{"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"CallStatus01":"Ringing"}],"Uuid":"9c1e3c12-79f7-4ff5-80fd-4119fbe63f25"}]}]}
{"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"CallStatus01":"Active"}],"Uuid":"9c1e3c12-79f7-4ff5-80fd-4119fbe63f25"}]}]}
{"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"CallStatus01":"Idle"}],"Uuid":"9c1e3c12-79f7-4ff5-80fd-4119fbe63f25"}]}]}

I think the callstatus can be interpreted like:

• ringing: button is pressed, but no-one has accepted yet
• active: the call is accepted somewhere ( can be touchscreen or mobile app )
• idle: when the call is over

the Uuid is not one that I recognise from the devices list though, it's not the same as the acces control device, so I hope this is enough to work with?

[mherwege]

the Uuid is not one that I recognise from the devices list though, it's not the same as the acces control device, so I hope this is enough to work with?

Interesting. Did you try searching the full log for that Uuid? I am surprised it doesn't show up anywhere else. Without further info, it looks like impossible to link this to the right doorlock. If you are OK with this, you can send me a full log, including a binding start, by private message in the forum.

[toonvl]

@mherwege I don't know how to send you a private message here? Now that I have changed to ring and come in I can see in the events that it is indeed toggling the basicState, but since doing that I can't find the acces control device anymore in the devices list when I send the devices list command in MQTT. I hope they did not remove access in their latest update to the hobby API or something? what do you think?

[mherwege]

t know how to send you a private message here

You can’t here, but you can in the forum (community.openhab.org). My handle is the same.

I would be surprised Niko changed the API. You did not do a controller update, did you? Then it cannot have changed.

[toonvl]

@mherwege I created a user in the community forum with the same handle as well (@toonvl)
It appears my permissions are still limited there as a new member, I don't get the blue message button when I click your user over there. Maybe you can send me one first and I'll be able to reply.
about the update, I changed my configuration with the programmer, and every time you deploy with it, it will check for updates and apply them. So I'm not sure if it did, but it is possible. I can send an e-mail to niko support to check if they made some changes to remove direct access in the hobby API.