Niko Home Control

Hi

thanks i am going to collect the logs.

I have been extending the binding to support Niko Home Control II. In doing so, I had to refactor the rollershutter code for Niko Home Control I to keep a single interface. The behavior should not have changed for Niko Home Control I, but I cannot test that myself as I do not have rollershutters.
I am looking for testers to test rollershutters in the current development version of the binding, you can download from here to confirm I did not break anything.
If things do not work as expected, please turn on trace logging and send me the log file. If it works, let me know as well please.
@Serrrano @YannicVH I know you have rollershutters. Could you have a go at this?

@Mherwege
Hi
no problem i am going to test it
version 2.5.0 from 26.2 is for NHC I version ?

thanks

@Serrrano This is for both Nhc I and II, so yes, the correct jar.
One thing I forgot to mention, as the binding now requires the mqtt transport (for nhc II) to be installed. When the binding gets merged, this will be automatic. For testing, you will need to install it. The easiest way is to install the mqtt binding. That will take care of it.

Hi Mark,

i have tried to use google home with NHC 1 using myopenhab cloud service. It seems google home requirements are the Lights should have “Lighting” tags (Official Google Assistant Integration for openHAB) to be populated for google home.
Maybe other items should have other tags as well (https://www.openhab.org/docs/ecosystem/google-assistant/).
Please would it be possible to add tags for automatically generated switch (lights) items?
Even writable tags would help a lot.
Tags for NHC items are read only now and it seems this is the reason i can’t see them at google home control.

I have tried to edit Tags using REST API but got readonly error message :frowning:

Thanks for any effort regarding this.
Marek

The item definition for homekit, alexa or google have nothing to do with the binding. You need to set this in the item file as below. All three use the same item definition as defined here for homekit. I use alexa with myopenhab cloud and homekit with the below tags without any issue. Since you mention the rest api I suspect you do not use item files, I suggest to start with this because it will make the maintenance a lot easier.

Switch Gang "Gang"  [ "Lighting" ] {channel="nikohomecontrol:onOff:440e003a366a:27:switch"}

Thank you for your proposed solution. I am using PaperUI and so my item file is empty.
I have 200+ actions/items in NHC so you propose to generate item file from scratch?
Any automatic process to do so? To manually edit items files is a process I would like avoid to do for any change in the future.
Thanks for any hint.

@fcela You probably have simple mode enabled, to avoid having to create items. You will need to disable simple mode en create the items manually in PaperUI (if you don’t want to use text files). You should then be able to add tags through the REST interface. This is what I did in my system and it works.

Hi Mark,
if i see correctly, the paperUI items will not be reflected to the item “files”, but just to the json db.
Doesn’t matter if simple mode is enabled or not.
So if I want to add tags, i have to manually create items (as .items files) and add tags for the items to be populated to the google assistant.
I have tried several items and it is working, but not really manageable for my 200 items.

@extric99 I can use rest api but i will got readonly error for every item generated by paperUI.
Any idea?

@fcela If simple mode is on in PaperUI, there will only be items automatically generated in memory and read only. They will not get stored in jsonDB at all. If you switch off simple mode, you can define your items in PaperUI and link them to the things or create them in an items.file. The ones created in PaperUI will get stored in the jsonDB. For the ones created in paperUI, you can use the REST interface to add tags. In the items file, you can add it straight away.
Using simple mode is in general not adviced. So I think you would still be better off creating the items manually, while using the autodiscovered things.

@Mark,

i have tried your proposed solution several times. Do not know what could be wrong:

The only items with tags are those I have created manually in items file.
Thanks once more.

@fcela This works for me:

curl -X PUT --header "Content-Type: application/json" --header "Accept: application/json" "http://openhabianpi.local:8080/rest/items/Licht_Eetkamer/tags/Lighting"

Just replace the hostname and itemname.

@mark, please check the output:

abcd@openmediavault:~# curl -X PUT --header “Content-Type: application/json” “http://localhost:8080/rest/items/BedroomShutter/tags/Lighting
abcd@openmediavault:~# curl -X GET --header “Content-Type: application/json” “http://localhost:8080/rest/items/BedroomShutter
{“link”:“http://localhost:8080/rest/items/BedroomShutter",“state”:“99”,“stateDescription”:{“pattern”:"%s",“readOnly”:false,“options”:[]},“editable”:false,“type”:“Rollershutter”,“name”:“BedroomShutter”,“label”:"Bedroom Shutter 1”,“tags”:[“Blinds”],“groupNames”:[]}

Please note the item is not readonly, but is not editable
Any idea why the item is note editable?
I think this could be the problem

It could indeed be the problem. In my case, it show as editable (for a dimmer, I don’t have shutters).
Are you sure the item is not also left somewhere in an items file? Maybe defined twice? Items from items files would not be editable. Maybe try clearing the cache to see if that makes a difference.

since a couple of days I receive the following warning (exactly every minute)

[WARN ] [ikoHomeControlBridgeDiscoveryService] - Niko Home Control: discovery not possible, no broadcast address found

I didn’t changed anything in my NHC config. All actions are still working in openHAB, but I don’t like the warning :slight_smile:

@wars It looks like the binding does not get a response anymore on the magic packet send from the binding to discover the controller. What version of openHAB do you run? What binding version? Can you still use the Niko app with local connection (NHC I), or are you on NHC II already? The magic packet is also used by the NHC I app (or the touch panels in NHC I and II). Any chance there is a change in your network that would filter this packet? Does the issue persist when you restart the binding (or openHAB)?

Restart of openHAB solved it. I remember that I had a power outage this weekend, so this was probably the issue

@Mherwege does the binding supports the 0-10V analog sensor (https://www.niko.eu/nl-be/artikel/550-00230) ?

I’m going to connect a pressure sensor to this module to check the level of my rainwatertank. I don’t have the hardware yet, so I can’t test it yet.

@wars The binding only works with the actions you define in the Niko Home Control programming software. An analog sensor can be part of one or multiple conditional action (e.g. if value < 100 …) and therefore trigger an action. That action can be seen in OH.
In NHCII, it may actually be possible to see the sensor state changes through the API. Therefore, it may be possible to make the sensor value available in OH. That is currently not supported in the code, and I cannot promise it will work. I would need to see logs to know for sure.