Hej Mikkel,
Det lykkedes at få Java omkonfigureret, så jeg igen kunne få adgang til min kontroller. Jeg "fandt" dokumentationsfunktionen i IHC Captain og i den står enhedsId'en faktisk også. Fedt!!!
Bjarne
Hej. Jeg er begyndt at integrere OpenHab med IHC og andre installationer i huset. Jeg har fået kontakt til controller via PaperUI, og har oprettet en items fil, hvor jeg så linker kanalerne fra Paper UI til de items jeg har lavet (for at jeg kan se dem i Basic UI på min app på telefonen).
Jeg kan tænde og slukke lys (relæ) fra openhab, og får tilbagemeldinger på switch kontakter i openhab hvis jeg trykker de fysiske tryk.
Jeg kan styre mine wireless dimmere fra openhab via slider, men der får jeg ikke nogen tilbagemelding på slideren, hvis jeg regulere/tænder/slukker på de fysiske tryk. Jeg kunne forestille mig, at det er fordi jeg ikke har lavet det helt korrekt.
Dimmerne har jeg oprettet som channels i PaperUI, som Rollershutter, fordi det var det eneste jeg kunne få til at virke. Jeg ved ikke om dette er rigtigt?
Jeg kunne egentligt bedst tænke mig, at få kontakt til det hele via .items filer uden at skulle linke igennem PaperUI, men jeg kan simpelthen ikke lure hvordan jeg gør dette. Hvis jeg taster recourse id ind i min items fil, sker der nul og nada. (Sikkert fordi det ikke er sat ordentligt op) Måske både config. og .items. Det er her jeg virkelig godt kunne bruge lidt hjælp for at komme videre. Eventuelt få nogle eksempler på, hvordan man laver .items for både switch, dimmer, temperatur (gerne med mulighed for at ændre værdier til controller, for at kunne regulerer rumvarme)
Min items fil ser sådan her ud nu, hvor jeg har forsøgt at lægge et par recourse id ind, men disse har pt ingen funktion, da jeg kun kan styre, hvis jeg opretter link til de channels PaperUI selv henter fra controller, hvilket jeg egentligt helst ville undgå.
Group Home "D. G. Monrads Vej 11" <house>
Group Kitchen "Køkken" <kitchen> (Home)
Group LivingRoom "Stue" <sofa> (Home)
Group Bedroom "Soveværelse" <bedroom> (Home)
Group KidsRoom "Benyamins Værelse" <bedroom> (Home)
Group Office "Kontor" <office> (Home)
Group Corridor "Gang" <corridor> (Home)
Group Bathroom "Badeværelse" <bath> (Home)
Group Toilet "WC" <toilet> (Home)
Group LaundryRoom "Bryggers" <washingmachine> (Home)
Group Garage "Garage" <garage> (Home)
Group Outside "Udvendig" <garden> (Home)
Group Neato "Neato" <neato> (Home)
Switch Kitchen_Pendel "Køkkenbord" <light> (Kitchen, gLight) {channel=""}
Switch Kitchen_Sokkel "Køkkensokkel" <light> (Kitchen, gLight) {channel=""}
Dimmer Kitchen_Spots "Spots Køkken" <light> (Kitchen, gBlind) {channel="29459037"}
Switch LivingRoom_Spisebord "Spisebord" <light> (LivingRoom, gLight) {channel=""}
Switch LivingRoom_TV "Lys TV" <light> (LivingRoom, gLight) {channel=""}
Dimmer LivingRoom_Spots "Spots Stue" <light> (LivingRoom, gBlind) {channel="29455709"}
Switch Bedroom_SengH "Sengelampe Venstre" <light> (Bedroom, gLight) {channel=""}
Switch Bedroom_SengV "Sengelampe Højre" <light> (Bedroom, gLight) {channel=""}
Dimmer Bedroom_Spots "Spots Soveværelse" <light> (Bedroom, gBlind) {channel="17977437"}
Dimmer KidsRoom_Spots "Spots Benyamin" <light> (KidsRoom, gBlind) {channel="19827293"}
Switch Office_Spots "Spots Kontor" <light> (Office, gLight) {channel=""}
Dimmer Corridor_Spots "Spots Gang" <light> (Corridor, gBlind) {channel="17974109"}
Switch Bathroom_Spejl "Spejllys" <light> (Bathroom, gLight) {channel=""}
Switch Bathroom_Brus "Brusekabine" <light> (Bathroom, gLight) {channel=""}
Dimmer Bathroom_Spots "Spots Bad" <light> (Bathroom, gBlind) {channel="17980765"}
Dimmer Toilet_Spots "Spots WC" <light> (Toilet, gBlind) {channel="25042781"}
Switch LaundryRoom_Spots "Spots Bryggers" <light> (LaundryRoom, gLight) {channel=""}
Switch Garage_Spots "Spots Garage" <light> (Garage, gLight) {channel=""}
Switch Garage_Arbbord "Arbejdsbord" <light> (Garage, gLight) {channel=""}
Switch Garage_Kompressor "Kompressor" <light> (Garage, gLight) {channel=""}
Dimmer Outside_SpotsHus1 "Spots Hus 1" <light> (Outside, gBlind) {channel="11581789"}
Dimmer Outside_SpotsHus2 "Spots Hus 2" <light> (Outside, gBlind) {channel="11585117"}
Dimmer Outside_SpotsGarage "Spots Garage" <light> (Outside, gBlind) {channel="11588445"}
Dimmer Outside_SpotsSkur "Spots Skur" <light> (Outside, gBlind) {channel="27711837"}
Hjælp, eksempler og grundig forklaring modtages med kyshånd - da jeg virkelig brænder for at komme videre med dette projekt. Jeg er bare kørt lidt fast.
Haha, ja det glemte jeg så lige i farten. Havde ellers siddet og lavet det Sgu da godt jeg gemte det i min dropbox, så jeg kan komme til den nu.
Har i øvrig lige editeret i ovenstående items og sitemap og markeret de linjer røde, som er dem vi snakker om.
Og så får du også lige screendump af hvordan sitemap ser ud i BasicUI.
Edit igen.. Nu opdagede jeg lige, at jeg har faktisk lavet en fejl i min items fil i beskrivelse af trykkene. Jeg har byttet om på højre og venstre.
Derfor ser det forkert ud i sitemap filen. Men fordi IHC IDén er rigtig, så er det kun rent visuelt at det har betydning.
Apropos det med at jeg har linket trykkene, så er det endnu ikke noget jeg har besluttet mig for, om jeg vil gøre fast eller ej. Reelt set behøver man det ikke, da du kan påvirke dimmeren direkte enten i Fbén eller direkte på produkt-siden i Visual. Årsagen til jeg startede ud med at bruge trykkene, det var med den tanke, at hvis jeg en dag ikke gad OpenHab mere, så kan jeg bare slukke Rpién, og IHC controlleren kørere videre som om intet er sket. Men efterhånden som jeg er kommet dybere ind i OpenHab, så hælder jeg mere og mere til at slet ikke tage hensyn til IHC controlleren mere. Faktisk sad jeg den anden dag og overvejede at lave alt i OpenHab. Og IHC programmet bare vil indeholde produkterne. Dvs ingen Fbére overhovedet. Principielt kan man sagtens gøre det sådan. Men man skal tænke sig om, for hvad nu hvis.... Så er det godt at have et fungerende IHC program i baghånden, inden man springer ud i en fuldblods OpenHab løsning. JEg skal bare lige overbevise mig selv om det sidste, plus jeg skal lærer alt indgående i Openhab, specielt i forbindelse med rules.. Det er en hård omgang.
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
Bjarne B. Dollerup modtog omdømme point Mikkel Skovgaard i Kan ikke logge på Visual Controller
Bjarne B. Dollerup gav omdømme point til Michael Tøttrup i OpenHab, hjælp til en begynder