Hop til indhold
  • 0

openHAB2 IHC binding


Pauli Anttila
 Share

Spørgsmål

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).

 5b000b95160a8_ScreenShot2018-05-19at14_32_14.thumb.png.4093d93247a17cd4fc3d66307c895976.png

5b000ba2cc62b_ScreenShot2018-05-19at14_33_06.thumb.png.648edf0e40855577f58e973c448514b6.png

 

Link til kommentar
Del på andre sites

Recommended Posts

  • 0
Quote

When I change the switch in openHAB UI to ON, it sends command to IHC input 1, which is fine. However, one second later, it also send a command on input2, which turns off the light again. So I end up in a situation, where the light is on for one second.

Yes, this is how it works as trigger parameter is not yet implemented :rolleyes:

Link til kommentar
Del på andre sites

  • 0
56 minutter siden, Pauli Anttila skrev:

Yes, this is how it works as trigger parameter is not yet implemented :rolleyes:

@Pauli AnttilaCool - I will look forward to this implementation, because then I should be able to implement everything ordinary logic without rules.

However, I have one question. Today, I am setting an integer in IHC from openHAB to control the level of my ventilation system. It was a bit diffecult to get working in binding 1.x, and I ended up with this after advice from @Claus Skovgaard:

Number    DanthermVent "Vent. trin"       <qualityofservice> ["CurrentTemperature"] {ihc="<0xadd90b,>[*:0xadce0b]"}

The special part is marked in italic. Will I be able to set an integer i openHAB binding 2 like the example above? If yes, then I think all my scenarios are covered ;)

Link til kommentar
Del på andre sites

  • 0

Just updated the link to latest binding version. I have made many breaking changes to the binding. I removed pulse output channel as now every channel can send pulse if pulseWidth parameter is defined. Every channel also have now commandToReact parameter which can be used to filter commands. 

So following should be now possible

Type switch-channel  : ihcoutput  "IHC output"   [ resourceId=1736539, direction="ReadOnly" ]
Type switch-channel  : ihcinput1  "IHC input 1"  [ resourceId=2448474, direction="WriteOnly", pulseWidth=1000, commandToReact="ON" ]
Type switch-channel  : ihcinput2  "IHC input 2"  [ resourceId=2448218, direction="WriteOnly", pulseWidth=1000, commandToReact="OFF" ]

I have not test new version very well, so there could be bugs.

 

Link til kommentar
Del på andre sites

  • 0

Thanks. I have downloaded and installed the new binding version 2, and it is working as intended! Thanks, this is really good. For simple control of your IHC installation rules are not needed with this binding.

However, I have not yet tested setting of an integer field - only done on/off. What will be the commandToReact on an integer field? - it needs to send a pulse to IHC, if the integer value is changed.

Link til kommentar
Del på andre sites

  • 0
Quote

What will be the commandToReact on an integer field? - it needs to send a pulse to IHC, if the integer value is changed.

If you want that number channel react to all commands, you ignore the whole commandToReact parameter. If you want that channel just react to number 5 then defined so. So commandToReact is exactly the command which you send to items. If pulseWidth is defined, then binding don't send the item value but generate the pulse. 

Link til kommentar
Del på andre sites

  • 0
På ‎06‎-‎06‎-‎2018 at 22:00 , Pauli Anttila skrev:

If you want that number channel react to all commands, you ignore the whole commandToReact parameter. If you want that channel just react to number 5 then defined so. So commandToReact is exactly the command which you send to items. If pulseWidth is defined, then binding don't send the item value but generate the pulse. 

@Pauli AnttilaI have now tried to test the number functionality, and my ihc.things contains this:

Type number-channel        : ihc2number    "IHC vent"      [resourceId=11390475, direction="WriteOnly", pulseWidth=1000]    //vent
Type number-channel        : ihc2numberstat  "IHC vent s"  [resourceId=11393291, direction="ReadOnly"]    //vent stat
 

and the ihc.sitemap contains: Switch item=DanthermVent2 mappings=[1="1", 2="2", 3="3", 4="4"] 

while ihc.items has: 

Number    DanthermVent2 "Vent. trin2"                        <qualityofservice>  {channel="ihc:controller:haldIHC:ihc2number", channel="ihc:controller:haldIHC:ihc2numberstat"}

The reading of the numeric value from ihc2numberstat is working fine.

However, when the value is set using ihc2number, it seems always to set it to 100 according to LK ServiceView. This is regardless of whether I choose 1, 2, 3 og 4 in the UI. Therefore, this functionality is not working for me. 

Can you assist with this? - it is working fine in binding 1.

Thanks.

 

Link til kommentar
Del på andre sites

  • 0

@EjvindHald, it works like you have configured it to work :). When ever Number item receive a command (1, 2, 3, 4), binding send 1000ms "pulse" to 11390475 resource. When pulseWidth parameter is defined, binding send ON command, wait 1000ms and send OFF command. ON and OFF commands are converted automatically to IHC resource value type. Normally, pulse is used with boolean resource (IHC binary input), but in your case IHC resource value is numeric, therefore binding converts ON command to value 100 and OFF command to value 0. So ultimately binding send value 100 (ON), sleep 1000ms and then send value 0 (OFF). I can't remember why I have selected value 100 when ON command is converted to numeric resource value as conversion functions are taken from OH1 binding. Most probably the reason was that Dimmer item types, value 100 present the full brightness.

I guess you want to send a item value rather than generate a pulse, so you shouldn't define pulseWidth in this case.

Type number-channel        : ihc2number    "IHC vent"      [resourceId=11390475, direction="WriteOnly"]    //vent

Then binding send item value (1, 2, 3, 4) to IHC resource, which then match you OH1 configuration

ihc="<0xadd90b,>[*:0xadce0b]"

 

Link til kommentar
Del på andre sites

  • 0

I have now used this new version on my "production" openHAB system almost one month without single problem, so it seems to be pretty rock solid. I have done some refactoring to binding since last version (in 1st page). Binding it's not yet merged to openHAB main repo, but official PR snapshot builds can be found here.

Link til kommentar
Del på andre sites

  • 0
On 7/3/2018 at 9:02 PM, Pauli Anttila said:

I have now used this new version on my "production" openHAB system almost one month without single problem, so it seems to be pretty rock solid. I have done some refactoring to binding since last version (in 1st page). Binding it's not yet merged to openHAB main repo, but official PR snapshot builds can be found here.

Sounds great - impressive work! 

Looking forward to test the new binding, when i have time for it. 

Link til kommentar
Del på andre sites

  • 0

@EjvindHald May I ask if you have completely made a switchover from Paulis OH1 IHC binding, to the OH2 IHC binding? And if so, how is your experience? 

The starting point for my OH use, was your "best practice" post last year, why I guess a switchover for me some way will be similar.

Thanks in advance.

Best regards Ole. 

 

Link til kommentar
Del på andre sites

  • 0
2 timer siden, Vagn skrev:

I have 2 ihc controllers installed in my house. One of them runs well against openhab2. Is it possible to configure the binding so it can communicate with the second controller as well?

Yes, that is one of the advantages of binding version 2. It should automaticly discover 2 Things (your 2 IHC controllers) which each have their own ip address. Please be aware that OpenHAB is still is shipped with binding version 1, so you need to download and add IHC binding 2 yourself as explained in the first article in this post.

Link til kommentar
Del på andre sites

  • 0

@Pauli Anttila How do I add a wireless dimmer..? when I press the + sign, there is no dimmer function to select, is that function not yet implemented ?? and then in my list I have 36 low battery, and also 36 signal strength channels, but I only have maybe 10-15 wireless devices,  and have no idea what they are, they are only followed by a number....

Everything else that I have tested works fine.. thanks for the great work...

Link til kommentar
Del på andre sites

  • 0

This new binding works exceptionally. Many thanks for the work done so far.
I have tried to add a second controller, but when it is added, it gets the status of INITIALIZING, then no further happens. If I delete the first controller, the status of the secondary immediately changes to ONLINE. If I then add the first controller again, it will get the status of INITIALIZING. What did I miss? Please advice.

Link til kommentar
Del på andre sites

  • 0

I have now tried adding a third controller, but then both second and third controller stand in INITILAZING forever. However, I have found that if I change something on the THING object, for example, the controller name, the controller goes ONLINE immediately. But at the same time, Controller 1 stops responding and some ERROR appears in the log. See the added Log below. Please advise.

The log shows that I add “controller 1” as a THING. Adds an OUTPUT to ITEMS. Turn OFF and ON the OUTPUT and it works fine. Then I add “controller 2” and it goes in INITILAZING, nothing happens in the log. Then I change the name of “controller 2” which then goes ONLINE. Then I try to change OUTPUT on “controller 1” but it is not responding, and ERROR is in the log.

2018-09-01 19:06:25.296 [hingStatusInfoChangedEvent] - 'ihc:controller:608e3097' changed from UNINITIALIZED to INITIALIZING

2018-09-01 19:06:25.559 [hingStatusInfoChangedEvent] - 'ihc:controller:608e3097' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Initializing communication to the IHC / ELKO controller

2018-09-01 19:06:25.560 [WARN ] [.ihc.ws.projectfile.ProjectFileUtils] - Error occured when read project file from file '/var/lib/openhab2/ihc-project-file-608e3097.xml', reason /var/lib/openhab2/ihc-project-file-608e3097.xml (No such file or directory)

2018-09-01 19:06:31.586 [me.event.ThingUpdatedEvent] - Thing 'ihc:controller:608e3097' has been updated.

2018-09-01 19:06:31.875 [hingStatusInfoChangedEvent] - 'ihc:controller:608e3097' changed from OFFLINE (BRIDGE_OFFLINE): Initializing communication to the IHC / ELKO controller to ONLINE

2018-09-01 19:06:59.394 [ome.event.ItemUpdatedEvent] - Item 'IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang' has been updated.

2018-09-01 19:07:00.226 [.ItemChannelLinkAddedEvent] - Link 'IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang-ihc:controller:608e3097:outputs#155995' has been added.

2018-09-01 19:07:07.665 [vent.ItemStateChangedEvent] - IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang changed from NULL to ON

2018-09-01 19:07:10.726 [ome.event.ItemCommandEvent] - Item 'IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang' received command OFF

2018-09-01 19:07:10.746 [vent.ItemStateChangedEvent] - IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang changed from ON to OFF

2018-09-01 19:07:11.782 [ome.event.ItemCommandEvent] - Item 'IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang' received command ON

2018-09-01 19:07:11.795 [vent.ItemStateChangedEvent] - IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang changed from OFF to ON

2018-09-01 19:07:12.328 [vent.ItemStateChangedEvent] - IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang changed from ON to OFF

2018-09-01 19:07:12.357 [vent.ItemStateChangedEvent] - IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang changed from OFF to ON

2018-09-01 19:07:34.136 [hingStatusInfoChangedEvent] - 'ihc:controller:9c845dba' changed from UNINITIALIZED to INITIALIZING

2018-09-01 19:07:53.864 [me.event.ThingUpdatedEvent] - Thing 'ihc:controller:9c845dba' has been updated.

2018-09-01 19:07:54.116 [hingStatusInfoChangedEvent] - 'ihc:controller:9c845dba' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Initializing communication to the IHC / ELKO controller

2018-09-01 19:07:54.116 [WARN ] [.ihc.ws.projectfile.ProjectFileUtils] - Error occured when read project file from file '/var/lib/openhab2/ihc-project-file-9c845dba.xml', reason /var/lib/openhab2/ihc-project-file-9c845dba.xml (No such file or directory)

2018-09-01 19:07:55.234 [me.event.ThingUpdatedEvent] - Thing 'ihc:controller:9c845dba' has been updated.

2018-09-01 19:07:55.558 [hingStatusInfoChangedEvent] - 'ihc:controller:9c845dba' changed from OFFLINE (BRIDGE_OFFLINE): Initializing communication to the IHC / ELKO controller to ONLINE

2018-09-01 19:08:03.014 [ome.event.ItemCommandEvent] - Item 'IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang' received command OFF

2018-09-01 19:08:03.038 [vent.ItemStateChangedEvent] - IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang changed from ON to OFF

2018-09-01 19:08:03.172 [ERROR] [enhab.binding.ihc.handler.IhcHandler] - Can't update channel 'ihc:controller:608e3097:outputs#155995' value, cause

2018-09-01 19:08:06.836 [ome.event.ItemCommandEvent] - Item 'IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang' received command ON

2018-09-01 19:08:06.859 [vent.ItemStateChangedEvent] - IHCELKOController1_Outputs_HelleHelleWireSpot607Udgang changed from OFF to ON

2018-09-01 19:08:07.036 [ERROR] [enhab.binding.ihc.handler.IhcHandler] - Can't update channel 'ihc:controller:608e3097:outputs#155995' value, cause

 

Link til kommentar
Del på andre sites

  • 0

@Vagn, I think I have found the reason for you problem. I have only one IHC controller, so I'm not able to test support properly. I made some fixes, so could you try this version?

 

@BrianPedersen, I don't have any wireless dimmers, so I don't have a clue how they are implemented. That's also the reason why I have not included those to auto discovery. Have you used them with binding version 1? If yes, then you should be able add them manually to v2 binding as well. I could add the support, but I need details how they work.

 

Link til kommentar
Del på andre sites

  • 0
På 5/9/2018 at 21:38 , Peter H skrev:

Hi.

Maybe it is just me but the new binding is creating "things", but for my Wireless stuff it only creates "Low Battery" and "Signal Strength".

Are you seeing the same thing or am I doing something wrong?

Thanks.

 

I think, that none of the wireless things in implemented... I have a lot of wireless, so i'am returning to version 1...

Link til kommentar
Del på andre sites

  • 0
6 minutes ago, BrianPedersen said:

I think, that none of the wireless things in implemented... I have a lot of wireless, so i'am returning to version 1...

That's not correct. Wireless actuators are supported. Only limitation is the auto discovery, where only airlink_inputs and airlink_outputs are automatically discovered. All lego blocks are in place, so what can be configured via ver 1 binding can be manually configured via ver 2 binding as well.

Link til kommentar
Del på andre sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gæst
Svar på dette spørgsmål

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loader...
 Share

×
×
  • Tilføj...

Important Information

Privatlivspolitik og We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.

1200x630bb.png

ok