openHAB2 IHC binding

[Pauli Anttila]

Update 12.3.2019:

Binding has been merged to openHAB main repository and will available in 2.5 version. Before that, new version can be found from official openHAB snapshot builds.

Before official add-on documentation page is updated, binding documentation can found here.

 

NOTE. If you have used older beta versions of the binding, beware that there has been some breaking changes lately:

• Controller address parameter is not anymore ip, but hostname
• "-channel" suffix is removed from channel types. E.g. switch-channel is just switch.

 

###########################################################################################################################

 

Even openHAB 1 IHC binding has been rock solid for many years, I finally decided to port the binding to support openHAB 2 features.

Latest version: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.ihc/2.4.0-SNAPSHOT/

Documentation link

Some improvements / features:

• By default, binding create channels automatically from project file (currently all dataline_inputs, dataline_outputs, airlink_inputs, airlink_outputs and resource_temperature).
• Auto creation can be disabled, and channels can be created manually (then all resource id's are supported).
• Support both Paper UI and thing files configuration.
• Channels for basic controller information (state, SW and HW version, controller uptime, etc).
• Trigger channels support (button short press, long press and extra long press).
• Support multiple controllers (those who have e.g. two controllers environment).

 

 

[Pauli Anttila]

Hi @Kandersen,

Automatically created channels can't be edited, but you can keep createChannelsAutomatically=true and then add additional channels with extra options via PaperUI or by things file. This is actually how I use it.

[Kandersen]

24 minutter siden, Pauli Anttila skrev:

Hi @Kandersen,

Automatically created channels can't be edited, but you can keep createChannelsAutomatically=true and then add additional channels with extra options via PaperUI or by things file. This is actually how I use it.

Okay, so one way or another, I will have to create the channels, if they require additional settings, (which I believe most channels will do).
Hopefully I´ll get some time to test it very soon now. 

[Kandersen]

Hi @Pauli Anttila

I wonder if it would be possible to run 2 x openhab (on two seperate servers) connecting to the same (one) IHC controller ?
I know I may be pushing the IHC controller to its limit, but I have an spare Rpi, and I was thinking about making a new openhab 2.4 (M6) setup, and test your latest binding on that.

[Pauli Anttila]

18 hours ago, Kandersen said:

I wonder if it would be possible to run 2 x openhab (on two seperate servers) connecting to the same (one) IHC controller ?
I know I may be pushing the IHC controller to its limit, but I have an spare Rpi, and I was thinking about making a new openhab 2.4 (M6) setup, and test your latest binding on that.

Hi @Kandersen,

and yes, you can connect as many openHAB instances you want to the same controller. But as you said, IHC controller might be unstable. I have not had any issues with multiple connections. 

[Kandersen]

Thanks Pauli.. I´ll give it a try. 

[BrianPedersen]

3 timer siden, Kandersen skrev:

Thanks Pauli.. I´ll give it a try. 

i have done it. it works fine, I have a main server, and a test server, both are connected, and everything is updated just fine, on both servers, and my controller is only a old 6.1

[Kandersen]

Great to hear Brian.. I´ll give it a try, cause I want to test an Rpi 3B+ and just the latest IHC binding.. 

[Kandersen]

@Pauli Anttila

Hi Pauli.. I´m just about to test the latest IHC binding, but I ran into a problem.. It seems like the binding use the default port (443) for connection. I have change the port on my IHC controller. And now I get connection refused. I fixed using the same settings as in binding 1.12.. but perhaps you should maka an option in the things settings for the port to use!

[Kandersen]

@Pauli Anttila

Hmm. I´m not quite sure if this is correct. 
I got the new binding up running on a clean install 2.4 (M6 snapshot release). Binding installed fine, and after the change in the port, it connected fine to the IHC controller. I put the createChannelsAutomatically=true and it found lots of channels, ofcouse.. 
But the first 72 channels looks like this:

That make me wonder, cause I one have 3 wireles battery devices and 7 wireless dimmer devices. But it looks like it found 36 devices??

Another problem is the temperature sensor. 
From what I can understand you read the resources ID of the product and create channels from them. And most of the temperatur sensor seems to be correct. But I have one channel which I cant figure where comes from.

This one, with the red circle. When I use Visual or an alternative IHC viewer, which also tells me the recourse ID, I cant find it anywhere.
For some reason it does now have a name of the location (i would have suspected Køkken, like the channels underneeth). But this resource ID is not part of the temperature sensor in the Køkken location. Infact I cant find it anywhere.. So where does this one come from?

Btw..Just a info.
I just pushed the controller above its limits. 4 x SSL connections at one time (2 x openhab, 1 x ServiceView and 1 x IHC Captain seems to be too many ) The controller went into fail mode, and restartet. Had to close down 1 openhab and the servcieview connection first though.. Fortunatly I have an alternative Serviceviewer (Dingus Alternative Serviceview) whic is using the web connection insted of ssl. Dingus´s serviceviewer can show the resource ID´s. 

[Pauli Anttila]

@Kandersen,

 

Could you enable trace level logging and send me the log?

 

Form karaf console:

1. bundle:stop "IHC / ELKO Binding"

2. log:set TRACE org.openhab.binding.ihc

3. bundle:start "IHC / ELKO Binding"

4. Wait a while and get log file

5. log:set DEFAULT org.openhab.binding.ihc

[Kandersen]

@Pauli Anttila

Here you go:

openhab.rar

[Pauli Anttila]

@Kandersen

Quote

That make me wonder, cause I one have 3 wireles battery devices and 7 wireless dimmer devices. But it looks like it found 36 devices??

Your controller is reporting 38 wireless devices.

wireless_devices.txt

Quote

This one, with the red circle. When I use Visual or an alternative IHC viewer, which also tells me the recourse ID, I cant find it anywhere.
For some reason it does now have a name of the location (i would have suspected Køkken, like the channels underneeth). But this resource ID is not part of the temperature sensor in the Køkken location. Infact I cant find it anywhere.. So where does this one come from?

Those are temperature sensor's alarm inputs. I don't know the reason why the location information isn't correct (it's not correct in my environment either). In fact, I haven't recognised those alarm inputs earlier (never looked so deeply), but I will check if those could be improved.

 

[Kandersen]

10 minutter siden, Pauli Anttila skrev:

our controller is reporting 38 wireless devices.

But how is that possible, when I only got 10 wireles devices?? And only 3 battery devices?? It has to come from somewhere..
This is my Visual program, (vis):
mejsevænget 14_11_2018 inverter PIR.vis

Here is a screendump of my wireless products:

[Kandersen]

6 minutter siden, Pauli Anttila skrev:

Those are temperature sensor's alarm inputs. I don't know the reason why the location information isn't correct (it's not correct in my environment either). In fact, I haven't recognised those alarm inputs earlier (never looked so deeply), but I will check if those could be improved.

Hmm, I just saw that now using the real ServiceViewer.. For some reason it doesn´t show the Alarm, and I had forgotten all about it.. 
This is how it looks like in Dingus´s Alternative IHC viewer:

[Pauli Anttila]

Quote

But how is that possible, when I only got 10 wireles devices?? And only 3 battery devices?? It has to come from somewhere..

Well, Binding is using controller AirlinkManagementService to ask detected devices and as you can see from the log, result contains 38 devices. What is the outcome if you press "Product liste" button in "LK IHC Wireless product linking" window?

[Kandersen]

4 timer siden, Pauli Anttila skrev:

What is the outcome if you press "Product liste" button in "LK IHC Wireless product linking" window?

Same 10 devices. 

[Pauli Anttila]

@Kandersen Could you send serial numbers of those 10 devices (which device is which)?

[Kandersen]

11 minutter siden, Pauli Anttila skrev:

@Kandersen Could you send serial numbers of those 10 devices (which device is which)?

Sure:
This is take from the Visual option of creating documentation for the installation.

Lokalitet	Soveværelse
Placering	Halogen spot rækkeklemme 15
Komponent	Lampeudtag dimmer ø80
Identifikationskode	--
Serie nummer	_0x640816240287
Lysgruppe	IHC 3

 

Lokalitet	Køkken
Placering	Køkkenvask rækkeklemme 19
Komponent	Lampeudtag dimmer ø80
Identifikationskode	--
Serie nummer	_0x640816240122
Lysgruppe	IHC 4

 

Lokalitet	Køkken
Placering	Underskabe Uni250 Klemme 17 og 18
Komponent	Dimmer Universal UNI250 (1-modul)
Identifikationskode	--
Serie nummer	_0x640a07237810
Lysgruppe	IHC 4

 

Lokalitet	Spiseplads
Placering	spisebord klemme 23
Komponent	Lampeudtag dimmer ø80
Identifikationskode	--
Serie nummer	_0x640816240124
Lysgruppe	IHC 4

 

Lokalitet	Spiseplads
Placering	Spiseplads halogenlys Uni250 Klemme 22
Komponent	Dimmer Universal UNI250 (1-modul)
Identifikationskode	--
Serie nummer	_0x640a07237823
Lysgruppe	IHC 4

 

Lokalitet	Kontor
Placering	Ved dør
Komponent	Tryk 2 tast (wireless pushbutton)
Identifikationskode	--
Serie nummer	_0x640e15123673
Lysgruppe	--

 

Lokalitet	Lille Badværelse
Placering	Ved dør
Komponent	Tryk 2 tast (wireless pushbutton)
Identifikationskode	--
Serie nummer	_0x640e15123789
Lysgruppe	--

 

Lokalitet	Caspers værelse
Placering	--
Komponent	Tryk 2 tast (wireless pushbutton)
Identifikationskode	--
Serie nummer	_0x640e15123809
Lysgruppe	--

 

Lokalitet	Hyggestue ved børneafd.
Placering	Halogen klemme 21 (bag tavle 2)
Komponent	Dimmer Universal UNI250 (1-modul)
Identifikationskode	--
Serie nummer	_0x640a07237758
Lysgruppe	IHC 1

 

Lokalitet	Udendørs
Placering	Udhæng Indgangsparti Uni250 klemme 5
Komponent	Dimmer Universal UNI250 (1-modul)
Identifikationskode	--
Serie nummer	_0x640a07237960
Lysgruppe	IHC 5

 

 

[Pauli Anttila]

@Kandersen Could you try following version https://www.dropbox.com/s/bn3k50w8or10rro/org.openhab.binding.ihc_2.4.0.201811282019.jar?dl=0

• RF channels are generated from project file rather than AirlinkManagementService
• RF device battery and signal strength channels have better description
• Temperature sensor alarm input description should be correct
• Controller SW and HW version channels are moved to thing properties
• Added more thing properties

[Kandersen]

4 timer siden, Pauli Anttila skrev:

RF channels are generated from project file rather than AirlinkManagementService

Alot better. I do get a few channels where the name doesnt seem right (like its missing room name). But I need to check up with Visual on this one. At least the number of RF devices are down to a real figure.

4 timer siden, Pauli Anttila skrev:

RF device battery and signal strength channels have better description

Yes, alot better as well. 

4 timer siden, Pauli Anttila skrev:

Temperature sensor alarm input description should be correct

Is it!

4 timer siden, Pauli Anttila skrev:

Controller SW and HW version channels are moved to thing properties

Yup, working fine here as well.. Btw why dont you use the latest firmware for HW 6.2?

One small request.. 
Is it possible to move the enable/disable button to the top insted of the bottom. Having hundreds of channels, it takes a while to scroll all the way down 

[Pauli Anttila]

Quote

Btw why dont you use the latest firmware for HW 6.2?

I haven't had a single problem with 2.7.144, so I just don't want to break it 

17 hours ago, Kandersen said:

Is it possible to move the enable/disable button to the top insted of the bottom.

Enable/disable button?

[Kandersen]

3 timer siden, Pauli Anttila skrev:

I haven't had a single problem with 2.7.144, so I just don't want to break it 

Fair argument 

 

3 timer siden, Pauli Anttila skrev:

21 timer siden, Kandersen skrev:

Is it possible to move the enable/disable button to the top insted of the bottom.

Enable/disable button?

This one:
(I dont know if it´s the binding or because I´m running openhab 2.4 M6 (milestone build).

[Kandersen]

Hi @Pauli Anttila

I think the binding got a problem with the 2.4 #1445, #1447 and Milestone M7. Maybe it has been there all the time.. 
If I upgrade my openhab, the IHC controller do come online allright. But it doesn´t receive anything from the controller. It even happens if I reboot my Rpi. 

If I go into PapuerUI and disable the thing (using the button Disable showen above) , and afterwards enable it again. The binding starts to receive updates fine from the Controller. 

Notice the time periode in this small log snippet:
 

2018-12-02 21:28:37.954 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from OFFLINE (COMMUNICATION_ERROR): org.apache.http.conn.ConnectTimeoutException: Connect to 10.4.28.6:777 [/10.4.28.6] failed: Read timed out to OFFLINE (BRIDGE_OFFLINE): Initializing communication to the IHC / ELKO controller
2018-12-02 21:28:41.739 [me.event.ThingUpdatedEvent] - Thing 'ihc:controller:elko' has been updated.
2018-12-02 21:28:42.287 [me.event.ThingUpdatedEvent] - Thing 'ihc:controller:elko' has been updated.
2018-12-02 21:28:42.389 [vent.ItemStateChangedEvent] - ControllerState changed from NULL to Ready
2018-12-02 21:28:42.678 [vent.ItemStateChangedEvent] - ControllerUpTime changed from NULL to 593242.088

2018-12-02 21:28:42.707 [vent.ItemStateChangedEvent] - ControllerDateTime changed from NULL to 2018-12-02T19:29:35.000+0100
2018-12-02 21:28:42.764 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from OFFLINE (BRIDGE_OFFLINE): Initializing communication to the IHC / ELKO controller to ONLINE
2018-12-02 21:40:32.365 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from ONLINE to UNINITIALIZED
2018-12-02 21:40:34.972 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2018-12-02 21:40:40.674 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2018-12-02 21:40:45.880 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Initializing communication to the IHC / ELKO controller
2018-12-02 21:40:47.139 [vent.ItemStateChangedEvent] - ControllerUpTime changed from 593242.088 to 593966.51
2018-12-02 21:40:47.145 [vent.ItemStateChangedEvent] - ControllerDateTime changed from 2018-12-02T19:29:35.000+0100 to 2018-12-02T19:41:39.000+0100
2018-12-02 21:40:47.395 [vent.ItemStateChangedEvent] - ControllerUpTime changed from 593966.51 to 593966.792
2018-12-02 21:40:49.585 [me.event.ThingUpdatedEvent] - Thing 'ihc:controller:elko' has been updated.
2018-12-02 21:40:50.522 [vent.ItemStateChangedEvent] - ControllerUpTime changed from 593966.792 to 593969.983
2018-12-02 21:40:50.540 [vent.ItemStateChangedEvent] - ControllerDateTime changed from 2018-12-02T19:41:39.000+0100 to 2018-12-02T19:41:42.000+0100
2018-12-02 21:40:50.546 [hingStatusInfoChangedEvent] - 'ihc:controller:elko' changed from OFFLINE (BRIDGE_OFFLINE): Initializing communication to the IHC / ELKO controller to ONLINE
2018-12-02 21:40:51.079 [vent.ItemStateChangedEvent] - koekkenTelestat4a changed from NULL to OFF
2018-12-02 21:40:51.097 [vent.ItemStateChangedEvent] - SoveTemperature changed from NULL to 22.10
2018-12-02 21:40:51.102 [vent.ItemStateChangedEvent] - koekkenVask changed from NULL to 34
2018-12-02 21:40:51.106 [vent.ItemStateChangedEvent] - koekkenTemperature changed from NULL to 23.50
2018-12-02 21:40:55.742 [vent.ItemStateChangedEvent] - SoveTemperature changed from 22.10 to 22.00

 

[Kandersen]

@Pauli Anttila

Controller DateTime seems to be 2 hours wrong for some reason I cant really figure. 
Both my controller and the Rpi is reporting the same time. But when using DateTime of the Controller in a sitemap, it´s exactly 2 hours wrong. And it doesnt seem to update on sitemap.

 

2018-12-02 21:49:37.388 [vent.ItemStateChangedEvent] - ControllerDateTime changed from 2018-12-02T19:41:42.000+0100 to 2018-12-02T19:50:29.000+0100

[Pauli Anttila]

17 hours ago, Kandersen said:

If I upgrade my openhab, the IHC controller do come online allright. But it doesn´t receive anything from the controller. It even happens if I reboot my Rpi. 

Could you enable logs with trace level and try to reproduce the issue?