Niko Home Control II

If you have Ubuntu, please check the status of your firewall with:

sudo ufw status verbose

In your case, sending hex 44 to 192.168.1.255 on port 10000 should give a reply like this:

… … … … … … C0 A8 01 10 FF FF FF 00 19 02 01 02 00 03 00 02 00 E3 22

It’s actually kind of impossible that your system running Openhab returns a packet with 02 as the value of the 16th byte :slight_smile:

private void setIsNhcII(DatagramPacket packet) {
    byte[] packetData = packet.getData();
    int packetLength = packet.getLength();
    // The 16th byte in the packet is 2 for a NHC II Connected Controller
    if ((packetLength >= 16) && (packetData[15] >= 2)) {
        this.isNhcII = true;
    } else {
        this.isNhcII = false;
    } 

You can easily check this yourself with Packetsender (https://packetsender.com/download) on Windows or Linux.

@Mherwege , maybe it’s possible to add other checks for NHC2, although I think your method should just work. In case the system running Openhab has 2 (or more configured) IP addresses in a different subnet, the right one can be determined by checking from which subnet there is an active connection to port 8080 (webinterface Openhab). We can assume that one has an active connection when configuring/installing the NHC binding right?

Another approach of finding the controller is checking the Mac address with ARP. I think all Niko devices start with 00:11:2A:xx:xx:xx but I can only verify this for my 550-00003 controller

Also, on a NHC2 device, multiple TCP ports are open. I cannot tell if this is the same on a NHC1 controller:

22,80,3579,3580,5060,5061,8001 and most importantly, port 8883 for the encrypted MQTT communication. This could be another extra check, just to be sure.

Btw, I discovered that sending the 0x44 UDP packet on port 5353 gives the same reply as sending it on port 10000 :wink:

Very nice that they basics voor nhc2 are working! I’ll now have a look when I can upgrade my installation to nhc2. Good job!

Hello,
Nhc2 binding can not control blinds yet? I
am looking to obtain gateway to upgrade to Nhc2, but the blinds are necessary for me.
Thank you.

@fcela, Niko Home Control 2 can control blinds, the binding in development cannot yet.

We are still looking for people with energy devices in their setup. Based on the parameters currently known to us we could probably get this kind of info from the coco:

ModelType (or EnergyModelType)
MacAddress
Channel
MeterType
FlowType
Segment
PulsesPerUnit
ClampType
ShortName
GasVolume
WaterVolume
ElectricalEnergy
ElectricalPower
ReportInstantUsage

For example, the mqtt payload for the live energy usage:

payload {“Method”:“devices.status”,“Params”:[{“Devices”:[{“Properties”:[{“ReportInstantUsage”:“True”}]
payload {“Method”:“devices.status”,“Params”:[{“Devices”:[{“Properties”:[{“ElectricalPower”:“526”}]

As this is “live” data (Electrical Power = 526Watts), we should be able to gather this info and process it in Openhab. Historical data like energy readings over a certain timespan are presumably saved in the Niko Core (cloud). So whenever you consult this kind of info, an encrypted connection is made through the touchscreen or the android/ios app.

Mark,

Great work, thx! Where can i download the new binding? dropbox link nog longer works… kr, Nicolas

We are running some final tests for the switches and dimmers. @Mherwege has done some initial work on the thermostats for nhc2 but we have not been able to test this yet.

We hope to be able to support:

  • switches
  • dimmers
  • thermostats
  • all on/off functions (with autoupdate=false integrated in the code so you can configure it as a pushbutton)
  • functions that are triggered by PIR sensors (same principle as all on/off function)
  • mood control pushbuttons (toggle the moods (sferen) that are created in the NHC2 software) More Info
  • notifications in NHC programming software (channel triggers for creating rules for push and informative messages) More Info
  • energy readings (live power readings with eventually data gathered over time in a database)
  • shutters

We are still looking for people with the following:

  • shutters
  • moods (sferen) programmed in their setup
  • gas/water meters

It would help a lot if you could help us provide the necesarry logs.

Please pm me if you want to help.

I still have NHC I, but the moods aren’t a special thing. They are just actions, which you probably connect to multiple lights/sockets. I also have the mood control, but this is just a display where you can toggle different actions. A mood can also just be one light eg. I don’t think this way of working is changed in NHC II.

I have just upoaded a new version ready for further testing. @bccrew has been a very big help in testing the alpha version of this binding. We had some challenges, but I hope we are getting closer. I still don’t have NHC II myself, so I very much depend on all of your testing and giving feedback.

What has been programmed:

  • on/off lights
  • dimmer lights
  • all off and scenes (as push buttons), whereby scenes have not specifically been tested
  • notifications
  • thermostats, initial implementation needs full testing

The up-to-date README is here.

You can download the latest binding jar here.

To reach feature parity with the NHC I functionality in the binding I am looking for someone willing to spend time providing inputs (logs) and testing the binding with rollershutters.
A nice extension beyond NHC I functionality, and already on the radar, is energy measurements.

I have energy measurements for water, gas and electricity (including solar power). Also have “sferen”. Also have thermostats. But I do not have a working OpenHAB system :slight_smile:

I’ll try to setup a RPI with Openhabian. Maybe the hypervisor layer does something weird in the virtual machine and that is way it is not working (installed Openhab on an ESXi VM). Had the same issue with v1.

If I get it working, I’ll provide some logs.

Installed Openhab 2.5.0-SNAPSHOT on fresh Ubuntu 18.04 VM. Installed latest jar file. Discovery is instant so this is working (including an alarm and event channel). However an error occurs (openhab.log & events.log):

2019-01-08 00:05:49.786 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '192.168.0.192' with clientid 192_168_0_192-nikohomecontrol_bridge2_443b00ee363d-public and file store '/var/lib/openhab2/nikohomecontrol/192_168_0_192-nikohomecontrol_bridge2_443b00ee363d-public'

2019-01-08 00:05:50.296 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '192.168.0.192' with clientid 192_168_0_192-nikohomecontrol_bridge2_443b00ee363d-profile and file store '/var/lib/openhab2/nikohomecontrol/192_168_0_192-nikohomecontrol_bridge2_443b00ee363d-profile'

2019-01-08 00:05:54.641 [hingStatusInfoChangedEvent] - 'nikohomecontrol:bridge2:443b00ee363d' changed from INITIALIZING to OFFLINE (COMMUNICATION_ERROR): Niko Home Control: error starting bridge connection

org.eclipse.smarthome.io.transport.mqtt.MqttException: MqttException with reason 32000
	at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NhcMqttConnection2.startPublicConnection(NhcMqttConnection2.java:153) ~[?:?]
	at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.lambda$0(NikoHomeControlCommunication2.java:126) ~[?:?]
	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) [?:?]

@cwegh Could you switch on TRACE logging for the binding? I hope to be able better locate the source of the problem with it.

I see something remarkable in the INFO messages. The first part of the clientid should be the IP address of the machine running openHAB. But that can’t be the same as the address of the machine connecting to (the CoCo). That, however, is what is being logged. I believe we had something similar before when the discovery did not work for you. Could this be specific to running it in a VM?
I am using a very simple java function to get the address of the current host, so don’t see where that can go wrong. To get the address of the CoCo, I use the source address of the packet sent from the CoCo in response to the UDP discovery broadcast message. The only thing I can think of is that that address is the VM host address, rather than the CoCo address, if the VM host does some network magic. I have little experience with VM’s.

The MQTT Exception points to a timeout. This is very likely if we are trying to do the connection to the wrong IP.

Mark,

in that case the function is not working that well. In my tests the first part of the clientid is also the coco IP address.

2019-01-07 13:35:54.717 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to '192.168.1.16' with clientid 192_168_1_16-nikohomecontrol_bridge2_443b00xxxxxx-public and file store '/var/lib/openhab2/nikohomecontrol/192_168_1_16-nikohomecontrol_bridge2_443b00xxxxxx-public'

On the other hand, the timeout seems like another (network) problem. @cwegh Can you perform a tcp probe on port 8883 on 192.168.0.192 from your Ubuntu server to see if you can reach the MQTTS port?

You can install nmap with apt-get install nmap and perform the following command from your Openhab server.

nmap -p 8883 -v 192.168.1.192

Are you using bridge mode or NAT mode for your esxi? Because NAT mode will give the VM it’s own IP address from your DHCP server.

@bccrew @cwegh
Forget about my observation. It was an error in the code on my side. It will be fixed in the next version. This still should not impact the workings of the binding though, so there must be another reason for the timeout. A full TRACE log would be helpful.

I’ll check tonight. The VM has its own IP directely from the DHCP server.

Hi,

With the thermostat in my installation, I get the following error and my installation won’t connect anymore with the latest jar.

2019-01-08 18:41:36.534 [DEBUG] [l.nhc2.NikoHomeControlCommunication2] - Niko Home Control: adding thermostatdevice Thermostaat Living 2019-01-08 18:41:36.567 [ERROR] [ansport.mqtt.internal.ClientCallback] - MQTT message received. MqttMessageSubscriber#processMessage() implementation failure java.lang.NumberFormatException: For input string: "15.50" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:?] at java.lang.Integer.parseInt(Integer.java:580) ~[?:?] at java.lang.Integer.valueOf(Integer.java:766) ~[?:?] at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.updateThermostatState(NikoHomeControlCommunication2.java:511) ~[?:?] at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.devicesListRsp(NikoHomeControlCommunication2.java:391) ~[?:?] at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.processMessage(NikoHomeControlCommunication2.java:674) ~[?:?] at org.eclipse.smarthome.io.transport.mqtt.internal.ClientCallback.lambda$3(ClientCallback.java:90) ~[201:org.eclipse.smarthome.io.transport.mqtt:0.11.0.201901030053] at java.util.ArrayList.forEach(ArrayList.java:1249) ~[?:?] at org.eclipse.smarthome.io.transport.mqtt.internal.ClientCallback.messageArrived(ClientCallback.java:90) [201:org.eclipse.smarthome.io.transport.mqtt:0.11.0.201901030053] at org.eclipse.paho.client.mqttv3.internal.CommsCallback.deliverMessage(CommsCallback.java:499) [200:org.eclipse.paho.client.mqttv3:1.2.0] at org.eclipse.paho.client.mqttv3.internal.CommsCallback.handleMessage(CommsCallback.java:402) [200:org.eclipse.paho.client.mqttv3:1.2.0] at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:206) [200:org.eclipse.paho.client.mqttv3:1.2.0] 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:1142) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?] at java.lang.Thread.run(Thread.java:745) [?:?]

@Mherwege: log file in attachment. It seems to go in CONNECTED state, but when the binding wants to add a thermostatdevice a MQTT implementation error occurs. The same one as @blatruwe

2019-01-08 20:35:44.071 [DEBUG] [l.nhc2.NikoHomeControlCommunication2] - Niko Home Control: adding thermostatdevice Thermostaat badkamer
2019-01-08 20:35:44.072 [ERROR] [ansport.mqtt.internal.ClientCallback] - MQTT message received. MqttMessageSubscriber#processMessage() implementation failure
java.lang.NumberFormatException: For input string: "20.50"
	at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) ~[?:?]
	at java.lang.Integer.parseInt(Integer.java:580) ~[?:?]
	at java.lang.Integer.valueOf(Integer.java:766) ~[?:?]
	at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.updateThermostatState(NikoHomeControlCommunication2.java:511) ~[?:?]
	at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.devicesListRsp(NikoHomeControlCommunication2.java:391) ~[?:?]
	at org.openhab.binding.nikohomecontrol.internal.protocol.nhc2.NikoHomeControlCommunication2.processMessage(NikoHomeControlCommunication2.java:674) ~[?:?]
	at org.eclipse.smarthome.io.transport.mqtt.internal.ClientCallback.lambda$3(ClientCallback.java:90) ~[204:org.eclipse.smarthome.io.transport.mqtt:0.11.0.201901030053]
	at java.util.ArrayList.forEach(ArrayList.java:1257) ~[?:?]
	at org.eclipse.smarthome.io.transport.mqtt.internal.ClientCallback.messageArrived(ClientCallback.java:90) [204:org.eclipse.smarthome.io.transport.mqtt:0.11.0.201901030053]
	at org.eclipse.paho.client.mqttv3.internal.CommsCallback.deliverMessage(CommsCallback.java:499) [200:org.eclipse.paho.client.mqttv3:1.2.0]
	at org.eclipse.paho.client.mqttv3.internal.CommsCallback.handleMessage(CommsCallback.java:402) [200:org.eclipse.paho.client.mqttv3:1.2.0]
	at org.eclipse.paho.client.mqttv3.internal.CommsCallback.run(CommsCallback.java:206) [200:org.eclipse.paho.client.mqttv3:1.2.0]
	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) [?:?]

trace_cwegh_20190108.txt (82.7 KB)

@bccrew: nmap works

Starting Nmap 7.60 ( https://nmap.org ) at 2019-01-08 20:01 CET
Initiating Ping Scan at 20:01
Scanning 192.168.0.192 [2 ports]
Completed Ping Scan at 20:01, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 20:01
Completed Parallel DNS resolution of 1 host. at 20:01, 0.00s elapsed
Initiating Connect Scan at 20:01
Scanning 192.168.0.192 [1 port]
Discovered open port 8883/tcp on 192.168.0.192
Completed Connect Scan at 20:01, 0.00s elapsed (1 total ports)
Nmap scan report for 192.168.0.192
Host is up (0.00056s latency).

PORT STATE SERVICE
8883/tcp open secure-mqtt

@cwegh @blatruwe I just loaded a new version at the same place that should fix this. Remember I don’t have NHC II, so very few means to test. Chances are we may need a few more iterations before it works entirely. Thank you for trying this out.

Same error. No problem, we all want the same :wink:

@cwegh Are you sure? Exactly the same error doesn’t sound likely, for the simple fact that that code in the error message is not there anymore in the version I loaded here.