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

 

 

[EjvindHald]

8 timer siden, Pauli Anttila skrev:

Does anyone have idea what is the scale (min, max, etc) of the battery level and signal strength for wireless devices?

I do not know this. Maybe some of the senior guys in this area like @Lars Jacobsen, @Lars1, @Mikkel Skovgaard or @cis2131 can contribute?

@Pauli Anttila: Can you provide an example for binding version 2.x of a line in the items file using channel and a Command?

In Openhab binding 1.x you had this in the documentation: 

ihc=">[Command:ResourceId(:VALUE)]"

which is a very powerful feature of the binding.

 

[Mikkel Skovgaard]

Battery is just ok or not ok

Signal level is 0 to 18. 18 being best. There is 3 levels within that scale but I'm on my phone

[Pauli Anttila]

Thanks Mikkel

[Pauli Anttila]

I have made lot of improvements the binding and now all features which I planned to implement is implemented. I updated the first post, where is a link to latest jar file and also link to the documentation (draft). I have made some breaking modifications to the binding, so you might need to remove existing thing and add it again. I really appreciate all help in documentation side (more detailed descriptions and examples, etc) as I don't need any documentation myself, so it's purely for your purposes 

[EjvindHald]

1 time siden, Pauli Anttila skrev:

I have made lot of improvements the binding and now all features which I planned to implement is implemented. I updated the first post, where is a link to latest jar file and also link to the documentation (draft). I have made some breaking modifications to the binding, so you might need to remove existing thing and add it again. I really appreciate all help in documentation side (more detailed descriptions and examples, etc) as I don't need any documentation myself, so it's purely for your purposes 

Thanks. I have downloaded the new binding 2.x, and it is working fine. 

Does this mean that the functionality in binding 1.x such as this example in red

Switch    ForsteSalGarderobeSpotLoft "Spot loftet"         <light>          ["Lighting"]     {ihc="<0x1a7f5b,>[ON:0x255c5a:100],>[OFF:0x255b5a:100]"}

will no longer be available using channels in binding 2.x ?

[Pauli Anttila]

@EjvindHald, Currently only one resource Id per channel is supported. It could be challenging to model this in openHAB2. What is the real use case behind this and do you (or anyone else) have many items which use this kind configuration. This functionality can always be imitated by several channels, virtual items and rules.

[Kandersen]

Most of my setup uses this kind of configuration 

12 timer siden, EjvindHald skrev:

Switch    ForsteSalGarderobeSpotLoft "Spot loftet"         <light>          ["Lighting"]     {ihc="<0x1a7f5b,>[ON:0x255c5a:100],>[OFF:0x255b5a:100]"}

 

[EjvindHald]

8 timer siden, Pauli Anttila skrev:

@EjvindHald, Currently only one resource Id per channel is supported. It could be challenging to model this in openHAB2. What is the real use case behind this and do you (or anyone else) have many items which use this kind configuration. This functionality can always be imitated by several channels, virtual items and rules.

I have 63 switches in my ihc.items file, and they are all using this feature. Besides that I have a few contacts and numbers, and they have mainly readonly definition. One number for the level in my ventilation system has ReadWrite definition.

The real use case is that this feature provide a very simple and reliable method of having correct status in openHAB regardless of whether a change was initiated by openHAB UI or a physical input push button attached to IHC. In openHAB it can be quite cumbersome to detect the origin of a change, and suppress additional activities if it was initiated by a physical button, because then everything is done. Before I discovered you smart binding options, I tried a variety of rules including wait, circular refences and sometimes also unintended endless loops inside openHAB. I wrote a posting about this, and it can be read on here (use Chrome to have English translation).

With this feature I can map my entire IHC installation quite simple without the need for rules. Rules are only needed, when I would like a special functionality. It is important for me that IHC is the master and holds all relevant logic and status. There are several reasons for this and one is that the installations in the house must always be working without being depending on 3rd party software such as openHAB.

[EjvindHald]

I have tried with different typs of rules, virtuel items and more channels as you suggested, and I finally found a solution by having the 2 rules with a virtuel item and the correct combination of sendCommand, postUpdate and sleep command. The last is to avoid circular events being triggered on the openHAB bus, when a physical button is pressed. The solution does not work properly in all situations and I do not know why.

Anyway, in my case it would mean 2 x 63 = 126 rules, where today I have 0 (zero) rules using openHAB binding 1.x. On top of this comes 63 new virtual items.

Therefore, it would be much simpler if it was possible that new binding could have same features as openHAB 1.x with <, >, ON, OFF.

Thanks.

Ejvind

 

[Pauli Anttila]

@EjvindHald, could you post your test items and rules? 

[Kandersen]

Ejvind - Hvorfor er det vigtigt for dig at skelne mellem om en items er blevet aktiveret via OpenHab eller fysisk tryk? Resultatet er vel det samme. Så det du skal, det er at kende status på dit item du har påvirket. Det er dog i langt de fleste tilfælde ikke nødvendigt at kende dette i IHC. Og for de funktioner hvor det er, der kan du hente statusmeldingen direkte fra IHC controlleren og bruge den som en item. 

Jeg er også lidt usikker på, hvorfor du blander rules sammen med, måden items defineres på (channels)?

[EjvindHald]

På ‎30‎-‎05‎-‎2018 at 07:14 , Pauli Anttila skrev:

@EjvindHald, could you post your test items and rules?  

From ihc.rules:

//Spisestue syd test openHAB2
rule "Living room toogle switch - UI"
when
    Item IHC2UI changed  
then
    {IHC2SpisebordKip.sendCommand(ON)}
    Thread::sleep(1000)
    {IHC2SpisebordKip.sendCommand(OFF)    
    }
end

//Spisestue syd test openHAB2
rule "Living room toogle switch - physical contact"
when
    Item IHC2Spisebord changed
then
    {postUpdate(IHC2UI,IHC2Spisebord.state)}
    Thread::sleep(1000)
end

From ihc.things

ihc:controller:haldIHC [ ip="192.168.1.31:444", username="xxxxx", password="yyyyy", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] {

Channels:

Type switch-channel            : my_test_switch          "My test Switch"    [resourceId=2845531, direction="ReadOnly"]  //output
Type switch-channel            : SpisestueLoftSydKip    "Spisestue syd kip"    [resourceId=1417818, direction="WriteOnly"]    //input
    
} 

From ihc.items

//IHC binding2 test
Switch    IHC2Spisebord "Spisebord2"                {channel="ihc:controller:haldIHC:my_test_switch"}
Switch    IHC2SpisebordKip "Spisebord2Kip"     {channel="ihc:controller:haldIHC:SpisestueLoftSydKip"}
Switch  IHC2UI "Spisebord2UI"     <phlampe>

Comments

My preference is to have IHC hold all logic, and therefore I will not modify any outputs directly. Instead, on or off in openHAB should simulate physical press on an input button. By doing that the very same logic in IHC will be executed as if it was pressed. This is very easy in binding 1.x using <, >, on and off, but quite cumbersome in binding 2.x where this functionality in the binding does not exist. Instead, it can be simulated, and I have shown an example here using a toogle input. It is working fine except in the scenario of an ultra short physical press on the button. Suggestions and inputs are welcome.

I also tried the new type "pulse-output-channel", but I could not get it working. Item Spisebord2UI is the virtual item.  If it is not possible to have these functions in binding 2.x with channels, I will probably just keep using binding 1.x as long time as possible.

 

 

 

[EjvindHald]

På ‎30‎-‎05‎-‎2018 at 11:13 , Kandersen skrev:

Ejvind - Hvorfor er det vigtigt for dig at skelne mellem om en items er blevet aktiveret via OpenHab eller fysisk tryk? Resultatet er vel det samme. Så det du skal, det er at kende status på dit item du har påvirket. Det er dog i langt de fleste tilfælde ikke nødvendigt at kende dette i IHC. Og for de funktioner hvor det er, der kan du hente statusmeldingen direkte fra IHC controlleren og bruge den som en item. 

Jeg er også lidt usikker på, hvorfor du blander rules sammen med, måden items defineres på (channels)? 

Jeg prøver blot at genskabe den samme funktionalitet, som jeg opnår med <, >, ON og OFF funktionerne i binding 1.x. Disse funktioner mangler som bekendt i binding 2. Og med mit tiltænkte løsningsforslag til at opnå den samme funktion har jeg brug for at kende disse - ellers kan jeg ikke få det til at virke.

Hvis du har et smart forslag til, hvordan man enkelt kan opnå det samme, så vil det være særdeles velkommen. I din eksisterende binding 1.x kan du blot for et enkelt test item undlade at bruge >, <, ON og OFF og så prøve at opnå den samme funktion på anden vis :-) Dvs. ingen direkte ændring af outputs i IHC - alle ændringer skal ske via input. Og konsekvensen af fysiske tryk skal selvfølgelig afspejles direkte i openHAB som du kender det.

[Kandersen]

Er det ovenstående eksempel på den måde den nye binding er? (Jeg har endnu ikke nået at lege med den). altså hvor du både skal definere channels og items. For hvis det er korrekt, så forstår jeg ikke meningen med det. 

[EjvindHald]

12 timer siden, Kandersen skrev:

Er det ovenstående eksempel på den måde den nye binding er? (Jeg har endnu ikke nået at lege med den). altså hvor du både skal definere channels og items. For hvis det er korrekt, så forstår jeg ikke meningen med det. 

Things, Channels og Item er alle begreber indenfor openHAB version 2 - se mere her. Det betyder, at man skal vænne sig til dem, når man arbejder med bindings version 2, uanset om det er til IHC eller andet. Det er ret smart, og giver bl.a. nem adgang til at arbejde med flere IHC controllere på en gang.

Men i den nye binding lægge Pauli op til, at funktionerne <, >, ON og OFF forsvinder, hvilket er uheldigt. Det er ret unikke funktioner, og jeg har lavet eksempel på dem i dette indlæg.

[Mads M]

Hi

Thanks for the new 2.0 Binding currently testing with 1.X and the 2.x binding on the same OH2 and it seems to work fine

Could you convert the controller uptime from seconds to days and hours ect. ?

[Kandersen]

1 time siden, EjvindHald skrev:

Things, Channels og Item er alle begreber indenfor openHAB version 2 - se mere her. Det betyder, at man skal vænne sig til dem, når man arbejder med bindings version 2, uanset om det er til IHC eller andet. Det er ret smart, og giver bl.a. nem adgang til at arbejde med flere IHC controllere på en gang.

Men i den nye binding lægge Pauli op til, at funktionerne <, >, ON og OFF forsvinder, hvilket er uheldigt. Det er ret unikke funktioner, og jeg har lavet eksempel på dem i dette indlæg.

Er med på dit eksempel. Og også på at channels er smart, når man har flere "ting/funktioner" i samme enhed. Jeg har andre enheder, som også bruger channels. Men i dit eksempel du lagde op her tidligere, der ser det ud for mig som om, at man skal definere en enkelt items flere gange (fx en switch). Så synes jeg lige det smarte går af. 

[EjvindHald]

11 timer siden, Kandersen skrev:

Er med på dit eksempel. Og også på at channels er smart, når man har flere "ting/funktioner" i samme enhed. Jeg har andre enheder, som også bruger channels. Men i dit eksempel du lagde op her tidligere, der ser det ud for mig som om, at man skal definere en enkelt items flere gange (fx en switch). Så synes jeg lige det smarte går af.  

Ja, præcis. Det er også derfor, at jeg opfordrer Pauli til at medtage den oprindelige funktionalitet fra binding 1.x, hvis det er muligt. Jeg har været nødt til at definere 3 items i mit eksempel:

1 svagstrøms input til kip
1 Output til lyset
1 virtuel item, som bruges til at styre det med i openHAB

og det er ikke særlig elegant. Der er præcis derfor, at jeg har spurgt, om det ikke var muligt at få funktionaliteten med <, >, ON og OFF også i binding 2.x, fordi så ville alt blive meget nemmere. 

[Pauli Anttila]

@EjvindHald, I think following should work fine?

Channels:

Type switch-channel          : ihcoutput     "IHC output"   [ resourceId=2845531, direction="ReadOnly" ]  //output
Type pulse-output-channel    : ihcinput      "IHC input"    [ resourceId=1417818, direction="WriteOnly", pulseLength=1000 ]    //input

Items:

Switch    IHC2Spisebord "Spisebord"    { channel="ihc:controller:haldIHC:ihcoutput", channel="ihc:controller:haldIHC:ihcinput" }

 

[EjvindHald]

2 timer siden, Pauli Anttila skrev:

@EjvindHald, I think following should work fine?

Channels:

Type switch-channel          : ihcoutput     "IHC output"   [ resourceId=2845531, direction="ReadOnly" ]  //output
Type pulse-output-channel    : ihcinput      "IHC input"    [ resourceId=1417818, direction="WriteOnly", pulseLength=1000 ]    //input

Items:

Switch    IHC2Spisebord "Spisebord"    { channel="ihc:controller:haldIHC:ihcoutput", channel="ihc:controller:haldIHC:ihcinput" }

 

@Pauli Anttila, thanks - I have tried your suggestion. It works fine with one exception: The lights cannot be turned off. If the switch is set to false in openHAB UI no message is sent to IHC. However, if you try to turn it on again from UI, then it sends a message to the input toogle switch, which then turns off the light.

I can see you are using multi channel link in items. I do not know how that works.

[Pauli Anttila]

OK, reason why it doesn't work is that currently pulse output channel only send pulse when state changes from off to on. So if I extended the pulse output channel so that pulse can be configured to send also when state changes from on to off, it most probably work fine then.

OpenHAB support multi channel linking and it doesn't have any black magic behind. When item receive a command, openHAB send command to every channel linked to the item. When channels are updated, item state is updated as well. IHC binding channels support direction configuration parameter, so if ReadOnly is enabled, IHC binding doesn't send any commands from item to configured IHC resource. If IHC binding receive update from IHC controller, channel is updated. If WriteOnly is enabled, binding just send commands to IHC controller, but doesn't update the channel state when update is received from IHC controller. So direction works exactly like < and > operators in version 1 binding.

 

[EjvindHald]

12 minutter siden, Pauli Anttila skrev:

OpenHAB support multi channel linking and it doesn't have any black magic behind. When item receive a command, openHAB send command to every channel linked to the item. When channels are updated, item state is updated as well.

Yes, I think if you extend it also to capture from on to off, it will solve the toogle scenario, which will be great 

However, I do not quite see how another typical scenario will fit in  . If you have one physical input for on and another physical for off like in this binding 1.x example:

Switch    ForsteSalGarderobeSpotLoft "Spot loftet"         <light>          ["Lighting"]     {ihc="<0x1a7f5b,>[ON:0x255c5a:100],>[OFF:0x255b5a:100]"}

There are 2 different IHC ID's in italic - one for turn on and another for turn off. For openHAB2 you wrote that "openHAB send command to every channel linked to the item", so I guess this is not supported in openHAB using multiple channels ?

[Pauli Anttila]

Well, my idea was to introduce trigger parameter to pulse output channel, where you can choose when pulse is send (ON->OFF, OFF->ON, Both)

Then following should work.

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

 

[Kandersen]

22 timer siden, EjvindHald skrev:

og det er ikke særlig elegant. Der er præcis derfor, at jeg har spurgt, om det ikke var muligt at få funktionaliteten med <, >, ON og OFF også i binding 2.x, fordi så ville alt blive meget nemmere. 

Okay så forstår jeg det. Blev bare forvirret fordi du blandede rules ind i det. Der kan jeg nemlig ikke se sammenhængen.

[EjvindHald]

8 timer siden, Pauli Anttila skrev:

Well, my idea was to introduce trigger parameter to pulse output channel, where you can choose when pulse is send (ON->OFF, OFF->ON, Both)

Then following should work.

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

 

@Pauli AnttilaThanks - I have tried this:

item:
Switch    IHC2Spisebord "Spisebord"      {channel="ihc:controller:haldIHC:ihcoutput", channel="ihc:controller:haldIHC:ihcinput1", channel="ihc:controller:haldIHC:ihcinput2"}

things:
Type switch-channel               : ihcoutput   "IHC output"    [resourceId=3932434, direction="ReadOnly"]  //output
Type pulse-output-channel    : ihcinput1    "IHC input1"    [resourceId=3931665, direction="WriteOnly", pulseLength=1000, trigger="ON"]    //input1
Type pulse-output-channel    : ihcinput2    "IHC input2"    [resourceId=3931921, direction="WriteOnly", pulseLength=1000, trigger="OFF"]    //input2

which should work. 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.

If your suggestion with trigger could be working, it can also be used for the toogle scenario. Then you would just define two channels on the same resourceID, but with different triggers.