Hop til indhold
  • 0

Openhab/IHC anbefaling af setup


ThomasHej
 Share

Spørgsmål

Folkens,

Jeg har købt mig en Raspberry PI og har fået "kontakt" til min IHC.  Jeg har oprettet en items fil, og linket et fysisk output og oprettet et test panel og HabPanel og minsanten det hele virker.  Så langt så godt.

Men, nu er mit spørgsmål: Hvorledes er anbefalingen til opsætning...

Det virker som en utrolig dårlig idé direkte at manipulere med de fysiske outputs, og jeg ville i virkeligheden meget hellere betragte OpenHAB som en alternativ måde at "trykke på knapperne" på, og så lade IHC logikken styre tingene efter der er "trykket på knappen".

Så helt konkret:

Jeg har en kontakt (Input) som via en funktionsblok tænder et lampested med en timer-sluk og blinker med en diode når den er tændt.  Jeg ønsker ikke fra OpenHab at tænde for lampestedet direkte da det vil bypasse al logik. 

Jeg vil helst fra OpenHab kunne "Trykke på knappen" og så måske aflæse status enten fra diode-output eller fra lampestedet direkte.  Altså en ID til at trykke på knappen, og et andet ID til at aflæse status. 

Skal jeg virkelig selv kode "Sæt ON", vent 150ms, "Sæt OFF" logik i OpenHab eller er der en smartere måde.

 

Hvad gør I andre?

 

Thomas

Link til kommentar
Del på andre sites

17 svar på dette spørgsmål

Recommended Posts

  • 0

Hej Nielsen,

Tak for svar...  Desværre table du mig undervejs...

Kan du fortælle præcise hvilke filer jeg skal oprette, hvor de skal ligger, og deres indhold.

Jeg har lavet en .rules fil og en sitemap fil.  Jeg kan få min "knap" til at vise sig selv og med "Tryk" som action i UI, og når jeg trykker på den, tænder eller slukker lyset, men derefter "hænger" knappen i "ON"-state og "Tryk" lyser konstant.

Det er helt som om rules ignoreres.

Her er indhold af min kontor.rules fil:

--------

rule "tryk_KontorUL"
when
        Item KontorUL received update ON
then
        sendCommand(KontorUL, OFF)
end

------

Og her er indhold af min kontor.items fil:

------

Switch KontorUL {ihc="0x322c5c"}
-----

Og endelig, her er indhold af min kontor.sitemap fil:

------

sitemap demo label="Main menu"
{
        Frame label="Frame"
        {
        Switch item=KontorUL label="KontorULLabel" mappings=[ON="Tryk"]
        }
}

Og bare for at være helt komplet, snippet fra min .VIS fil...

----

         <product_airlink id="_0x322b54" product_identifier="_0x4404" device_type="_0x807" name="Kombi relæ 4 tast" serialnumber="_0x640713450014" locked="yes" enduser_report="yes" position="Kontor Spots" icon="_0x85">
            <airlink_input id="_0x322c5c" name="Tryk (øverst venstre)" address_channel="_0x1">
               <link_from_resource id="_0x325e2d" name="Følg Link" icon="_0x47" link="_0x325f2c"/>
               <link_from_resource id="_0x32642d" name="Følg Link" icon="_0x47" link="_0x32652c"/>
            </airlink_input>
            <airlink_input id="_0x322d5c" name="Tryk (øverst højre)" address_channel="_0x2">
               <link_from_resource id="_0x32602d" name="Følg Link" icon="_0x47" link="_0x32612c"/>
               <link_from_resource id="_0x32662d" name="Følg Link" icon="_0x47" link="_0x32672c"/>
            </airlink_input>
            <airlink_input id="_0x322e5c" name="Tryk (nederst venstre)" address_channel="_0x3"/>
            <airlink_input id="_0x322f5c" name="Tryk (nederst højre)" address_channel="_0x4"/>
            <airlink_relay id="_0x32305e" name="Udgang" address_channel="_0x1" backup="yes">
               <link_to_resource id="_0x32632c" name="Følg Link" icon="_0x4a" link="_0x32622d"/>
            </airlink_relay>
 

 

Hvad er det som jeg gør forkert?

På forhånd tak,

Thomas

Link til kommentar
Del på andre sites

  • 0

Hej Thomas

Jeg sætter min rule på input op som i dette eksempel:

rule "kip spisebord"
when
 Item SpisestueOH received update ON
then Thread::sleep(150)
  sendCommand(SpisestueOH,OFF)
  Thread::sleep(300)
end

Den sidste sleep på 300 ms er for at undgå at den kipper nok engang.

Desuden er det vigtigt, at du ikke aflæser status for IHC på dit input, og det gør ved at tilføje et > tegn foran adressen.

Dvs. Switch KontorUL {ihc=">0x322c5c"}

Ellers kan den netop gå i selvsving.

Så skulle det gerne virke :-)

mvh / Ejvind

--

Rettelse:

Længere nede i denne tråd er der forslag fra Claus om at bruge ekstra funktioner i IHC Binding, og det betyder, at man ikke behøver gøre, som jeg tidligere skrev her. Brug i stedet metoden fra Claus, og det hele bliver mere simpelt.

Redigeret af EjvindHald
Forslag fra Clus
Link til kommentar
Del på andre sites

  • 0

Hej Thomas

Undskyld det sene svar , 2017 er startet med 200kmt :-(

Nå men hjalp Ejvinds svar ?

Openhab kan startes i debug mode , der kan man se om ens "rule" bliver startet og hvis den indeholder fejl.

hvilken version af Openhab bruger du ? (kan varmt anbefale 2.0) 

prøv og tilføje autoupdate="false"  efter din item

dvs.   Switch KontorUL {ihc=">0x322c5c", autoupdate="false" }

mvh.

Nielsen

Link til kommentar
Del på andre sites

  • 0
På ‎30‎-‎12‎-‎2016 at 12:51 , ThomasHej skrev:

Folkens,

Jeg har købt mig en Raspberry PI og har fået "kontakt" til min IHC.  Jeg har oprettet en items fil, og linket et fysisk output og oprettet et test panel og HabPanel og minsanten det hele virker.  Så langt så godt.

Men, nu er mit spørgsmål: Hvorledes er anbefalingen til opsætning...

Det virker som en utrolig dårlig idé direkte at manipulere med de fysiske outputs, og jeg ville i virkeligheden meget hellere betragte OpenHAB som en alternativ måde at "trykke på knapperne" på, og så lade IHC logikken styre tingene efter der er "trykket på knappen".

Så helt konkret:

Jeg har en kontakt (Input) som via en funktionsblok tænder et lampested med en timer-sluk og blinker med en diode når den er tændt.  Jeg ønsker ikke fra OpenHab at tænde for lampestedet direkte da det vil bypasse al logik. 

Jeg vil helst fra OpenHab kunne "Trykke på knappen" og så måske aflæse status enten fra diode-output eller fra lampestedet direkte.  Altså en ID til at trykke på knappen, og et andet ID til at aflæse status. 

Skal jeg virkelig selv kode "Sæt ON", vent 150ms, "Sæt OFF" logik i OpenHab eller er der en smartere måde.

 

Hvad gør I andre?

 

Thomas

Hej Thomas

Jeg tænkte ligesom dig, at IHC installation altid skal fungere uafhængig af andre typer software. Og at man ikke skal springe IHC logik over. Så derfor har jeg brugt nogen tid på tryk på input - som jeg også angav tidligere i tråden - men er foreløbig kommet til den konklusion, at det ikke er hensigtsmæssigt. Det skyldes, at når du via Openhab aktiverer et input tryk, så er det ikke muligt på event bussen at se forskel på, om output er aktiveret via dette eller et faktisk fysisk tryk. Og den oplysning er nødvendig for at få status opdateret korrekt og undgå problemer med selvsving via cirkulære referencer.

Derfor gør jeg foreløbig følgende:

  • Ved de simple on/off eller kip så påvirker jeg output direkte i IHC, fordi der er ingen status eller lignende, som gemmes. Hvis der er en simpel logik som fx tænd LED i opus tryk, så har jeg gentaget denne logik i Openhab.
  • Ved de komplekse ting, hvor der er en eller flere funktionsblokke i brug, så har jeg netop fundet en god løsning til det, og den er beskrevet i dette indlæg. 

I begge tilfælde skal du ikke aktivere input tryk via Openhab, så dit problem forsvinder;). Dog er de komplekse ting lidt omstændige at sætte op i Visual, men metoden anbefalet af Henning fungerer.

Jeg synes, at det virker ret fint i mit setup nu. Men må dog også erkende, at der går nogle timer her i begyndelsen med det.

Ejvind

Rettelse:
Gør ikke som jeg skrev, men brug forslaget lige herunder fra Claus, hvor der gøres brug af ekstra funktioner i IHC binding. Det gøre det hele meget nemmere, og man behøver ikke gentage funktioner i Openhab eller slå inputtryk fra via rules.

Redigeret af EjvindHald
Forslag fra Claus Skovgaard
Link til kommentar
Del på andre sites

  • 0
På 17/1/2017 at 22:18 , EjvindHald skrev:

Hej Thomas

Jeg tænkte ligesom dig, at IHC installation altid skal fungere uafhængig af andre typer software. Og at man ikke skal springe IHC logik over.

Jeg har også samme holdning. I dette tilfælde at OpenHAB er et add-on til IHC installationen, hvor kommunikationen bør gå via kontakterne eller dedikerede FB'ere, så IHC selv står for logikken og ikke er afhængig af at OpenHAB kører.

I forbindelse med de udfordringer I har haft med dette og de forskellige løsninger man kan overveje, vil jeg lige starte med at lave en lille analyse af forskellene mellem IHC og OpenHAB på "kontakt-området". Dette er for at klarlægge mulighederne man har når man skal mappe sine IHC tryk over i OpenHAB.

  1. IHC (den fysiske verden):
    1. Kontakterne kan ikke vise tilstand
    2. Kontakternes "sluttetid" bestemmes af den der trykker
    3. Et kontakt kan have en diode associeret, men rent teknisk har denne jo intet med kontakten at gøre
  2. IHC (software):
    1. Et tryk kan fx fremkalde et scenarie, skrue op/ned for lyd, styre en markise el. og associeres så umiddelbart ikke med nogen (binær) tilstand
    2. Et tryk kan have en kip-funktion (simpel eller avanceret) og kan så associeres med tilstanden on/off
  3. OpenHAB kontakterne kan konfigureres til at være en:
    1. Traditionel kontakt (viser tilstand)
      Switch ihc_tryk1 {ihc="0x13b6045d"}

      I OpenHAB vises en kontakt der repræsenterer IHC værdien og samtidig kan ændre den.

    2. Trykknap (som IHC)
      Switch ihc_tryk2 {ihc=">[ON:0x14268d11:100]", autoupdate="false"}

      Syntaksen ":100" betyder at det linkede IHC input (kan fx være et fysisk tryk) sættes on i 100ms (svarende til et tryk på en IHC kontakt). I OpenHAB vises én knap.

    3. Scenarieknap (on/off for Switch item og muligvis mere avancerede ved fx Number item - har ikke prøvet endnu)
      Switch ihc_tryk3 {ihc=">[ON:0x13b6025f:200],>[OFF:0x13b60360:200]", autoupdate="false"}

      Som ovenfor, men her vises i OpenHAB to knapper med hver deres link til IHC, som fx kan være til tænd og sluk på en FB.

Da der i IHC ikke findes traditionelle kontakter har 3.1 umiddelbart lille værdi i denne kontekst. Ved linkning til FB'ere findes der dog eksempler på konstante input signaler man kunne forestille sig brugt, fx serviceafbryder til alarm FB'en, ude/hjemme tilstand, hjemmesimulering m.m. hvis dette ikke styres automatisk.

Konfigurationen 3.2 svarer 1:1 til et IHC tryk, bortset fra man på forhånd bestemmer sluttetiden og dermed ikke kan kombinere fx kort og langt tryk på samme knap. Hvis man vil det kan man benytte 3.3 og i sitemap opsætte strengene på knapperne, fx

.items:
Switch ihc_tryk3_1 {ihc=">[ON:0x13b6025f:200],>[OFF:0x13b6025f:1000]", autoupdate="false"}

.sitemap:
Switch	item=ihc_tryk3_1 mappings=[ON="Kort", OFF="Langt"]

Til sidst vil jeg lige gennemgå hvordan jeg håndterer de situationen med knapper hvor jeg gerne vil have en tilstand associeret.

Situationer med dioden sammen med trykket kan løses ved at have et Switch item for trykket (3.2) og et input Switch item for dioden som vises med ikon/tekst i stedet for en knap:

.items:
Switch ihc_tryk2_1 {ihc=">[ON:0x14268d11:100]", autoupdate="false"}
Switch ihc_diode1 "diode" <onoff> {ihc="<0x128f1212"}

.sitemap
Switch item=ihc_tryk2_1
Text item=ihc_diode1

Ikon og tekst kan opsættes helt som man har lyst til. Denne metode kan også bruges ved avanceret feedback (tekst eller tal). Fx hvor tryk på en knap skifter igennem et antal scenarier.

Der er dog et lidt smartere måde at gøre det på, hvor man faktisk tager 3.1 i brug. Man kan opsætte et input link og samtidig to output links. Dermed får man en trykknap med med feedback fra et vilkårligt sted. Bemærk dog at det ikke giver den store mening at linke med en diode der fx blinker.

.items:
Switch ihc_tryk_feedback "Ventilator" <onoff> {ihc="<0x143cc712,>[ON:0x143cc311:100],>[OFF:0x143cc311:100]"}

.sitemap
Switch item=ihc_tryk_feedback

Man kan linke ON/OFF til samme (kip tryk) eller direkte til tænd/sluk på en FB'en. Og input link kan fx være "lys indikation" fra en lampen.

Jeg håber det kan bruges. Det har løst de fleste af mine behov indtil videre. Og bemærk at der ikke kræves nogen brug af rules.

Mvh Claus

Link til kommentar
Del på andre sites

  • 0
3 timer siden, Claus Skovgaard skrev:

Jeg har også samme holdning. I dette tilfælde at OpenHAB er et add-on til IHC installationen, hvor kommunikationen bør gå via kontakterne eller dedikerede FB'ere, så IHC selv står for logikken og ikke er afhængig af at OpenHAB kører.

I forbindelse med de udfordringer I har haft med dette og de forskellige løsninger man kan overveje, vil jeg lige starte med at lave en lille analyse af forskellene mellem IHC og OpenHAB på "kontakt-området". Dette er for at klarlægge mulighederne man har når man skal mappe sine IHC tryk over i OpenHAB.

  1. IHC (den fysiske verden):
    1. Kontakterne kan ikke vise tilstand
    2. Kontakternes "sluttetid" bestemmes af den der trykker
    3. Et kontakt kan have en diode associeret, men rent teknisk har denne jo intet med kontakten at gøre
  2. IHC (software):
    1. Et tryk kan fx fremkalde et scenarie, skrue op/ned for lyd, styre en markise el. og associeres så umiddelbart ikke med nogen (binær) tilstand
    2. Et tryk kan have en kip-funktion (simpel eller avanceret) og kan så associeres med tilstanden on/off
  3. OpenHAB kontakterne kan konfigureres til at være en:
    1. Traditionel kontakt (viser tilstand)
      
      Switch ihc_tryk1 {ihc="0x13b6045d"}

      I OpenHAB vises en kontakt der repræsenterer IHC værdien og samtidig kan ændre den.

    2. Trykknap (som IHC)
      
      Switch ihc_tryk2 {ihc=">[ON:0x14268d11:100]", autoupdate="false"}

      Syntaksen ":100" betyder at det linkede IHC input (kan fx være et fysisk tryk) sættes on i 100ms (svarende til et tryk på en IHC kontakt). I OpenHAB vises én knap.

    3. Scenarieknap (on/off for Switch item og muligvis mere avancerede ved fx Number item - har ikke prøvet endnu)
      
      Switch ihc_tryk3 {ihc=">[ON:0x13b6025f:200],>[OFF:0x13b60360:200]", autoupdate="false"}

      Som ovenfor, men her vises i OpenHAB to knapper med hver deres link til IHC, som fx kan være til tænd og sluk på en FB.

Da der i IHC ikke findes traditionelle kontakter har 3.1 umiddelbart lille værdi i denne kontekst. Ved linkning til FB'ere findes der dog eksempler på konstante input signaler man kunne forestille sig brugt, fx serviceafbryder til alarm FB'en, ude/hjemme tilstand, hjemmesimulering m.m. hvis dette ikke styres automatisk.

Konfigurationen 3.2 svarer 1:1 til et IHC tryk, bortset fra man på forhånd bestemmer sluttetiden og dermed ikke kan kombinere fx kort og langt tryk på samme knap. Hvis man vil det kan man benytte 3.3 og i sitemap opsætte strengene på knapperne, fx


.items:
Switch ihc_tryk3_1 {ihc=">[ON:0x13b6025f:200],>[OFF:0x13b6025f:1000]", autoupdate="false"}

.sitemap:
Switch	item=ihc_tryk3_1 mappings=[ON="Kort", OFF="Langt"]

Til sidst vil jeg lige gennemgå hvordan jeg håndterer de situationen med knapper hvor jeg gerne vil have en tilstand associeret.

Situationer med dioden sammen med trykket kan løses ved at have et Switch item for trykket (3.2) og et input Switch item for dioden som vises med ikon/tekst i stedet for en knap:


.items:
Switch ihc_tryk2_1 {ihc=">[ON:0x14268d11:100]", autoupdate="false"}
Switch ihc_diode1 "diode" <onoff> {ihc="<0x128f1212"}

.sitemap
Switch item=ihc_tryk2_1
Text item=ihc_diode1

Ikon og tekst kan opsættes helt som man har lyst til. Denne metode kan også bruges ved avanceret feedback (tekst eller tal). Fx hvor tryk på en knap skifter igennem et antal scenarier.

Der er dog et lidt smartere måde at gøre det på, hvor man faktisk tager 3.1 i brug. Man kan opsætte et input link og samtidig to output links. Dermed får man en trykknap med med feedback fra et vilkårligt sted. Bemærk dog at det ikke giver den store mening at linke med en diode der fx blinker.


.items:
Switch ihc_tryk_feedback "Ventilator" <onoff> {ihc="<0x143cc712,>[ON:0x143cc311:100],>[OFF:0x143cc311:100]"}

.sitemap
Switch item=ihc_tryk_feedback

Man kan linke ON/OFF til samme (kip tryk) eller direkte til tænd/sluk på en FB'en. Og input link kan fx være "lys indikation" fra en lampen.

Jeg håber det kan bruges. Det har løst de fleste af mine behov indtil videre. Og bemærk at der ikke kræves nogen brug af rules.

Mvh Claus

Hej

Jeg tillader mig lige at blande mig lidt ,er ved at lære openhab2  lidt at kende så lige et par extra spørgsmål.

Er det openhab "1"   i taler om her ? ,jeg tænkte om en af jer ved hvordan man kan få ihc items ind i classic ui eller kan man kun bruge ihc items i HABPanel ?

jeg har openhab2 installeret og har fået kontakt med ihc nu og kan nu "Switch" lidt med ind og udgange det virker fint ,men hvis det skal blive rigtigt smart

for at kunne bruge openhab app så skal items jo ind i classic for at man kan se dem og bruge dem til noget .

 

Hilsen Simon.

Link til kommentar
Del på andre sites

  • 0
12 timer siden, Simon Thorsted skrev:

Hej

Jeg tillader mig lige at blande mig lidt ,er ved at lære openhab2  lidt at kende så lige et par extra spørgsmål.

Er det openhab "1"   i taler om her ? ,jeg tænkte om en af jer ved hvordan man kan få ihc items ind i classic ui eller kan man kun bruge ihc items i HABPanel ?

jeg har openhab2 installeret og har fået kontakt med ihc nu og kan nu "Switch" lidt med ind og udgange det virker fint ,men hvis det skal blive rigtigt smart

for at kunne bruge openhab app så skal items jo ind i classic for at man kan se dem og bruge dem til noget .

 

Hilsen Simon.

Hej Simon. Det gælder for så vidt både OH1 og OH2. IHC bindingen virker i OH2 i legacy mode - dvs du skal lave opsætningen ligesom i OH1 med .items fil (linkning) og .sitemap fil (præsentation/brugerflade). Før nogen opgraderer IHC bindingen til OH2, kan du ikke gøre som du snakker om.

Link til kommentar
Del på andre sites

  • 0

Det er nogle gode forslag, som Claus kommer med, og via disse kan man bruge input fra Openhab2. Men konsekvensen er, at man i UI får både en on/off knap og en statusvisning af fx en lampe fuldstændig som i den fysiske verden. Hvis man vil kun vil have én knap eller ikon i UI til både at vise status og ændre status, så er man nødt til enten at gentage logik i Openhab eller bruge forslaget for Henning, som jeg har linket til tidligere i denne tråd.

Link til kommentar
Del på andre sites

  • 0
10 timer siden, EjvindHald skrev:

Hvis man vil kun vil have én knap eller ikon i UI til både at vise status og ændre status, så er man nødt til enten at gentage logik i Openhab eller bruge forslaget for Henning, som jeg har linket til tidligere i denne tråd.

Er det ikke det man opnår netop i den sidste metode jeg beskriver? Eller misforstår jeg?

På 2/2/2017 at 16:15 , Claus Skovgaard skrev:

Der er dog et lidt smartere måde at gøre det på, hvor man faktisk tager 3.1 i brug. Man kan opsætte et input link og samtidig to output links. Dermed får man en trykknap med med feedback fra et vilkårligt sted. Bemærk dog at det ikke giver den store mening at linke med en diode der fx blinker.


.items:
Switch ihc_tryk_feedback "Ventilator" <onoff> {ihc="<0x143cc712,>[ON:0x143cc311:100],>[OFF:0x143cc311:100]"}

.sitemap
Switch item=ihc_tryk_feedback

Man kan linke ON/OFF til samme (kip tryk) eller direkte til tænd/sluk på en FB'en. Og input link kan fx være "lys indikation" fra en lampen.

 

Link til kommentar
Del på andre sites

  • 0

Jeg er nødt til at have det her switch een gang til, for prins knud!

Hvis jeg bruger denne (Claus´s eksempel 3.2) i items:

  • Switch ihc_tryk2 {ihc=">[ON:0x14268d11:100]", autoupdate="false"}


Og denne i sitemap:

  • Switch item=ihc_tryk2


Så ender jeg ud med en switch i sitemap som IKKE tilbagestiller sig selv. Hvordan det er lig med et IHC tryk 1:1 det er mig en gåde??

Indtil nu har jeg brugt en rule som tilbagestiller knappen (switch). Men som jeg forstod på Claus´s indlæg, så skulle ovenstående være uden brug af en rule. Eller har jeg misforstået det?

I øvrig, hvad er det præcist den der autoupdate="false" gør?
Og hvorfor var det lige man skulle indsætte et > før IHC syntaks?
 

Link til kommentar
Del på andre sites

  • 0
43 minutter siden, Kandersen skrev:

Så ender jeg ud med en switch i sitemap som IKKE tilbagestiller sig selv. Hvordan det er lig med et IHC tryk 1:1 det er mig en gåde??

Du skulle gerne ende med en knap ala:

IMG_6990.PNG.46dd2accd10a33bc09428932fc8fdf0f.PNG

Måske er det nødvendigt at tilføje en mapping i din Sitemap ala:

Switch  item=ihc_Godnat mappings=[ON="Aktiver"]

autoupdate angiver om knappen kan/skal opdateres fra bindingens side (IHC)

> betyder en binding udelukkende med kommunikation til IHC (og ikke retur)

Link til kommentar
Del på andre sites

  • 0
2 minutter siden, Claus Skovgaard skrev:

Måske er det nødvendigt at tilføje en mapping i din Sitemap ala:

Switch  item=ihc_Godnat mappings=[ON="Aktiver"]

Det er nødvendigt. Ellers ender man med den der standard skydeknap. Det var det der var mit problem. Med mappings som i dit eksempel, så fungere det i sitemap. 
 

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