Leaderboard

Fedt det virker. Men jeg forstår ikke hvorfor du overhovedet har det problem, den er jo nærmest identisk med mine. Og de virker 100%. Een ting er dog sikkert. Ovenstående items er ikke korrekt. du har en [ for meget " [[lighting]" i den linje. Stop lige op og pust ud et øjeblik mens du får lidt ilt til hjernen. Dine punkter skal du vist lige tænke lidt mere over. Hvad er det præcis du gerne vil? Nu har du bevist at din IHC controller kan kommunikere med din OpenHab2 server. Så er det nu du skal tænke over, hvad det så er du vil bruge det til. Som jeg nævnte tidligere, så giver det ingen mening at bede OpenHab2 gøre noget, som IHC controlleren gør mindst lige så godt. Når jeg læser dine punkter herover, så virker det som om du i gang med at gå over åen efter vand. Det kan jeg absolut kun fraråde. Selvom det er muligt, så giver det som sagt ingen mening. Udover det er det en masse unødig arbejde og kommunikation du skal lave i OpenHab2 og IHC controlleren. Så: (lidt lang og måske kedeligt forsøg på pædagogisk forklaring, som jeg ville gøre det og har opfattelsen af, at man bruger en enhed som OpenHab bedst til samme med IHC). Defintion logik: Logik i IHC controlleren = Funktionsblokke Logik i OpenHab = Rules/automatik. A. IHC tryk eller hændelser der skal styre andre IHC komponenter - Hold logikken i IHC controlleren. B. Openhab tryk/komponenter/hændelser (things/items) der skal styre IHC komponenter - Hold logikken i IHC controlleren. C. IHC tryk eller hændelser der skal styre andre (OpenHab) komponenter (things/items) - Hold logikken i Openhab. D. OpenHab komponenter (things/items) der skal styre andre OpenHab komponenter (things/items). Hold logikken i OpenHab. Du skal opfatte OpenHab som et binde-led mellem flere "ting", hvor IHC controlleren er en "ting". Det der adskiller IHC controlleren fra mange andre "ting" er, at den har logik styring og automatik i sig selv, ligesom fx en Philips Hue også har. Det betyder ikke at man SKAL bruge denne logik styring/automatik, men det giver nogle andre muligheder i forbindelse med påvirkninger ud og ind. Og det kan i netop IHC´s tilfælde være en væsentlig fordel at holde logikken i IHC controlleren. Et eksempel på to "ting", der arbejder sammen via OpenHab. 1. ting - IHC controlleren 2. ting - en Zwave PIR. Målet er at bruge zwave PIR til at skabe en hændelse i IHC, fx tænde et (IHC) lys i en bestemt tid. I IHC har mit udvendige lys. Det er dette jeg vil tænde på zwave PIR. Jeg opretter en funktionsblok til PIR styring i IHC, hvor logikken er i, og udgangen til mit udvendige lys også er forbundet. PIR indgangen på denne funktionsblok oprettes som en "item" i OpenHab: item ihc_pir_indgang Zwave PIRén oprettes ligeledes som en "item" i OpenHab. item: zwave_pir Nu kender OpenHab de to "ting" som der skal påvirkes. Nu skal jeg bare kæde dem sammen som var mit mål. Dvs når zwave pir går ON, så skal pir indgangen i IHC funktionsblokken også gå ON. Og når den går OFF, så skal PIR indgangen også gå OFF. Og det gør jeg via en simpel rule som er lig med den jeg sendte tidligere: rule "zwave pir ON" when Item zwave_pir changed from OFF to ON then ihc_pir_indgang.sendCommand(ON) end rule "zwave pir OFF" when Item zwave_pir changed from ON to OFF then ihc_pir_indgang.sendCommand(OFF) end Jeg kunne godt have lavet al logikken i OpenHab, og så sendt en kommando direkte til lys udgangen på IHC controlleren. Men det er her det snedige med IHC controlleren kommer ind. For funktionsblokken i IHC har jo allerede givet mig den logik styring/automatik, som jeg ellers skulle lave i OpenHab. Så hvorfor pokker skulle jeg så ikke bare udnytte det. Egentlig tror jeg også at ovenstående kunne gøres uden en rule, ved at linke de to items direkte sammen. Men jeg har ikke forsøgt det, plus at det ikke giver mig en garanti for, at når den ene er OFF så skal den anden også være OFF, og omvendt. Men jeg vil tro det kan lade sig gøre. Årsagen til at det er så simpelt, det er fordi det bare er en simpel slave funktion. ON=ON / OFF=OFF. I OpenHab kunne man godt have udvidet det til at indholde flere andre hændelser og eller forudsætninger, fx at ovenstående rule kun skal køre, hvis jeg er hjemme (OpenHab kender min mobil/tilstedeværelse). Så ville jeg skulle tilføje en 3. ting, item min_mobil, og så lade den indgå som en forudsætningen i rule i OpenHab, som jeg mener skal gøres med en AND funktion. (har ikke studeret den del så meget endnu, men det kommer jeg snart til). Så: Brug logikstyring/automatikken, der hvor det giver mest mening, nemmest og bedst egnet. Dvs du skal ikke lade et IHC tryk gå ind over OpenHab, for at tænde et IHC lys (uanset om det er wireless eller ON/OFF). Men det kan være en ide at definere dem alle som items i OpenHab, fordi så har du muligheden for at fx lade et andet tryk (zwave tryk) tænde det IHC lys, og et IHC tryk tænde fx en Philips Hue pære. Håber det giver bedre mening og forståelse. Det er meget banalt eksempel jeg stiller op her. Men når man først fanger ideen, så åbner der sig pludselig en helt anden verden, hvor der nærmest ikke er nogen grænser for, hvordan du kan kæde tingene sammen, kombinere dem og bruge det hele på kryds og tværs, og udnytter de enkelt "ting", der hvor de har deres styrke. I Philips Hue, som jeg også har, der har jeg defineret scener. (dvs i selve Hue brigden). Jeg bruger så IHC Captain til at aftaste IHC tryk. Så når jeg trykker på et bestemt IHC tryk, så tænder lamperne i stuen med en bestemt scene, (dvs farve og lysstyrke). Igen, jeg kunne godt definere scenen i OpenHab, (dvs sætte lamperne op i OpenHab via en rule). Men hvorfor gøre det, når nu Philips Hue giver mig en mulighed for at gøre det på en lidt nemmere måde, og jeg så kan bruge IHC Captain til at "kalde scenen". På et tidspunkt vil jeg måske ændre dette, så OpenHab overtager denne del af logikken. Men pt synes jeg det er nemmere i Philips Hue appen og IHC Captain. Så det handler altså også om, hvor man selv synes det er nemmest. Og så udnytte den del. En sidste lille detalje som jeg var lige ved at glemme: OpenHab har også UI (user Interface. BasicUI, ClassicUI eller Habpanel). Og nu bliver det først rigtig "sjovt". Det betyder at du direkte i OpenHab UI kan lave virtuelle items, som du kan bruge til at påvirke udaftil. Fx et virtuelt tryk i BasicUIl, som tænder dit IHC lys. BasicUI kan du så gå til via din PC, mobil eller lign. Dine virtuelle items kan du også kombinere i rules på kryds og tværs. Fx hvis du har defineret et virtuelt tryk i BasciUI som skal tænde dit IHC lys, så kan du i en rule sige, at det kun må lade sig gøre, hvis klokken er noget bestemt, eller skumring er ON, vinden blæser fra nord, solen er gået ned, konen har gjort sig sengeklar osv osv. Er det fx skumring, og du allerede har et skumringsrelæ på din IHC, så kan det igen give mening at bruge logikken i IHC controlleren. Dvs du definere skumringsrelæet som en item i OpenHab. Og vupti - så er du i samme princip som ovenstående eksempel. Min opfattelse er, at hvis man holder tungen lige i munden og tænker over hvad mål man har med fokus på, hvor ens "ting" har hver deres styrke, så kan man virkelig drive det her vidt. Man kan også skære igennem og køre et fuldt ud OpenHab setup, hvor man er ligeglade med alle "tingéne" og deres styrke, og laver alt i OpenHab. Min opfattelse er bare, at det er ikke noget man bare lige såen gør fra den ene dag til den anden. Plus at OpenHab på desværre mange punkter har en rigtig dårlig dokumentation og decideret manglende. Derfor er jeg startet ud med det basale og forsøger hakke mig igennem de udfordringer som OpenHab giver mig. Jeg har endnu ikke knækket nødden med kort/lang tryk. Min foreløbige opfattelse er, at det ikke kan lade sig gøre i OpenHab. Det giver desværre visse begrænsninger fx i forbindelse med fortrådet lysdæmpere Nok om det.. du har en spændende tid foran dig PS - Bemærk at når jeg skriver "ting" så er det med "". Det er fordi det hedder "Thing" i OpenHab. "Thing" har "items". "items" er dem der er interessante og som du bruger til at lave din styring/automatik. Fx min zwave PIR er en "Ting" med 6 forskellige "items" i sig. Motion PIR. Alarm, rystekontakt, lux, temperatur og hmm.. den sidste