Hop til indhold

EjvindHald

Members
 Se profil  See their activity

  • Antal indlæg

    535

  • Medlem siden

  • Senest besøgt

  • Days Won

    28

 Indholdstype 

Indlæg skrevet af EjvindHald

  4. Læse / skrive IHC timer værdi i OpenHAB

    i OpenHAB

    Besvaret

    Hi @Ole Yes, it makes a lot of sense and you can utilize the full power of openHab including many devices in different technologies. But if you - like me - has a conservative approach and wan’t ihc to hold all logic you would instead feed ihc with the temp., wind and other inputs and let a fb control everything. Then openHab becomes an advanced remote control. I have learned that the 0-10 volt adapter from Zigza is quite useful when feeding ihc with analog input.

    So it depends on which approach you have  :-)

     

  12. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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.

     

  13. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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.

  15. openHAB2 IHC binding

    i OpenHAB

    Besvaret

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

  16. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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.


     

  17. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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 ?

  18. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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.

  20. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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. 

  21. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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.

  22. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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.

  23. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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.

     

     

     

  24. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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

     

  25. openHAB2 IHC binding

    i OpenHAB

    Besvaret

    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.

×
×
  • 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.

  I accept

1200x630bb.png

ok