Hello,
Thnx for the answers. I use openHab 2.5.1 on iMac. Probably the problem is with the API code. In mynikohomecontrol there is no connection yet with the hobby API. I see i have to solve a riddle but because i don’t know anything about JSON code that is a problem. In the future i will run openHab on a nas server. That’s the reason why i now still use the iMac. Other connections with my audio system
works fine on openHab.
@SCT The release version of the binding does not use the API authentication yet. That’s only in the development version. However, it should not make a difference in functionality.
For the development version, you indeed need to get the question solved. If you search this thread, you will find the answer.
For the release version (installed with openHAB) you need to define a profile with password in the Niko Home Control programming software and put that profile with its password in the configuration. It should work from there as described in the documentation. If it doesn’t, I need logs.
Mark I used the Niko home control touch profile name and password but is still have no connection.
The hub is detected in the inbox when i install the binding. The IP dress is the same as that of the hub.
Do i need to install te MQTT binding also to make is work? Can i reach you by PM?
Thx for your help.
Hey dstammen,
I use Surveillance Station on my Synology to record to Niko VideoDoorbell.
Just added the IP camera with the stream URL, user and password.
Maybe this helps.
Cheers,
Hermke
@wars @bccrew Just to make it visible to all on the forum, we can now confirm the binding does also work with the Niko Home Control Wireless Hub. @SCT has been successful in running the release version of the binding without any modification. Further testing is always welcome to confirm stability.
If you are the proud owner of both a CoCo and a Hub, openHAB will allow you to create a configuration that bridges both to a degree. It is a bit of configuration work, but scenes can work across the 2 with some simple rules.
Nice! I’m planning to upgrade to nhc II before summer and wanted to buy the hub to be able to use the wireless sockets.
This is also very useful info! The only downside is that the doorbell is way too expensive…
Hi Mark
Bridge NHCII
I noticed that the documentations says “token” as a property but when I add the bridge via PaperUI and use the RestAPI, I can see it’s actually “password”.
My bridge is not online, I have an error
2020-04-09 16:03:57.382 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NoSuchMethodError: org.eclipse.smarthome.io.transport.mqtt.MqttBrokerConnection.setTrustManagers([Ljavax/net/ssl/TrustManager;)V
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NhcMqttConnection2.createMqttConnection(NhcMqttConnection2.java:162) ~[?:?]
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NhcMqttConnection2.startConnection(NhcMqttConnection2.java:136) ~[?:?]
at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.startCommunication(NikoHomeControlCommunication2.java:127) ~[?:?]
at org.openhab.binding.nikohomecontrol.internal.handler.NikoHomeControlBridgeHandler.lambda$0(NikoHomeControlBridgeHandler.java:81) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Can I provide you with extra information? Could my current version of openhab be the problem (openHAB 2.5.0~M4-1 (Milestone Build))?
OK, should have updated first but I’m hesitant as with every update I have a bunch of problems (and yet again :-)).
Updated to 2.5.3, got this error
2020-04-09 17:58:27.678 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.nikohomecontrol-2.5.3-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.nikohomecontrol [76]
Unresolved requirement: Import-Package: org.eclipse.smarthome.io.transport.mqtt
It was solved after I installed another MQTT binding but that should not be necessary, I presume? Now the niko binding works!
It looks like you still have a snapshot binding in your addons folder. You can remove that and just install the normal way. The release code (2.5.3) has the latest code. That also corresponds to the documentation.
Thanks for the correction in the doc by the way.
I kept password as the field name because that would avoid errors when upgrading, although a reconfiguration (to use tokens) is required. If I would have dropped password and added token, you would have to remove and rediscover the bridge.
You are correct, I was still using the snapshot. Changed that!
I struggled anyway 
, still used 8883 as port in my things-file. Took quite some time before I remembered that the hobby api works with 8884. The penny dropped rather quickly for token/password as I configured it but could not see the token in the paper-ui.
No problem for updating the documentation. This binding is the center of my openhab and thus the center of my home-installation. Really glad this binding exists! Happy I can be a (really small) part of this binding.
@Mherwege & others
How long are others able to get inputs from the energymeter every 2 seconds? My maximum was never longer than a day. There were simply no more updates coming.
I noticed updates (“ReportInstantUsage”:“True”) every 25 seconds. I guess that the nhc binding. I’m wondering, maybe because it’s overlapping the previous period of 30 seconds reporting the controller can’t handle it? Somebody from Niko in this topic perhaps that can confirm this?
2020-04-11 12:10:12.076 [vent.ItemStateChangedEvent] - Thermostaat_Setpoint changed from 16.0 °C to 16.82 °C
2020-04-11 12:10:12.238 [vent.ItemStateChangedEvent] - Thermostaat_Setpoint changed from 16.82 °C to 16.0 °C
Is this something you have control over in the binding? It would be nice to have .5 decimals and a “correct” rounding of numbers.
(Actually it’s is strange from Niko that the thermostat is able to show 0.1 precision on the screen itself but only is returning 0.5 precision in the api. Does anybody know the reason for that?)
Energymeter: I implemented this on an original request of @bccrew. I don’t know if he has it running. Anyway, This is very much lacking on the Niko site. They have this in their API because it is also the way they get the data for their energy graph in the touchscreen. But that is only visible as long as you are on that page, so does not need constant refreshing. If you want to log energy usage in OH you obviously need a continuous stream. I used a 25s trigger to not have gaps. That seemed to work, but I don’t have an energymeter myself, and didn’t hear anything further back from @bccrew. In theory, if you get data every 2s, you should be able to calculate an energy consumption value (energy level x 2s and sum over the day). But this could be better provided from the API (consumption from start of day) as well, and should be more accurate. Niko is aware of the gap, but I have not heard anything on a solution from them.
Thermostat: I was looking at the code, and it is not impossible there is some error in the code. Could you set the binding to DEBUG level and get me some logs? I may be only setting integer values instead of float values.
I don’t know why the Niko docs state the values are in 0.5° events. I didn’t check and I don’t do any correction. In NHC 1, you actually sent integer values 10 times the value, so 0.1° increments. Its worth trying if it really needs these 0.5° increments. It could be a way to reduce traffic coming from NHC.
I’m still moving my system to the 2.5.1 so I need to do some further testing again with the Energy Meter. Hopefully in the next week.
I’m writing my values to influxdb, there I’m retrieving my values, filling the unknown values with linear values. I have to say this comes really close to reality. So 2 seconds update are really not necessary. I do agree with you, I’m missing some extra options from Niko or some extra request in the api. Hopefully they add them in the future. Instead of 30 values within 2 seconds, I would like to have 1 value every 30 seconds or every minute.
As they are working towards a connection with the smart meters from the grid operators, I do hope that they will not stop developing for their own energy modules.
Interesting to hear some feedback from @bccrew as soon he has the time.
Here’s my log, I have 2 thermostats:
2020-04-12 10:43:55.706 [DEBUG] [ler.NikoHomeControlThermostatHandler] - Niko Home Control: handle command 17.42 °C for nikohomecontrol:thermostat:Eegene:Slaapkamer_Thermostaat:setpoint
2020-04-12 10:43:55.712 [DEBUG] [nternal.protocol.nhc2.NhcThermostat2] - Niko Home Control: execute thermostat overrule 174 during 360 min for bf2cf06f-2eb1-490f-a09c-cb48752c3c96
2020-04-12 10:43:55.749 [DEBUG] [ler.NikoHomeControlThermostatHandler] - Niko Home Control: handle command 17.42 °C for nikohomecontrol:thermostat:Eegene:Keuken_Thermostaat:setpoint
2020-04-12 10:43:55.753 [DEBUG] [nternal.protocol.nhc2.NhcThermostat2] - Niko Home Control: execute thermostat overrule 174 during 360 min for d6558df5-bae5-4d5b-aea1-a012819ad1ed
2020-04-12 10:43:56.009 [DEBUG] [l.nhc2.NikoHomeControlCommunication2] - Niko Home Control: setting thermostat bf2cf06f-2eb1-490f-a09c-cb48752c3c96 with measured 215, setpoint 170, mode 3, overrule 170, overruletime 360, ecosave 0, demand 0
2020-04-12 10:43:56.013 [DEBUG] [trol.internal.protocol.NhcThermostat] - Niko Home Control: update channels for bf2cf06f-2eb1-490f-a09c-cb48752c3c96
2020-04-12 10:43:56.053 [DEBUG] [l.nhc2.NikoHomeControlCommunication2] - Niko Home Control: setting thermostat d6558df5-bae5-4d5b-aea1-a012819ad1ed with measured 230, setpoint 170, mode 0, overrule 170, overruletime 360, ecosave 0, demand 0
2020-04-12 10:43:56.058 [DEBUG] [trol.internal.protocol.NhcThermostat] - Niko Home Control: update channels for d6558df5-bae5-4d5b-aea1-a012819ad1ed
Thanks for this. I will have a look one of the next days.
@Dries_V I think I have found the problem with the setpoint update. My current code always rounds to the closest integer value, which were 0.1° steps in NHC I, but 1° steps in NHC II.
I have now changed it to 0.1° steps for NHC II as well. I know the Niko documentation says it should be 0.5° steps, but I think it is worth trying what the API will do with 0.1° steps. I created a new jar you can find here: https://www.dropbox.com/s/dc13yhi9o1nnjn9/org.openhab.binding.nikohomecontrol-2.5.4-SNAPSHOT.jar?dl=0.
Could you give it a try before I submit a PR? Uninstall the binding from PaperUI and drop the new version in the addons folder.
If it absolutely needs rounding to 0.5°C steps, I will adapt to it, but let’s first try this.
Hi
Tested it.
2020-04-14 00:22:05.125 [DEBUG] [nal.protocol.nhc2.NhcMqttConnection2] - Niko Home Control: publish hobby/control/devices/cmd, {"Method":"devices.control","ErrCode":"","ErrMessage":"","Params":[{"Devices":[{"Uuid":"d6558df5-bae5-4d5b-aea1-a012819ad1ed","Properties":[{"OverruleActive":"True"},{"OverruleSetpoint":"22.3"},{"OverruleTime":"5"}]}]}]}
But it seems the api overwrites it with 0.5 precision steps.
2020-04-14 00:22:05.312 [DEBUG] [l.nhc2.NikoHomeControlCommunication2] - Niko Home Control: received topic hobby/control/devices/evt, payload {"Method":"devices.status","Params":[{"Devices":[{"Properties":[{"OverruleActive":"True"},{"OverruleTime":"5"},{"SetpointTemperature":"22.50"},{"OverruleSetpoint":"22.50"}],"Uuid":"bf2cf06f-2eb1-490f-a09c-cb48752c3c96"},{"Properties":[{"OverruleActive":"True"},{"OverruleTime":"5"},{"SetpointTemperature":"22.50"},{"OverruleSetpoint":"22.50"}],"Uuid":"d6558df5-bae5-4d5b-aea1-a012819ad1ed"}]}]}
I would say, leave the code as it is. It works with 0.5 steps. If niko ever changes their api to 0.1 precision, your code is ready for it!
Thanks for your work!
Thanks for testing. I created a PR.
Hi all,
great to see there is still a lot of testing and developing going on around here.
I have another question or feature request (if not already made possible).
Could it be possible to execute an REST API Post command (to my Unifi switch, to PoE powercycle the switchport my Touchscreen3 is connected to) from pressing a NHC button?
Or any other command/script …
Or maybe it can be done simpler: pressing NHC button to send MQTT command to restart the Touchscreen3 device
I sometimes have issues with this device saying it’s not connected, and it won’t connect untill I reboot it entirely (or PoE powercycle the switchport it’s connected to).
With kind regards,
Harm
Yes, that should be possible with the “Virtual Output” functionality. You can add a new Free start/Stop action and it will get a new UUID within the NHC environment and in Openhab ofcourse.
Add a Virtual Output player and give it a name
This step is optional if you don’t have a free button or you don’t want to use a real Niko pushbutton on your wall. It will still create a virtual button in the NHC app and a new UUID to use in Openhab.
Add a connection to an external system player.
Create a new Start/Stop action where you either use a real button (player) or the player that you created in step 2.
Openhab will detect the new function and it is ready to use.
Basically pushing this button now won’t do a thing, unless you use it in Openhab to capture the input and bind a rule to it, for example the REST API call to cycle your POE port on the switch.
This kind of buttons can also be used to do anything else you want! Couple with a zwave device, start or stop anything you want!! 
