Try putting the actionId in quotes. I have changed the type to string for NHCII and didn’t see an impact when testing. But I didn’t try textual config.
Thanks, it solved the problem! Actually I should have know it, because the error pointed in that direction…
btw, I also changed some onOff thing types to ‘pushButton’. Was there a special reason to implement these stateless actions in another way?
@wars For consistency with nhcII again. If you ‘push’ AllOff (or the same would apply for a scene I think), there really is no state change. Pushing AllOff a second time would do the same thing. So ideally you don’t get the state change in openHAB (autoupdate = false). It just pushes it through to Niko if you trigger from the openHAB side. If you trigger from the Niko side, openHAB should do nothing with it (so no state change).
Hmm, I have some strange behaviour.
I had a working bridge, dimmers, buttons etcetera… I thought I had some problems because my bridge stayed offline (eventually it was a stupid error in my LAN setup).
I tried to remove my bridge and add it again. It was after a while that I found the error in my LAN setup. My bridge was back online but I noticed all the dimmers and other things were not working anymore, although they show the status “online”.
I guessed it had to do with my new bridge so I removed a dimmer and added it again via the inbox where the dimmer showed up again.
It’s still not working. Immediately after I add the dimmer via the inbox, the status is online, when I switch the dimmer to On it shows the error “Niko Home Control: actionId 5e0a1093-2d12-4e82-922c-142d97a884d8 does not match an action in the controller”
Huh? I just added it to my system via the automatic discovery in the inbox, so the actionID must be right, no? Furthermore, I can find that ID in the logs of my Niko APP on my android phone, so it must be right no?
Can somebody help me? Do I have to delete some folder with some cache or something? Is there a way I can debug this further and give some extra information?
(Running OH 2.4 with the downloaded JAR file above)
Please clean your logs in /var/log of equivalent on windows and run a full startup of OH. Then post your logs here. Put the binding in debug mode too if you want.
This morning, the Niko Home Control hobby API went live. Binding will get adapted soon after testing.
2 Likes
42 is the answer, isn’t it?
Nice! I need to make some time/money to upgrade to NHCII
I’m curious if it will be possible to integrate other mqtt stuff in NHC.
Never mind, got it
Hi,
To try the API, I use MQTT.fx software but if I use credentials connection can not be established and if I don’t use them, I can connect too the broker but no published topic works.
I join bellow the configuration pages of the MQTT.fx app. Can you please help me to find my mistake ?
Thanks
The IP address is the one I use to access Niko Home Controler Dashboard, bus communication, components and system log pages.
The password is the one given in the Niko Hobby API webpage.
If I don’t provide any credential information, I can connect to the broker but when I susribe to # I only recieve public/system/evt topic and no published topics works.
The file is the one downloaded from the Niko Hobby API webpage
Hi, first the broker port is 8884 and try to subscribe to example ‘hobby/control/devices/cmd’. See page 11 of the documentation page.
Good luck, Bjorn
In the OpenHab2 MQTT Broker configuration page where can we define the certificate file ?
I am happy you already are able to connect.
Unfortunately, the structure of the messages does not make it easy to use out of the box with the mqtt binding. An action in Niko Home Control is not represented by a mqtt topic. Mqtt is rather used in a request/response way instead of a publish/subscribe way. It would require a lot of rules to make it work, logic that already exists in the binding. The binding uses the mqtt api internally.
The current niko home control binding internally already uses the full content of the api, as published by Niko. I have a development version that already enhances it with some of the features I had not covered before. @bccrew has been testing with it.
The one thing missing is the change in authentication. The current way supported in the binding should still work, but I will replace it with the new way. You will then have to provide your password and certificate. It is a small change to the binding, but I don’t have much time at the moment, so it may take a few weeks.
Hi Mark,
please could you clarify this for me?
Unfortunately it is not clear enough, if I can or can’t upgrade my Niko Home Control I installation from 1.17 (NHC I) sw to 2.5 sw (NHC II) version. I have only Niko Home Control IP-interface (550-00508) at my site right now, nothing else (no gateway nor connected controller).
Is it necessary to add Connected controller to my site?
Would I be able to use your binding after sw upgrade at my site?
Are there any benefits using NHC II instead of NHC I?
I have openhab cloud connector connected into Google Home for remote control of the site right now.
Thanks.
@fcela You will not be able to use Niko Home Control II with your hardware. Only the latest connected controller can be upgraded if not yet on NHC II. In all other cases you would have to replace the power supply, controller and IP interface. I have done that, but there is absolutely no need if you are happy with your system.
The programming of NHC II is somewhat easier. And Niko extends NHC II functionality on a regular basis, not NHC I.
It is my understanding the main reason for requiring a new controller in NHC II, is extra memory in the controller. The new software does not fit on the old controller. NHC II still works with all components that also work for NHC I.
I extended the binding to work for both NHC II and NHC I. As I have personally moved on, I will need to depend on NHC I users if anything breaks on NHC I side for testing fixes. I have no intention dropping NHC I from the binding.
Thanks Mark, i have found the same in the meantime 
.
Thanks for explanation regarding NHC II benefits as well.
So there is no reason to move on right now at least.
Just one more question regarding your binding.
Is there a possibility to fulfill the item tags when auto-discovery of items happend in the binding?
I have some issues when trying to use the items in google home/assistant through openhab cloud connector. I’m using the PaperUI right now.
There are strict requirements to fill up the item tags to be visible for google assistant.
The Google assistant supports the following tags right now:
(Official Google Assistant Integration for openHAB)
[“Lighting”]
[“Switchable”]
[“CurrentTemperature”]
[“Thermostat”]
[“Blinds”]
I had to manually generate the .item file and put the required tags to do so.
It is not the best approach, especially when changing the configuration in NHC sometimes.
Thank for any hint regarding this.
Can you tell me the answer for the hobby api?