Hop til indhold
IHC-User.dk

EjvindHald

Members
  • Antal indlæg

    123
  • Medlem siden

  • Senest besøgt

  • Days Won

    2

EjvindHald last won the day on June 22

EjvindHald had the most liked content!

Om EjvindHald

  • Rang
    Member

Profile Information

  • Location
    København

Seneste besøgende på profilen

Blokken med seneste besøgende er deaktiveret, og bliver ikke vist til andre

  1. EjvindHald

    openHAB2 IHC binding

    @Pauli AnttilaSo will you ensure that this new IHC binding 2 will become a part of the openHAB package? Thank you very much for your effort so far.
  2. EjvindHald

    openHAB2 IHC binding

    Hi @Pauli Anttila Thanks for clarifying. I have now removed the pulseWidth on setting the numeric value, and everything is working fine.
  3. EjvindHald

    openHAB2 IHC binding

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

    openHAB2 IHC binding

    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.
  5. EjvindHald

    SMS besked

    Det hele er fint beskrevet i LK's vejledning, som du kan finde her.
  6. EjvindHald

    openHAB2 IHC binding

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

    openHAB2 IHC binding

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

    openHAB2 IHC binding

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

    openHAB2 IHC binding

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

    OpenHAB og Visility

    Se keepalive regel her lavet af @Claus Skovgaard. Det kan muligvis være løsningen på problemet.
  11. EjvindHald

    openHAB2 IHC binding

    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.
  12. EjvindHald

    openHAB2 IHC binding

    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.
  13. EjvindHald

    openHAB2 IHC binding

    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.
  14. EjvindHald

    openHAB2 IHC binding

    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.
  15. EjvindHald

    openHAB2 IHC binding

    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
×

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.