Kandersen

Uden at ville genere nogen alt for meget, så er mit korte svar - Ja! Alle kan finde ud af det. Men det kræver man lige sætter sig en anelse ind i det. Og her kan man godt blive udfordret, hvis man ikke har nogen som helst erfaring med computere, andet end som almindelig bruger. 
Hvis du allerede er udfordret med en Rpi og SD kort, (specielt sidstnævnt), så bliver inlæreringsprocessen en anelse længere 

Den korte version:
Rpi = Raspberry Pi version 3B. Dette er en meget (MEGET) lille computer, som oftest vises bare som et printkort med nogle USB porte og netværks port i. Årsagen til at man kan købe den sådan, det er fordi mange, bla også i industrien, bygger den ind i noget som passer til deres behov. Til hjemmebrug anbefaler jeg et start-kit med kassen, strømforsyning og SD kort. Fx som dette: https://raspberrypi.dk/produkt/raspberry-pi-3-model-b-plus-starterkit/

SD kortet kopiere man selve operativ systemet ned på, inkl evt programmer, fx openhab2. Det er lidt ligesom at installere en windows fra en USB stick. Her er det bare et SD kort, fordi det er den kortlæser der sidder i RPién. Til openhab2, så er operativ systemet Linux baseret på openhabian (Debian). Det hele hentes i en og samme image fil, og kopieres på SD kortet. Så klare Rpién selv resten, når man har tændt den.

openHab2 findes også til windows og Mac, hvis man er mere fortrolig med det. Jeg har ikke selv rodet med det, selvom jeg faktisk er windows mand med stort M. Det siges at skulle fungere rigtig godt. Jeg synes bare det er lidt spild, at man skal have en windows/Mac computer til at stå og knurre 24/7, når en meget lille billig computer som Rpi kan gøre det mindst lige så godt. Til gengæld slås jeg så også med Linux konstant og fatter nada af det. Så ind imellem, fordi jeg roder med alt det jeg gør, så er jeg også virkelig udfordret på min tålmodighed. Linux er bare et djævle OS.

Jeg har stemmestyring på stort set alt IHC via Google Assistant (Google Home), dog foreløbig kun som test med lys, termostater, garageport, men det har kørt klippe stabilt i snart et par måneder, bortset fra få dage hvor enten Google har lavet ballade eller senest en fejl på openhabs cloud server).
Lige så snart jeg har tiden til det, så føres resten over på stemmestyring, (kun et spørgsmål om at lave de sidste linjer). Og flere Google Assistant enheder skal indkøbes.

Jeg kan tænde/slukke al lys, strøm/whatever som er sat til IHC installationen.
UNI400 dæmpere kan ikke dæmpes, fordi de kræver langt tryk. Og det er en massiv udfordring at simulere et menneskeligt langt tryk via et virtuelt emne uanset om det er stemmestyring eller virtuelle kontakter/tryk. Men dæmperne kan tændes og slukkes. Wireless dæmpere kan styre og dæmpes 100%.
Garageporten er bare en simpel puls på et output modul (over et reed relæ). Og kan derfor tændes via stemmestyring. Desværre er det puls, og det er straks værre at give mening, fordi man faktisk skal tænde al puls, både når man skal tænde og slukke.. Ligesom vi gør med trykkene. Dem tænder vi reelt også, for at slukke lyset. 
Der findes snedige metoder der løser dette, men jeg har ikke lige haft fokus på at ændre det endnu, men det kommer. Indtil betyder det fx, at jeg skal sige "tænd garageporten" for at åbne den. Og jeg skal efterfølgende sige "tænd garageporten" for at lukke den. Det er lidt akavet. Men det virker. Og det virker klippe stabilt. 
 
Termostaterne kan jeg styre helt som jeg vil. Hæve/sænke temperaturen (setpunkt), spørge indtil hvad temperaturen er osv osv. Senest er luftfugtighed også kommet på, så nu kan jeg spørge ind til hvad luftfugtigheden er. Umiddelbart kan det virke ligegyldigt, men... Nilan ventilationsanlægget er også på, foreløbig dog kun med Bruger Funktion. Dvs jeg kan aktivere Bruger Funktion via stemme kontrol. Det tager kun ganske kort tid at lave, så jeg kan justere ventilationen i de 4 trin som Nilan anlægget kan køre med, også via stemme kontrol. Så kan jeg fx bede Nilan anlægget om at sætte ventilationen på 3, når luftfugtigheden er højere end normalt.. (Ikke at jeg gider gøre det, fordi den del også kører automatisk via openHab2. Men jeg KAN gøre det, hvis jeg vil). 

Jeg kan også spørge ind til alt i huset, selvom jeg er ude. Dette kan jeg gøre via min Android mobil eller hvis jeg er i bilen, så kan jeg gøre det via Android Auto. Fx kan jeg spørge Google Home, om lyset er tændt i stuen. Og så får jeg svar retur, hvorvidt de 4 Philips Hue lamper vi har, er tændt eller slukket. (Philips Hue er IKKE en del af IHC installationen. Den del køre parallelt med Google Home og openHab2, og er pt det eneste jeg har forbundet til Google Home, udover openHab2).
 


Jeg bruger som nævnt openHab2 med Google Assistent (Google Home). (Amazon Alexa kan også bruges og er stort set det samme. Jeg ville bare helst have Google, da jeg tror mest på det). 

Hvad er krævet:
openHab2 kører på en Rpi 3B, hvilket reelt er den eneste hardware "dims" der skal til for at bruge stemmestyring.
Derud over bruger jeg en Google Home Mini, min Android mobil, samt i bilen, hvor der er Android Auto.  

Hvis man kun har fokus på stemmestyring til IHC installationen, så er det relativ nemt at sætte openHab2 op. (Jeg har planer om at lave en mindre artikel om det til et andet medie). 

openHab2 kommer med en færdig image fil, som man kopiere til et SD kort, og sætter SD kortet i Rpién, tænder den. Efter lidt tid (20 min), så er openhab2 installeret.
Derefter skal openhab2 konfigureres grundlæggende, og cloud connecteren skal installeres (openhab kommunikere med Google Assistant via cloud). 
Når det er gjort så skal IHC bindingen installeres. IHC bindingen er den der sørger for kommunikationen mellem IHC controlleren og openhab2. 

Når IHC bindingen er installeret, og der er forbindelse til IHC controlleren, så skal man ellers bare i gang med at finde de IHC funktioner man vil have i sin openhab2 inkl de tags der skal bruges til Google Assistant. Den del er nok den der tager længest tid. Men det er rimelig nemt, når man først har forstået ideen med det.
Det som IKKE er nemt ved openhab2, det er når man bliver lidt mere avanceret og vil have logik styret fra openhab2. Det er på mange måder openhab2´s virkelige forcé, men det er også til tider ekstremt komplekst.. Men med logikken IHC controlleren, så behøver man ikke bruge openhab2 til det. 
Det næste "problem" med openhab2 er, at når først man er kommet i gang med det, så tager det om sig. Og det er en ufattelig tidsrøver, fordi man praktisk talt kan alt. Jeg har fx kombineret hjemmet her med IHC med z-wave, zigbee, Wifi, Xiamoi, Modbus.. Og ja, nu også (snart) Wireless Mbus. Mit største problem er, at jeg har for mange ting i gang hele tiden, fordi jeg gerne vil teste ting, inden de føres ud i et samlet færdigt resultat. Min plan er at det hele en dag skal færdiggøres og der laves et ordentligt bruger interface som vil være en relativ stor skærm placeret centralt i huset, med indbygget Google Assistent på. Via denne skærm vil man kunne monitorere hele huset, samt området udenom, inkl kameraer. Lidt ligesom LK´s IHCtablet, bare voldsomt mere avanceret. Bemærk - Det er kun meningen det skal være en monitor. Man skal ikke kunne tænde/slukke noget fra den medmindre det er med stemmen. Selvom det er muligt, så synes jeg ikke det giver meget mening at sidde og trykke på en skærm/mobil eller andet, for at tænde/slukke lys eller andet.

Jeg ender nok med at det først er 100% færdigt og driftsikkert, når jeg engang skal på pension, med alle de planer jeg har med det. Men jeg har det sindsygt sjovt indtil da, og lærer (og tester) en masse. Hvis jeg bare havde kunnet begrænset mig til kun IHC installationen, så var det hele færdigt for længe siden 

Du skal være velkommen.

nix, og det vil næppe heller virke. Bare fordi Homey (og i øvrigt også mange andre base stationer, coordinatorer, gatways, fx zigbee og z-wave etc) har 868Mhz modtager, så er det langt fra sikkert de kan snakke sammen. Det handler nemlig om protokollen og ikke mindst kryptering. LK´s wireless protokol er krypteret. 

Jeg ville prøve det som Bjarne skriver..
1. Drop dimmeren i første omgang. Smid 230volt direkte på trafoen på primær siden (her kommer stikproppen ind), og se om der kommer lys.
2. Kommer der ikke lys, så er dimmeren udelukket som evt fejlkilde. Og trafoen er udelukkende som fejlkilde, i og med den er ny. Tilbage er pærerne og/eller tilslutningen til dem.
3. Start med at koble en eller to pære på trafoen samtidig, og fortsæt indtil problemet opstår (lyset slukker). Så har du indskrænket problemet til de(n) pære som fik lyset til at slukke. tænder lyset ikke på den første pære, så drop den og tag den næste. Tænder lyset heller ikke der, så drop den og tag den næste.. Sådan bliver du ved, indtil der kommer lys. Hvis der slet ikke kommer lys, så tilbage til trafoen, skift den, ud fra den betragtning, at selvom den er ny, så må den have en eller anden form for fejl. Tjek derefter igen med en pære ad gangen. 

Bemærk dog minimumbelastning for trafoen. Det er muligt du er nødt til at prøve med flere pærer på een gang. I så fald skal det komme an på kombinationer, om der er lys/ikke lys. 

Men først - Drop dimmeren!! Den kan virkelig lave ballade i en fejlsøgning, fx hvis den står til 1% men at du ikke kan se lyset faktisk er tænd ved den styrke.. Det er skidt at rive det hele fra hinanden, bare for at finde ud af, at det var dimmeren som var skruet helt ned. (Lært af bitter erfaring).    

Vi mennesker er simpelthen for dumme.. Vi glor på nogle tal og det kan være helt skævt, fordi vi mærker (føler) noget som ikke kan holdes op imod tallet. Fx den der med, at begrebet "stue temperatur" er 21 grader. Hvad nytter det, hvis
1. Termometeret viser forkert.
2. Vi synes det er for koldt/for varmt med 21 grader.

Som jeg skrev tidligere. Vi burde glemme tallene, og føle os frem. Så længe vi sikre os, at det der måles det også er målbart og justerbar, så går det kun galt, så snart vi enten er flere personer i samme rum, eller det der irriterende tal på vægge viser noget andet end det vi gerne synes det skal vise.. 

Gad at vide hvad der sker, hvis man i stedet for at justere på varmen, så kalibrerede føleren. Jeg er ret sikker på, at så vil der være en del mennesker som pludselig havde det meget bedre, selvom det i virkeligheden er det samme resultat (varme/kulden er det samme som før, men tallet viser noget andet)   

jeg giver den gas i weekenden og ser om baby dør - en dag hvor nogle af mine virkelige nørd kollegaer har tid skal vi se om vi kan få gennemskuet den firmware og lavet vores egen til den  og om ikke andet bede LK overholder deres open source forpligtelser med det software de har inkluderet

Yep, har jeg. Jeg prøvede nærmest alle kombinationer. Bla derfor kunne jeg komme ned fra de 22% til 21% 

Nå da, det var da noget rod.
jeg har valgt IHC systemet fordi det opfylder det jeg skal bruge til mit smart House. Også ville jeg hellere ikke skræmme evt køber væk i fremtiden med noget system som kune jeg kan servicere.
der bliver en del kabler ja, men synes det er tryghed for mig at have kabler ud til alle tryk og sensor. Også er kablet stadigvæk det bedste efter mit optik.

Lige en update til denne. 
Jeg har skiftet pæren som gav problemer. Og nu er problemet væk..
Pæren må altså være blevet defekt på een eller anden måde, så Hue bridge ind imellem ikke kunne få forbindelse til den, (selvom den sidder 2 meter fra en Bloom lampe og Mesh derfor burde virke).  

Jeg gør mit bedste

Hvis jeg får tid i weekenden, så skal jeg prøve at sætte det op hos mig. Har egen mailserver, så jeg ved præcis hvad der sker. 

Jeg har nu gennemført en del test og må konkludere at det er controlleren der fejler ved "Ude i hampen måling" !
Jeg har parallel koblet et input modul til 2 controllere hvor den ene (Venstre) er i normal brug og den anden (Højre) kun er konfigureret med nogle få temperature sensorer.
Temperaturen der ses kommer fra samme sensor, samme kabling og samme input modul samtidig, der burde derfor kunne ses samme fejl på begge kontrollere hvis fejlen skulle stamme fra sensor, kabling eller input modul.
Som det kan ses på billedet registres der på vestre controller 0 grader.

Velkommen tilbage Brian
 
 

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.

Værs´go!
 

Update 12.3.2019:
Binding has been merged to openHAB main repository and will available in 2.5 version. Before that, new version can be found from official openHAB snapshot builds.
Before official add-on documentation page is updated, binding documentation can found here.
 
NOTE. If you have used older beta versions of the binding, beware that there has been some breaking changes lately:
Controller address parameter is not anymore ip, but hostname "-channel" suffix is removed from channel types. E.g. switch-channel is just switch.  
###########################################################################################################################
 
Even openHAB 1 IHC binding has been rock solid for many years, I finally decided to port the binding to support openHAB 2 features.
Latest version: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.ihc/2.4.0-SNAPSHOT/
Documentation link
Some improvements / features:
By default, binding create channels automatically from project file (currently all dataline_inputs, dataline_outputs, airlink_inputs, airlink_outputs and resource_temperature). Auto creation can be disabled, and channels can be created manually (then all resource id's are supported). Support both Paper UI and thing files configuration. Channels for basic controller information (state, SW and HW version, controller uptime, etc). Trigger channels support (button short press, long press and extra long press). Support multiple controllers (those who have e.g. two controllers environment).  

 

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 

Jeg ser det som to (idiotiske) onder der møder hinanden, i en tidsalder ingen af delene hører til. 
IHC Net Basic hører efter min mening slet ikke nutiden til. Det er langt mere effektivt at lave et ordentligt net, evt ved at trække 2 kabler (og opsætte 2 stik). 
På den anden side møder man en boks, som ikke er bygget til det, som var mere eller mindre standard for et par årtier siden, men som burde være bagudkompatibel. Yousee underskylder jeg delvist, fordi 2 par kabel (eller 10/100mbit) ikke har været normen i rigtig mange år, og det er sandsynligvis ganske få som vil opleve netop dette problem, (sker kun for dem med splitterkabler).  

Mht til at bruge WiFi. Så er det også lidt noget sludder jeg siger  Du har jo alligevel kun max 100mbit til rådighed. Med et godt Wifi net, så burde du få det samme ud af det eller mere. 
Men principielt, så er jeg langt mere tilhænger af kablet forbindelser specielt når/hvis det kommer til 4K streaming, som boksen jo sagtens kan.  

Yep, virker. så er jeg på version 1.06

Min overordnet plan er ganske simpelt, at få samlet alt, så jeg kan styre det på smarte måder på kryds og tværs, samt overvågne det hele på een samlet platform.
I korte træk, så vil jeg kontrollere og vide, hvordan vores hus har det, og hvad der sker i huset. 
Udover det er vanvittigt hyggeligt at sidde og rode med, så mener jeg også det langt hen ad vejen er enormt vigtigt for vores hverdag i hjemmet. Men det er først når det virkelig virker, virker ordentligt, troværdigt, stabilt og ikke mindst sikkert, at det er vigtigt. 

Jeg er måske lidt forud for tiden, men jeg finder det grotesk og komplet idiotisk, at vi sidder i år 2018 med SÅ mange forskellige former for styringer, og kun ganske få kan se fornuften i at kunne kombinere dem på kryds og tværs. Her falder LK/Schneider i med et massivt brag, fordi de har været i gamet i så mange år, og stadigvæk ikke kan se det. Det burde klynges op til offentlig stening for at komme med deres V3 controller sidste år, uden på nogen som helst måde at have rykket sig i en åben retning.
Heldigvis går det stærkt i den rigtige retning for nærmest alle andre. 

Du nævner selv nogle funktioner, som efter min mening har ligget lige til højrebenet i årtier.
fx: Højt Co2 niveau = der skal ventilation/udluftning til.

Ideen med at Nilan anlægget styre det selv er for sin vis okay. Problemet er bare, Co2 føleren er ikke standard. Og skulle man få den ide at opgradere anlægget med en Co2, så koster det kassen, i forhold til at købe en lille simpel Co2 føler (fx en Netamo vejrstation), og bruge den Co2 føler. Men så opstår problemet. Nilan og Netamo kan ikke snakke sammen. Så i realiteten ender man ud i at købe to Co2 følere, ja måske endda flere. 
Og sådan kan man blive ved med at tilføje forskellige dimser i sit hjem, som i realiteten kan kombineres og understøtte hinandens funktioner og muligheder. Men så ramler man panden mod muren og må kæmpe med at få en helhed til at hænge sammen. 

Mht Nilan og Co2, så er min erfaring  at anlægget (vores anlæg) slet ikke er effektivt nok til at holde Co2 niveauet nede. Jeg har prøvet at sætte anlægget op i trin 4 (100%) når Netamo siger at Co2 er over 1000. Det tager for lang tid at få Co2 niveauet ned på den måde. Derfor bruger jeg det ikke. Til gengæld jagter jeg en løsning, hvor Netamo (Co2) i stedet kunne åbne vores elektriske ovenlys Velux vinduer. Det tager kun ganske få minutter at få Co2 niveauet ned på den måde. Men så er jeg tilbage i det overordnet problem med kommunikationen igen. Nilan, Velux og Netamo snakker heller ikke sammen, selvom det igen er muligheder der ligger lige til højrebenet.
 
Ser man lidt mere effektivt på det, så er Nilan ventilation slet ikke så skide smart alligevel. Problemet er, at når man fx skruer op for ventilationen, så er det i hele huset på een gang (vi har 300kvm og 12 rum/værelser). Det er ineffektivt, hvis det fx kun er i stuen, et værelse eller køkkenet som trænger til et ekstra pust frisk luft. Så når man udlufter på den måde, så skaber man også et nyt problem, varmetab eller rettere unødigt varmetab. En forholdsvis simpel løsning på dette kunne være, at lave selvstændig styret ventiler/spjæld eller lign. Men det betyder nytænkning i forhold til det traditionelle. Så også her må man anfægte Nilan (og andre mærker) for ikke at tænke effektivt og smart nok.
Og hvis man så går all-in, så laver man styringen så den netop kan snakke sammen med andre systemer. Så fx en Co2 føler i hvert rum/værelse evt i kombination med en temperaturføler, kan aktivere en ventilation/vindue eller andet, når det er nødvendigt. Det er ikke raketvidenskab. Men som det er nu, så er bedste løsning, at få Co2 føleren til at aktivere en push besked, en lampe, en ringetone eller lign, så en beboer kan begive sig til vinduet og åbne det manuelt, eller skrue op for det i forvejen ineffektive ventilations anlæg. Altså, præcis sådan som Netamo er skruet sammen i dag. Det er gabende idiotisk, selvom man nok kunne finde på flere gode grunde til, at det har visse fordele. Fx at man ikke risikere at gro fast i sofaen osv..

Min foreløbige plan på Co2/udluftning bliver: 
At få Openhab2, Netamo/anden form for individuel Co2 føler og Velux til at snakke sammen. Så styres vinduerne i de rum, hvor det er nødvendigt. Det lyder simpelt, men Velux/IO vil ikke helt lege med endnu, så det er mit næste lille bump på rejsen. Udover det skal IHC controlleren og mit Ubuiquiti netværk også blandes ind i det, så jeg har styr på at vinduerne ikke åbner, når der ikke er nogen hjemme. IHC styrer alarmen, så når den er tilkoblet, så er det no-go for vinduerne. Ubiquiti kan se hvem der er hjemme. Ikke en 100% skudsikker løsning, men i forbindelse med PIR´s i flere rum, Alarmen til/frakoblet, så er det en smal sag for OpenHab at regne ud, om der er nogen hjemme. 
Nilan anlægget kommer ind i billedet de dage hvor det ikke er skide smart at åbne vinduerne pga vejret,  og/eller behovet for udluftning opstår, når der ikke er nogen hjemme. Fx til at køle ned. 

Min største udfordring med lige dette punkt pt - Tiden (den værste årsag), Velux, vind og vejr.
En Velux KLF 200 skulle efter sigende kunne forbindes OpenHab2. Men selvom vinduerne har regnsensor, så er denne melding ikke tilgængelig via KLF 200, siges der. Derfor skal jeg finde en anden form for regn, vind og vejr sensor, som virker på samme måde. Netamo har regn og vind, og jeg overvejer om det skal være løsningen. Men det skal være en klippe stabil løsning. Og så skal jeg have koblet regnsensorene fra i Velux vinduerne.. Det er vistnok lidt tricky.
Det havde ellers været smart, (logisk) hvis man kunne hente meldingen om "regn" fra vinduerne via KLF 200 interfacet, og så lade Nilan ventilation overtage, hvis det fx regner for meget til at vinduerne vil åbne. Så Velux skal åbenbart også anfægtes for at ikke bruge nytænkning, ligesom LK/Schneider, ligesom Nilan (oa mærker), ligesom.... man kan jo blive ved 

Nu kender jeg ikke VP-18. Men formoder det er Nilan VP-18 du mener.. 

Jeg har selv for nyligt tilsluttet vores Nilan comfort 300LR til min Rpi, som kører OpenHab. Jeg ved ikke om VP-18 kører modbus (RS485) ligesom Comfort300 gør. 
Hvis den gør det, så er der her en tråd som fik hjulpet mig igang. 
https://community.openhab.org/t/openhab1-2-nilan-heatpump/23538/1
1. punkt er at få forbundet Nilan anlægget med Rpién. Hvis Vp-18 er ligesom Comfort300 med CTS 602 interface, så skal du bruge en USB -> RS485 dongle. Den koster ca. 3-400,- fra England. 
2. På VP-18 skal du finde modbus interfacet. Igen jeg ved ikke om det er ligesom Comfort 300. Men på vores anlæg, der sidder modbus interfacet på ydresiden af anlægget.
Se billede her:

Det nederste kabel er det som går til panelet. Det skal du ikke tænke så meget over. Men begge skal være der. I ovenstående bruger jeg: Gul=A1, brun=B1 og blå=GND.

I RPIén har jeg sat min RS485 dongle: Se dette billede:

Derfra er det egentlig bare at få Rpi med Openhab2 op og køre. Men det er en forholdsvis stort bearbejde der skal laves med at oprette items. Så du skal kende modbus adresser til anlægget, eller satse på det er kompatible med comfort anlægget. Hvis VP-18 har CTS 602 interface, så vil jeg tro at det er det samme som vores anlæg. I tråden jeg linker til, der har den oprindelige skribent et andet Nilan anlæg (med varme), men det er stadigvæk CTS 602 interface, og derfor virker de fleste modbus adresser også til mit comfort300, som også har CTS 602 interface. 

Håber ikke det blev alt for indviklet.

Nu kender jeg ikke VP-18. Men formoder det er Nilan VP-18 du mener.. 

Jeg har selv for nyligt tilsluttet vores Nilan comfort 300LR til min Rpi, som kører OpenHab. Jeg ved ikke om VP-18 kører modbus (RS485) ligesom Comfort300 gør. 
Hvis den gør det, så er der her en tråd som fik hjulpet mig igang. 
https://community.openhab.org/t/openhab1-2-nilan-heatpump/23538/1
1. punkt er at få forbundet Nilan anlægget med Rpién. Hvis Vp-18 er ligesom Comfort300 med CTS 602 interface, så skal du bruge en USB -> RS485 dongle. Den koster ca. 3-400,- fra England. 
2. På VP-18 skal du finde modbus interfacet. Igen jeg ved ikke om det er ligesom Comfort 300. Men på vores anlæg, der sidder modbus interfacet på ydresiden af anlægget.
Se billede her:

Det nederste kabel er det som går til panelet. Det skal du ikke tænke så meget over. Men begge skal være der. I ovenstående bruger jeg: Gul=A1, brun=B1 og blå=GND.

I RPIén har jeg sat min RS485 dongle: Se dette billede:

Derfra er det egentlig bare at få Rpi med Openhab2 op og køre. Men det er en forholdsvis stort bearbejde der skal laves med at oprette items. Så du skal kende modbus adresser til anlægget, eller satse på det er kompatible med comfort anlægget. Hvis VP-18 har CTS 602 interface, så vil jeg tro at det er det samme som vores anlæg. I tråden jeg linker til, der har den oprindelige skribent et andet Nilan anlæg (med varme), men det er stadigvæk CTS 602 interface, og derfor virker de fleste modbus adresser også til mit comfort300, som også har CTS 602 interface. 

Håber ikke det blev alt for indviklet.

IHC captain laver et samspil mellem din IHC installation og HUE lamperne, via HUE bridgen. Så du skal altså ikke starte IHC Captain hvergang du skal tænde/slukke lyset.

Det du har læst et sted om at tænde på Hue app og så IHC Captain tænder på fuld styrke, det kan ikke helt passe, medmindre det er et scenarie som man bevidst har valgt skal være på fuld styrke i HUE appen. For det er netop det IHC Captain gør, den operere på scenarier og/eller enkeltvis på pærene. Det bestemmer man selv. 

Ideen med IHC captain er fantastisk smart. Men du skal se den som en erstatning for netop HUE appen i forbindelse med kontrollen af lyset fx, som hvis du bruger HUE appen (eller HUE switchen/kontakten) i dag til at tænde/slukke/justere lyset med. Så kan du gøre det med IHC Captain via IHC tryk i stedet.

Der er dog et lille men.. 

IHC Captain er ikke helt færdig udviklet i dag. Den fungere og kan bruges, men den mangler lige lidt optimering, synes jeg.
Bla har jeg lidt udfordringer med at tænde/slukke flere lamper i samme rum/gruppe. Vi har 4 HUE lamper i vores stue, som alle køre helt ens (3 stk Bloom og en color pære). Det sker ind imellem at når jeg tænder eller slukker via IHC tryk, så kan 2 eller 3 slukke, mens den 4. forbliver tændt.. Og så er det lidt en kunst at få dem "synkroniseret" igen. 
Og det er meget underligt at det sker, for det sker aldrig via HUE appen. Og principielt er det det samme der sker. 

Derudover er det lidt udfordrende at skrue op/ned for lyset via et IHC tryk. Det er helt klart et spørgsmål om timing, for selve funktionen virker som den skal. Men jeg oplever ind imellem, at selvom jeg har fx har sluppet trykket, så dæmper/ændre den sig alligevel efterfølgende et kort sekund.

En ting som jeg har bemærket i begge tilfælde, det er tiden hvor længe/kort man aktivere IHC trykket. Jeg kan som oftest fremprovokere den første fejl. Fx ved meget meget kort at trykke på IHC trykket. Det vil få nogle af lamperne til at reagere, mens nogen ikke gør. 
Og det er præcis det samme problem, når det drejer sig om dæmpning. Endnu værre er det, hvis det er et IHC tryk som hænger lidt (slidt eller blevet lidt træg), så er dæmpningen udfordret i stor stil.  
  
Afhængig af hvor meget tid Mikkel har, så er jeg ret sikker på, at det nok skal blive rigtig godt en dag. Jeg har et mindre hængeparti med ham om noget HUE udstyr han skal have fra mig. Men jeg er sikker på, at når jeg får det sendt, så har han sikkert løst det i løbet af ganske kort tid. 

Umiddelbart mangler jeg et stop signal til frekvensomformeren.
Desuden ville jeg ikke turde lade noget som helst køre op/ned bare ved et langt tryk, meget kan ske mens den f.eks. kører ned. Barnet taber noget og stikker hånden ned efter det.
Jeg ville lave det sådan at et vedvarende tryk sender vinen op eller ned, slippes trykket stoppes motoren.

Nu for jeg har været rimelig optaget med andet, Mikkel har haft ferie osv osv.. 
Men regner med vi måske kan finde tid i løbet af ugen.