Hop til indhold
IHC-User.dk
Pauli Anttila

openHAB2 IHC binding

Recommended Posts

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.

 

Del dette indlæg


Link til indlæg
Del på andre sites

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

Del dette indlæg


Link til indlæg
Del på andre sites
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 ?

Del dette indlæg


Link til indlæg
Del på andre sites

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

Del dette indlæg


Link til indlæg
Del på andre sites

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]"}

 

Del dette indlæg


Link til indlæg
Del på andre sites
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.

Del dette indlæg


Link til indlæg
Del på andre sites

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

 

Del dette indlæg


Link til indlæg
Del på andre sites

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

Del dette indlæg


Link til indlæg
Del på andre sites
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.

 

 

 

Del dette indlæg


Link til indlæg
Del på andre sites
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.

Del dette indlæg


Link til indlæg
Del på andre sites

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. 

Del dette indlæg


Link til indlæg
Del på andre sites
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.

Del dette indlæg


Link til indlæg
Del på andre sites

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

Del dette indlæg


Link til indlæg
Del på andre sites
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. 

Del dette indlæg


Link til indlæg
Del på andre sites
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. 

Del dette indlæg


Link til indlæg
Del på andre sites

@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" }

 

Del dette indlæg


Link til indlæg
Del på andre sites
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.

Del dette indlæg


Link til indlæg
Del på andre sites

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.

 

Del dette indlæg


Link til indlæg
Del på andre sites
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 ?

Del dette indlæg


Link til indlæg
Del på andre sites

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" ]

 

Del dette indlæg


Link til indlæg
Del på andre sites
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.

Del dette indlæg


Link til indlæg
Del på andre sites

Opret en konto eller log ind for at kommentere

Du skal være medlem for at skrive en kommentar

Opret en konto

Opret en konto på siden her. Det er nemt!

Opret en ny konto

Log ind

Har du allerede en konto? Log ind her.

Log ind nu

×

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.