Niko Home Control II

Hi Guys

A year ago I installed OpenHAB and connected the Niko Home Control IP interface. Goal would be to read the room thermostats and when above a specific temperature start the Samsung Airco.

Niko went fine, Samsung did not worked out immediately and stopped tinkering. Now with the summer coming I would like to get things going again.

In the meanwhile I switched to a NHC Connected Controller, which is confirmed to be working. I also upgrade the programming to NHC II language.

But now it seems I am not able to get the bridge connected. Behavior I have seen so far:

  1. When using the autodiscovery, it does find an interface, but it always uses the wrong IP address.

  2. Manually changing the IP address in PaperUI is not persistent, it seems not to save of it is overwritten every time.

  3. Sometimes it uses another IP address, and suddenly switching back to the original (never the manual edit).

  4. When deleting the add-on binding, the bridge is still discovered.

  5. When deleting the discovered bridge, it keeps coming back.

  6. Lastly I tried to create a manual things-file, also without any results (no connection)

  7. Finally I removed openhab using apt and reinstalled, but still the same issue.

I use port 8000.

Has anyone experienced this? Or provide any pointers on how to troubleshoot?

Kind regards


@cwegh I don’t expect the binding to work with Niko Home Control II. Unfortunately, as far as I can tell, Niko changed their protocol. Note it also requires another app. As far as I know. NHC II does not work with the NHC I app.
I am already surprised the binding even finds a bridge.
I do think there is something strange going on with your setup though. I think you may have had 2 versions of the binding running. Otherwise I cannot explain the bridge comming back after removing the binding. You could open the Karaf console und run bundle:list to check on that.
It is expected behaviour the IP address may be changed. I noticed when developing the binding the IP address of the interface changed regularly. Therefore discovery runs regularly, or on communication failure, and detects the new IP. To avoid it, you would have to fix the IP for NHC in hour DHCP server. Only then, the fixed IP value in the binding would make sense. You can turn off the regular refresh by setting the refresh interval to 0. The fact it detects the wrong IP for you may mean the new controller creates two IP connections, and the old one is still theree, but not functional anymore. I would need an alternative way to detect the controller.
I don’t have NHC II to try to adapt the binding to it. Without the ability to test myself, I am afraid this will be a tough exercise. I can have a look when I find time. I would need a full debug log of what the binding does. This will then require step by step testing as I try to figure out the new protocol. So no easy and fast process. Expect a major testing load on your side.

Hi Mark, thanks for the response!

Indeed, you need another mobile app and also the programming software is different. No issues there.

After I bit more investigation I can add the following:

  1. The autodiscovered bridge has always the same id: nikohomecontrol:bridge:302e302e302e
  2. The auto discovered bridge uses the IP from the server OpenHAB installed on (didn’t notice this since I use an internal dns name, but with remembering al the IP addresses in my network :slight_smile:)
  3. Can I remove the discovered bridge which keeps popping back from the DB directly? I think it is a stall record from my previous setup which is kept also when reinstalling.

No I have not 2 versions running. Output from bundle:list > 214 │ Active │ 80 │ 2.2.0 │ Niko Home Control Binding

Regarding the IP address, it is a MAC address reservation in my DHCP server, so it would not change. The IP address is also registered in my on-prem DNS server.

I am happy to help get this going, dumping logs and testing is less work then your developing work. OpenHAB currently has no important status in my home, so I can juggle it arround.

I did some further testing and I see in the wireshark trace a TCP payload mentioning allowed methods such as POST, GET etc. on TCP port 3579

Wireshark TCP Payload (stripped info)

Vary Accept
Link summaryxml relapplicationxml
AccessControlAllowHeaders AuthorizationContentType
ContentType applicationjson charsetutf
Server MonoHTTPAPI
Date Sat May GMT
TransferEncoding chunked
KeepAlive timeoutmax


Tried Postman on the IP and port 3579 and got this result

> <html ng-app=app>
>     <head>
>         <title translate=general.title></title>
>         <meta charset=utf-8>
>         <meta name=viewport content="width=device-width, initial-scale=1, maximum-scale=1">
>         <link rel=stylesheet href=/style.css>
>         <link rel=apple-touch-icon sizes=57x57 href=/content/img/favicon/apple-icon-57x57.png>
>         <link rel=apple-touch-icon sizes=60x60 href=/content/img/favicon/apple-icon-60x60.png>
>         <link rel=apple-touch-icon sizes=72x72 href=/content/img/favicon/apple-icon-72x72.png>
>         <link rel=apple-touch-icon sizes=76x76 href=/content/img/favicon/apple-icon-76x76.png>
>         <link rel=apple-touch-icon sizes=114x114 href=/content/img/favicon/apple-icon-114x114.png>
>         <link rel=apple-touch-icon sizes=120x120 href=/content/img/favicon/apple-icon-120x120.png>
>         <link rel=apple-touch-icon sizes=144x144 href=/content/img/favicon/apple-icon-144x144.png>
>         <link rel=apple-touch-icon sizes=152x152 href=/content/img/favicon/apple-icon-152x152.png>
>         <link rel=apple-touch-icon sizes=180x180 href=/content/img/favicon/apple-icon-180x180.png>
>         <link rel=icon type=image/png sizes=16x16 href=/content/img/favicon/favicon-16x16.png>
>         <link rel=icon type=image/png sizes=32x32 href=/content/img/favicon/favicon-32x32.png>
>         <link rel=icon type=image/png sizes=96x96 href=/content/img/favicon/favicon-96x96.png>
>         <link rel=icon type=image/png sizes=192x192 href=/content/img/favicon/android-icon-192x192.png>
>     </head>
>     <body ng-controller=shellController>
>         <div id=navigation>
>             <div id=container class=clearfix>
>                 <img id=nikoBrand src=content/img/niko_logo.svg>
>                 <i id=mobileMenu class="fa fa-bars fa-2x"></i>
>             </div>
>             <ul class=hide-this ng-cloak translate-cloak>
>                 <li ng-repeat="route in model.routes" ng-class="{'active' : isActive(route.originalPath)}">
>                     <a href=#{{route.originalPath}}>
>                         <br>{{ route.menuSettings.label | translate }}
>                     </a>
>                 </li>
>             </ul>
>             <div class=languageSelection ng-cloak translate-cloak>
>                 <span>{{ 'shell.languageChoice' | translate }}</span>
>                 <div class=styledSelect>
>                     <select ng-model=model.selectedLanguage ng-change=changeLanguage() ng-options="language.label for language in model.languages track by language.value"></select>
>                 </div>
>             </div>
>         </div>
>         <div id=page translate-cloak>
>             <div ng-view></div>
>         </div>
>         <script src=app.js></script>
>         <script>
>         $(document).ready(function() {
>             $('#mobileMenu').click(switchNavigation);
>             $('#navigation > ul > li > a').click(switchNavigation);
>             function switchNavigation(){
>                 if($('#navigation > ul').hasClass('hide-this'))
>                 {
>                     $('#navigation > ul').removeClass('hide-this');
>                 }else{
>                     $('#navigation > ul').addClass('hide-this');
>                 }
>             }
>         });
>     </script>
>     </body>
> </html>

@cwegh Indeed, just remove the auto-discovered bridge. IP updating should only happen for this auto-discovered bridge, not for the manually created ones (through PaperUI, or in a file).

Anyway, it will not work for NHC II. In NHC I discovery sends a magic packet over UDP and waits for the response. It then uses a TCP socket to communicate.

I am not sure on what to make from the the wireshark. In NHC I, the communication is over a TCP socket. I believe in NHC II, it uses http. I would need a full wireshark from startup of the app until the app UI is available to start investigating. I hope the communication is not encrypted. Do you need to setup a login for the communication to work locally?

Hi Mark

I keep removing the auto-discovered bridge, but it keeps coming back in the Inbox with the same ID and the IP-address of the OpenHAB server. Very strange.

Regarding NHCII, I’ll see what I can capture. I am not sure it communicates locally. There are 4 ways to interact with the controller which I will capture:

  1. Mobile App: I do not think the mobile app communicates locally, I have the feeling it is mobile app > > connected controller (CC). I’ll see what I can capture remotely on the CC interface using PRTG.
  2. Programming software to the CC (wireshark capture on laptop)
  3. Touch screen to the CC (readout remotely)
  4. The CC diagnose page (web interface on CC)

Where to I drop the capture files?

To be honest, auto-discovery is a nice-to-have. Creating a file with 1 line where to find the CC is as easy and more stable. But offcourse that’s mainly because I use a DHCP MAC reservation offcourse. But it will make the testing easier.

It would be very nice to have the ability to read-out the temperature from the thermostats.



WHi Christof,

I would need a capture of the communication with the mobile app. The binding essentially mimics communication with the app. The way I get this is by installing an Android emulator on a PC (Andy or Bluestacks), install the mobile app in the emulator and use wireshark to capture all communication to/from the controller. Just filter on IP or MAC address. That shows all local communication, and it should be possible to start analyzing from that. You can send a private message to me with the capture, or provide me a link to download somewhere in a private message.
My hope is I mainly need to change the communication protocol, but there is limited change to the message format and content. That remains to be seen though.

It is normal the bridge always appears in the inbox as discovery is running when the binding is installed. You can set to ignore an inbox result and it will not appear anymore. Many people (including myself) need discovery as we do not have the possibility to fix an IP address in the router (Telenet). If you don’t use it, don’t accept the inbox proposal and no bridge thing will be created from it.
What is strange in your case though is that discovery returns your openHAB machine IP. I would like to see an openHAB debug log for the binding to understand why that is. Discovery sends a very specific UDP package and expects a very specific response. It may give me a hint on how to detect a v2 system.

I can look at adding thermostat readouts if I see them appear in a capture with the app.


OK I’ll do that tonight.

How can I generate the debug log regarding the auto-discovery?



In the karaf console: log:set DEBUG org.openhab.binding.nikohomecontrol
Syntax is from the top of my head. You can see current settings with log:list.

So this was challenging. Tried several Android emulators because not all of them were able to have a phone format since the NHC II app is not available on tablet yet. Turned out to use the Android Dev Kit.

However as expected, the mobile app does not communicate locally with the CC. It goes over the internet.

Figured out to use PRTG. No success.

Checked out if I could do a SPAN on the CC port of my switch. It seems it had the capability so that was nice. Mirrored all packages towards my laptop on the physical interface and captured it with wireshark. Showed some interesting results. Capture 4 scenarios:

  1. Standard CC communication with the internet and local network interaction
  2. Using the Touch screen --> this does communicate locally!
  3. Opening Android app on my mobile
  4. Opening the diagnosis webpage of the CC

I’ll send you the wireshark capture and karaf debug log in a PM.




Did you get any wiser on this topic?
I upgraded my controler yesterday and I am regredding it allready.


@Bjorn_Embrechts It doesn’t look easy. I see no possibility for a local communication. It all has to go through their cloud if I want to emulate their app communication. And all that is encrypted. The message format is very different. It does use https, but no REST api with JSON messages.
So, even if we succeed in replicating that communication, there is little I would be able to reuse from the version I binding, which makes it a long development project.
Don’t expect anything in the near future.

I was looking at the app packets aswell but something popped into my head.
What if I connect my server to the connected controller, and to my local network (2 Ethernet connections)
You say the display communicates locally, does that mean we could kinda hack in to that?

@Bjorn_Embrechts We probably could if we could find out the encryption keys. I think the communication between the screen and the controller is encrypted mqtt traffic. There must be an mqtt broker running on the connected controller. When setting up a new screen, I believe you have to select a profile and password, matching a profile set up in the programmer. But there probably also is an application key we do not have.
What could be interesting is a full wireshark when connecting a new screen and selecting the profile to use. If we can derive something from that, we might be able to connect to that mqtt broker.
I don’t think doing something on a multil-homed system would make a difference. You still cannot see inside the encrypted messages. The challenge is connecting. The rest follows.
It would be nicer to build an integration this way, rather than through the Niko cloud. This would still work if the internet is down and is most likely more reactive. A connection to the cloud would require very frequent polling to get immediate status updates, which I don’t like.

Yeah it looks like that… I dont think Niko support will provide that information :stuck_out_tongue:
I guess all I can do is go back to my original idea (before i noticed the TCP packages), using Ethernet Relay modules and NHC pushbutton interfaces… a bit more costly but i only use it for Google assistant and i dont think i’ll ever use more then 8 commands…
Allthough it was cool to ask google to dim the lights to x%… Oh well
Back to the drawing board.

@Bjorn_Embrechts using a SPAN port I’ll capture the data when doing the following.

  1. Remove the current profile and upload the NHC config so the installation has no touch screen
  2. Start capture on the port where the touch screen is connected on
  3. Create new profile and upload the NHC config
  4. Push a light on button and dim a light on the touch screen
  5. Stop capture

I’ll send that capture to Mark so he can have a look.

Hi Guys,

New here, but very interested on how we advance with NHC II. Currently have NHC I working fine together with HomeKit, would love to upgrade to NHC II but waiting confirmation that it actually works…

Thx for the updates on this!


I think I can make the binding work when communicating to the Niko cloud. I have a prototype that should do just that. This is far from ideal though:

  • There is no feedback from the cloud except when the binding would poll the status continuously. This generates a lot of traffic and I am not sure the Niko cloud would not block it after a while. In their app, this is not an issue as it will only do polling when the app is open and for the specific actions on the screen, but as we want to be able to do all sorts of things we need the status to be accurate all the time.
  • Secondly, relying on the cloud means it will not work when the internet is down.

Therefore I would very much prefer a local solution. We have noticed some of the communication with the touch screens uses encrypted mqtt. If we would be able to listen in on that, it may open a lot of possibilities. But we are not there yet, and not sure at all we can make that work.
In summary, if you still have NHC I, I don’t see a reason to rush for NHC II. I am sticking to NHC I myself. Note I have just implemented thermostats in NHC I, which was fairly simple to do. What would you see as the compelling reason to go for NHC II?

Hi Mark,

I’ve installed NHC I last year, in our new house. But I’ve configured it quick & temporary because I knew NHC II was coming. It wasn’t until last week that I knew the potential of openHAB.

So the only (two) reasons to do it right now is so I could update everything and define the setup as it should be and then build the openHAB around it and because I’m planning on installing the touch screens from Niko, and the NHC II interface is a lot “sexier” than the first one.

A little of topic : Is it possible that my NHC ventilation controls are not visible in openHAB?




The ventilation units most likely do not work. Nobody asked for it so far, and I don’t have them.
For NHC I, I should be able to include them if you can send me a debug log from the binding when controlling them from the Niko controls or app.

I understand your feeling about NHC II. I think it is a shame Niko does not provide a documented api and made everything so much more difficult in NHC II. I will myself most likely stick to NHC I.

Hi Mark,

Thanks for that! I’ve tried to debug log the binding, but i don’t know what to listen on…
ive done the following:

log:stet DEBUG nikohomecontrol:bridge

Afterwards, i don’t see any logging changes when i control the ventilation in openhab.log or events.log. Do i need to log on another package name?