Kandersen

Schneider og LK er typiske eksempler på gamle hæderkronede virksomheder med hele deres arv og udvikling fokuseret på produkter, og disse virksomheder har oftest sværest ved at agere med digitale services - og det bliver bestemt ikke bedre af at man kommer fra Frankrig, hvor digitaliseringen vel er ca 10 år efter Norden, US og visse lande i Asien.
IHC er et klassisk eksempel på hvor galt det kan gå, når en virksomhed forsøger sig med "servicetization" uden at have det fornødne setup og kommer med en gennemsyret inside-out tilgang. De mangler forståelse, kompetencer og fokus, og ender altid med at blive disrupted af nye spillere som har det som Jeff Bezos kalder "customer obsession"

Yep det er via rules i openhab. 
Nu siger du at dine velux-vinduer kører via en KLF200. Det gør min vinduer også. Men der er forskellige måder at styre dem på. MED KLF200 firmware 2.xx så kan du styre vinduerne i 1-100%. Ellers kan du bruge scener som er oprettet i KLF200. Velux bindingen til openhab skulle gerne have fundet både vinduer og scener. 

Derefter er det sådan set en forholdsvis smal sag at få noget til at gøre noget andet ved påvirkning. 
fx.. 
 
rule "simple princip regel" When     item sensor changed then     velux.sendCommand(ON)  end Denne simple regel (rule) gør sådan set det som den siger:

Når sensor  ændre sig, 
 så
Send kommando ON til velux. 
Sensor er så en item fra et eller andet
Velux er en item linket til et velux vindue eller en scene på din KLF200. 

Her er min gamle (en del mere omstændig/avanceret) rule til styring af mine velux vinduer, der bla tager forbehold for, om alarmen er slået til/fra, og om det er mørkt udenfor. Og så selvfølgelig temperaturen i form af en Netamo sensor. Det skal lige siges, at den er ændret lidt i dag. Men princippet er det samme. Den aktivere scener i KLF200.
rule "Automatic control of all skylight windows" when Item NetamoUdendoersTemperature changed or Item Node13_SensorLuminance changed or Item alarm_totalalarm changed or Item dummy1 changed then // Exit the rule when there is nothing to do if(Override.state == ON) return; if(alarm_totalalarm.state instanceof Switch ) return; if(!(Node13_SensorLuminance.state instanceof Number)) return; if(!(NetamoUdendoersTemperature.state instanceof Number)) return; // Calculate which velux to send the ON command to val Number fTemp = NetamoUdendoersTemperature.state as Number val Number lux = Node13_SensorLuminance.state as Number val alarm = alarm_totalalarm.state var velux = VeluxAlleLuk // Third table if(alarm == ON) { logInfo("debug", "Third table clause") velux = if(fTemp >= 18|"°C") VeluxAlleVent else VeluxAlleLuk } // Second table, we already know alarm isn't ON so we don't have to test it for OFF here else if(lux < 10){ logInfo("debug", "Second table clause") velux = if(fTemp >= 18|"°C") VeluxAlleVent else VeluxAlleLuk } // First table, we know that alarm isn't ON and we know lux >= 20 so we don't have to test for it here else { logInfo("debug", "First table clause") switch fTemp { case fTemp >= 25|"°C": velux = VeluxAlleAaben100 case fTemp >= 24|"°C": velux = VeluxAlleAaben75 case fTemp >= 23|"°C": velux = VeluxAlleAaben50 case fTemp >= 18|"°C": velux = VeluxAlleVent default: velux = VeluxAlleLuk } logInfo("debug", "Choose " + velux.name) } // Send the command logInfo("skylight", "Sending ON command to " + velux.name + " because OutsideTemp = " + NetamoUdendoersTemperature.state + " Lux = " + Node13_SensorLuminance.state + " and Alarm = " + alarm_totalalarm.state) velux.sendCommand(ON) end
 

Ja, fjern Lille_bad_mode. Det fungere ikke med den type thermostater vi bruger. 

Her er opsætningen som jeg bruger. Den virker i Google Home appén. Den virker med Google Assistant (dvs du kan spørge Google om temperaturen, og via stemme indstille setpunkt).
Men den virker IKKE med Google Nest Hub (Home hub - den med skærmen). Og pt kan ingen fortælle mig hvorfor eller hvor problemet ligger. 
 
Group g_Stortbad_TSTAT "Stort Bad Thermostat" [ "Thermostat" ] Number stort_bad_Temperature "Stort Bad Temperatur [%.1f °C]" <cu_heating> (g_Stortbad_TSTAT,Temperatur,gTvaer,gSugeTemp) [ "CurrentTemperature" ] { channel="ihc:controller:elko:stortbad_temperatur_fb" } Number stort_bad_Tempsetpunkt "Stort Bad Temperature setpunkt [%.1f °C]" <temperature> (g_Stortbad_TSTAT) [ "TargetTemperature" ] { channel="ihc:controller:elko:stortbad_temperaturSet_fb", autoupdate="false" } Switch telestat1_stort_bad "Stort Bad Telestat [%s]" <cu_switch> (g_Stortbad_TSTAT,gTelestat) { channel="ihc:controller:elko:stortbad_telestat" } Number stort_bad_fugt "Stort Bad Fugtighed [%.0f %%]" <Humidity> (g_Stortbad_TSTAT,Fugtighed,gHumidityBathRoom) [ "CurrentHumidity" ] { channel="ihc:controller:elko:stortbad_fugtighed" }  

De fleste har nok haft en der stod af og fået / købt en ny.
Savner en forklaring fra LK-de burde være lidt ydmyge set i min optik.
Rigtig godt initiativ med det skema.

I forgårs satte jeg mig for at teste den nyeste IHC binding. Jeg har flere gange ville gøre det, men haft dilemmaer der holdt mig tilbage fra at teste den ordentligt på mit oprindelige setup. Så i forgårs gik jeg en lidt anden vej, da jeg alligevel er småt i gang med en anden og dybere detaljerede guide om openhab2 med IHC og "lidt" ekstra. 

Her er en lille hurtig 10-punkt guide, som ikke går fuldstændig i de mindste detaljer. Den er tiltænkt at give et lille overblik over det grundlæggende forløb i installering af openhab2 på en Rpi 3B+ med seneste IHC binding og autochannels:

1. Jeg tog en RaspberryPi 3B+ (forkortet, Rpi herefter) og et 16GB SD kort. 
2. Hentede den seneste stable version af openhab2 til Rpi. (Image fil) 
3. På min windows maskine brugte jeg win32image til at kopiere image filen til SD kortet. (kræver man har en SD kortlæser i sin windows maskine).
4. Isatte det færdig kopierede SD kort i Rpién, tilsluttede ethernet (netværk) stik og tændte for Rpién, så den automatisk kunne installere openhabian inkl openhab2 2.3 stable. (Det tager ca. 25-30 min på en Rpi 3B+). Jeg satte også en skærm til Rpién via HDMI, så jeg kunne følge med i hvad der skete. Men det er ikke nødvendigt, ligesom tastatur/mus heller ikke er nødvendig. 
5. Da openhabian (openhab2) var færdig med at opdatere/installere, så åbnede jeg et browser vindue på min windows maskine og skrev adressen: http://openhabianpi:8080 som leder til GUI  interface/skærm af openhab2. Dette er den nu kørende openhab2.  
6. Klikkede på PaperUI, og under menu punktet Configuration/System gik jeg punkterne igennem og rettede det grundlæggende til. <--- sprog, landekode osv.  
7. Derefter hentede jeg seneste version af IHC bindingen (.JAR fil). 
8. Brugte Winscape SSH program på min windows maskine, skrev IP nummer til Rpién, samt brugernavn/pw [openhabian/openhabian], hvorefter kan logge ind og se folder strukturen på Rpi. Her finder man addons folderen og kopiere .JAR filen (IHC bindingen) ind i den. Openhab2 opdager automatisk .JAR filen og starter automatisk IHC bindingen herefter.  
9. Dernæst konfigurerede en tekst fil i /etc/openhab2/things folderen. .things filen (text fil) er konfiguration af IHC controlleren. I den fil skriver man IP nummeret til IHC controlleren, brugernavn/pw og jeg satte den til at lave channels automatisk. (Automatisk channels er den nemme men også begrænsede løsning, der kan bruges). Derud over er der mulighed for manuelt at oprette channels i filen, men da jeg ville teste bindingens automatiske channels søgning, så satte jeg ingen ekstra channels på. 
10. Tilbage i PaperUI under menuen Configuration/Things kan jeg nu se IHC controlleren var installerede og Online. Ved klik på den fremkom en hulens masse channels, som passer til alle de produkter som ligger på IHC controlleren.

Sådan! - Så er man klar til det som det virkelig gælder om - OpenHab2 og hvordan man laver links, items samt sitemap filer, evt andre bindinger eller kommunikation til andet udstyr end IHC controlleren.

Men..
Det er herfra det bliver stejlt og til tider møg forvirrende og besværligt, ikke mindst hvis man ikke er vant til Linux "sprog", SSH og terminal program ala Putty. 
Jeg hader Linux og forbander det stadigvæk langt væk den dag i dag. Men hvis man holder fokus og tager et skridt ad gangen (et mål ad gangen), så er det så nemt så min påstand er, at langt de fleste kan få openhab2 og IHC bindingen op og køre uden store problemer eller krav om en længervarende akademisk uddannelse, specielt fordi den nyeste binding selv kan lave channels. 

I alt brugte jeg lige under 1 time, så havde jeg en færdig køreklar openhab2 med seneste IHC binding. Og i øvrigt inkl 4 manuelt oprettede items, een sitemap fil, og en opdateringen af openhab2 til seneste snapshot version 2.4 (M6), som ikke er beskrevet i forløbet herover. Det meste tiden gik med at vente på SD kortet var formateret og kopierede færdig, og derefter at openhabian installation blev færdig. 
Min viden er ikke den bedste målestok for, hvor nemt det her er eller hvor lang tid det tager, da jeg efterhånden har rimelig godt kendskab til det, selvom det faktisk kun er 3. gang jeg installere openhab2 fra grunden, (første gang var på en windows maskine, 2. gang på min nuværende Rpi og 3. gang var så i forgårs). Men min pointe er, at det er faktisk ikke så svært at nå hertil dette punkt, tværtimod.

Min påstand er, at langt de fleste kan gøre det. Det kræver en lyst og en vilje til at ville lære det. Lidt ala at tage et kørekort. Når man har fundet ud af det grundlæggende, så er det faktisk uhyre nemt. Men af det afhænger dog af, hvad det er man vil. Personligt har jeg selv gabt over rigtig meget med openhab (og IHC for den sags skyld). Og jeg har fået massive "øretæver" og sandsynligvis også blevet en del mere gråhåret. Og jeg har stadigvæk langt igen, hvis jeg skal nå alt 

IHC Captain er på mange måder et færdigt produkt, som kan det som det kan, og thats it, (selvom det faktisk også kan en hel del, hvis man er lidt viden om http/json osv). Men så er man netop igen ovre i, at man skal lære noget først. Som en egentlig UI til IHC installationen, der er den uden tvivl uhyre effektiv og simpel, så alle kan være med. Og det er utrolig godt at Mikkel laver det, fordi det på mange måder betyder, at IHC brugere ikke pine død er tvunget til at købe LK´s vanvittig dyre app, for noget så simpelt. 

De har læst på lektien:
First rule of support

@Kandersen, from here you can find first test version for configurable ON level. It should work with dimmer channels and you need to add onLevel channel parameter (e.g. onLevel=70). I don't have IHC dimmers so I didn't test it well.

Jeg er så småt i gang med at lave det.....
...netop med fokus på stemmestyring via Google Home og Openhab2, fordi det fungere sindsygt godt. 

Problemet med guiden er at lave den sidste del, (openhab cloud og Google home), da jeg helst vil bruge en helt nye opsætninger og dermed nye enheder/brugernavne/pw. Da min egen opsætning er ret omstændig, og en video guide helst skulle afspejle en komplet ny opsætning. 
 
Så lige pt overvejer jeg at lave det i flere afsnit, og så få fat i noget nyt udstyr.   

Således opløftet fik jeg overbevist Apple Support om, at de skulle "give" mig app'en igen. :-). Tak for svar, Bjarne og Kandersen.

Hmm, chicken..  
Hvad skete der lige med.. "If it aint broken, go push it to its limits!" 

Ikke nogen som ikke er trådløs. 

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 

Stop...
Åbnet porte bør under ingen omstændigheder være nødvendigt, når du prøver at tilgå din IHC controller fra en computer som er tilsluttet det lokale net.

Hvilket udstyr har du? (router, switch, access point oa.).  

Jeg roder med det i disse dage. Det sværeste er at det kræver at det skal ud på nettet og jeg vil være helt sikker på sikkerheden er på plads. Når det er på plads åbner det så også for mange mange flere ting.
Men jeg har ikke et godt bud på hvornår det er klar. Skal også have købt noget hosting etc.

Jeg skal lige tænke.. For jeg har faktisk også en rule kørende på min "hoved"-Rpi.. Men der bruger jeg ikke den nyeste IHC binding. 

Min rule ser således ud:

rule "PushButton of group gV"
when
    Member of gV changed to ON
then
    createTimer(now.plusMillis(300), [ | triggeringItem.sendCommand(OFF) ])
end
Og alle tryk er i en (gV) gruppe. 

Jeg kan ikke se lige hvad jeg har gjort i den nye IHC binding, mest af alt fordi jeg ikke rigtig bruger switches der endnu. 

I looked at rules aswell, but for my purpose it feels like overkill when I do not want any ekstra functionallty besides updating values.
 
Btw. everything works as expected now, even my OpenWeatherMap to IHC communication - and of course back to Homekit for iphone control of everything.

Så har du også nedsat levetiden på den 

Jeg ville os have google assistent koblet på og det er nu lykkes igennem en del sparring og en rigtig god vedhæftet vejledning i tråden hvor følgende link går til...
Hilsen Anders

Hue tryk har også virket rigtig godt her de sidste par dage (opdaterede en times tid efter du havde annonceret 1.25). 

Fik opdateret i går. Umiddelbart ingen problemer. Men jeg genstartede også Rpién. 

openHAB2 - IHC & Google Home integration
Det er nu efterhånden blevet til 14 beskeder siden jeg med stor interesse læst din vejledning – KANDERSEN - fra den 27 november om installation af IHC binding/OpenHab2. Det gav mig input til at starte et projekt med udskiftning af min gamle IHC controller version 1 til den nye controller version3, men jeg ville samtidig gerne have Google Home med i integrationen dvs. openHAB/IHC/Google Home. For at det kunne blive muligt var der en del nye ting at sætte sig ind i. Når man læser indlæg her i dette forum er det indlysende at mange har et indgående kendskab til programmering, hvilket jeg ikke har ….. jeg er en nogenlunde velfungerende pensionist på snart 70 og programmering var ikke på skemaet da jeg gik i skole.
Vejen frem for projektet var Google og dette forum. Målet er nået ==> openHAB/IHC/Google Home snakker nu sammen og under rejsens gang har jeg lavet en del screendumps som jeg har samlet i en manual således at jeg ud fra denne billedbog kan reproducere hvad jeg har lavet … hvis jeg skulle glemme det :-)
Jeg har vedhæft manualen og jeg har testet fremgangsmåden på en RPI3 og en RPI Zero w, sidstnævnte er lidt for sløv til dette projekt og det bliver heller ikke bedre af at den kun kan køre WiFi – RPI3 med LAN køre super.
Næste fase af projektet er programmeringen IHC controlleren, men det er et mindre problem – jeg programmerede selv den gamle controller for 15 år siden da jeg bygge sommerhuset og selv om programmeringen har ændret sig lidt, tror jeg dette projekt bliver lidt lettere for mig end integrationen af openHAB/IHC/Google Home.
God jul til alle
Manual openHAB2 - IHC & Google Home installation .pdf

Hej Henning. 
Du kan ikke sættes tags via PaperUI. Enten skal du lave items manuelt, eller så skal du bruge REST APIén til at sætte tags.
Jeg anbefaler, netop af samme årsag, at man bruger items filer. Det er lidt mere besværligt at komme i gang med, men når først man har "set lyset" så giver det så meget mere fleksibilitet, så man ser sig aldrig tilbage igen. 

Nu ved jeg ikke hvilken computer du har openhab kørende på. Er det en windows, så kig i c:/openhab/. Der skulle gerne ligge en en etc/openhab2/ folder. I den kan du bla se /items/ folderen. 

Hvis det er en Rpi du bruger, så laver du en ssh forbindelse til din openhab. Eller du skal opsættes shares, så du kan se de foldere du skal bruge fx fx en windows maskine (i stifinderen).
koekken.items 
Jeg bruger ssh løsningen. Og programmet jeg bruger (til windows) det hedder WinScp. Med det program kan du logge ind på din openhab ved at angive IP adresse, brugernavn=openhabian, samt password=openhabian. (<-- forudsætter du ikke har skiftet det). 
Så kan du se folder strukturen i WinScp. Den folder du skal have fat i hedder /etc/openhab2/. Deri vil du bla. finde /items/ folderen. 

en items fil er en ganske almindelig tekst file, som du selv navngiver. den skal bare hedde .items fil "efternavn"/extention
Den kan fx se sådan her ud: (se vdhæftet fil)


Dette er til et af værelserne hos os.. Hvis vi kigger på een af linierne, som har et Google Home tag:
Dimmer       koekken_vasklys_niv         "Køkken Dimmer niveau vask [%.1f %%]"                    <light>                 ["Lighting"]            { ihc="13957725" }

Så er det første:
Dimmer = med typen på channel, som du kan se i PaperUI (og den nyeste IHC binding).
koekken_vasklys_niv = Dette er items navnet. Det er unikt og aldrig to items må hedde det samme. 
"Køkken Dimmer niveau vask [%.1f %%]" = Det er label. Den bruges mest til at beskrive hvad items er linket til, og det der [%.1f %%] Det er for at man kan se niveaet i fx sitemap. 
<light>  = ikonet som vises i sitemap
["Lighting"]  = Google Home tag, som fortæller Google home at der er tale om en lys enhed
{ ihc="13957725" } = IHC Recource ID.. (Bemærk, det er til en gamle IHC binding. Jeg har ikke lige adgang til min test opsætning med den nye binding hvor jeg sidder nu). Det er det tal som peger direkte på resource ID i IHC controller programmet. Det er i det her tilfælde Niveau på en IHC Ø80 lampeudtag dimmer.

Sværere er det egentlig ikke. 

Når du har gjort dette, så skal du huske at synkronisere dine enheder i Google Home. Det gøres nemmest, hvis du har en google home enhed, ved at tale til den, og sige, "Hey google, synkronisere mine enheder". Hvis det går godt, så skulle du gerne kunne se et lys/pære ikon i Google Home app´en (i bunden af forsiden), hvor der står "køkken Dimmer niveau vask" eller hvad du end har skrevet i din label. 
Her er et tip.. glem dine labels i Google Home appén, og gå manuelt ind i Google Home appén og giv den et andet navn, som fremover er det du skal sige til Googe Home, for at styre det med stemmen. Det er betydelig nemmere og virker klippe stabilt på den måde. I mit tilfælde har jeg valgt at kalde dem "de to lamper ved køkkenvasken" i Google Home appén. Det betyder, at når jeg skal tænde/slukke dem, så siger jeg, "Hey Google, tænd de to lamper ved køkkenvasken". Det er bevidst valgt ud fra, at det var det jeg ville sige, hvis jeg bad en person om at tænde lyset.  Plus at det også gjorde, at jeg ikke skulle til at lave alle mine labels om i OpenHab, da jeg begyndte at bruge Google Home.
Hvis du allerede kan overskue det nu, så kan du sagtens bruge labels fra items i openhab. 

Så skulle du gerne være flyvende.. 

Der skal nok komme en mere detaljeret forklaring på et tidspunkt inkl screendumps osv. Har også overvejet en lille youtube film. Sidstnævnt kræver dog lige at jeg sætter mig ind i, hvordan man får vist sin skærm ordenligt på den måde andre gør.. Jeg aner nada om sådan noget. 
Men pt er jeg en del hængt op med arbejde og ikke mindst min egen installation, fordi jeg (endnu engang) ikke kunne dy mig og opdaterede min ellers klippe stabile openhab 2.3 til den nye Milestone release i forgårs. Det gav selvfølgelig et hav af problemer, som jeg pt døjer med.. Mangler dog kun at få modbus (Nilan ventilationsanlægget) op og køre igen. Men det er en tricky sag for en som mig, der aner nada om modbus, fordi alt er vendt op og ned i den nyeste openhab/modbus binding. Om alt går vel, så håber jeg lige i starten af det nye år, at have en forhåbentlig god guide parat. 

Hej Henning. 
Du kan ikke sættes tags via PaperUI. Enten skal du lave items manuelt, eller så skal du bruge REST APIén til at sætte tags.
Jeg anbefaler, netop af samme årsag, at man bruger items filer. Det er lidt mere besværligt at komme i gang med, men når først man har "set lyset" så giver det så meget mere fleksibilitet, så man ser sig aldrig tilbage igen. 

Nu ved jeg ikke hvilken computer du har openhab kørende på. Er det en windows, så kig i c:/openhab/. Der skulle gerne ligge en en etc/openhab2/ folder. I den kan du bla se /items/ folderen. 

Hvis det er en Rpi du bruger, så laver du en ssh forbindelse til din openhab. Eller du skal opsættes shares, så du kan se de foldere du skal bruge fx fx en windows maskine (i stifinderen).
koekken.items 
Jeg bruger ssh løsningen. Og programmet jeg bruger (til windows) det hedder WinScp. Med det program kan du logge ind på din openhab ved at angive IP adresse, brugernavn=openhabian, samt password=openhabian. (<-- forudsætter du ikke har skiftet det). 
Så kan du se folder strukturen i WinScp. Den folder du skal have fat i hedder /etc/openhab2/. Deri vil du bla. finde /items/ folderen. 

en items fil er en ganske almindelig tekst file, som du selv navngiver. den skal bare hedde .items fil "efternavn"/extention
Den kan fx se sådan her ud: (se vdhæftet fil)


Dette er til et af værelserne hos os.. Hvis vi kigger på een af linierne, som har et Google Home tag:
Dimmer       koekken_vasklys_niv         "Køkken Dimmer niveau vask [%.1f %%]"                    <light>                 ["Lighting"]            { ihc="13957725" }

Så er det første:
Dimmer = med typen på channel, som du kan se i PaperUI (og den nyeste IHC binding).
koekken_vasklys_niv = Dette er items navnet. Det er unikt og aldrig to items må hedde det samme. 
"Køkken Dimmer niveau vask [%.1f %%]" = Det er label. Den bruges mest til at beskrive hvad items er linket til, og det der [%.1f %%] Det er for at man kan se niveaet i fx sitemap. 
<light>  = ikonet som vises i sitemap
["Lighting"]  = Google Home tag, som fortæller Google home at der er tale om en lys enhed
{ ihc="13957725" } = IHC Recource ID.. (Bemærk, det er til en gamle IHC binding. Jeg har ikke lige adgang til min test opsætning med den nye binding hvor jeg sidder nu). Det er det tal som peger direkte på resource ID i IHC controller programmet. Det er i det her tilfælde Niveau på en IHC Ø80 lampeudtag dimmer.

Sværere er det egentlig ikke. 

Når du har gjort dette, så skal du huske at synkronisere dine enheder i Google Home. Det gøres nemmest, hvis du har en google home enhed, ved at tale til den, og sige, "Hey google, synkronisere mine enheder". Hvis det går godt, så skulle du gerne kunne se et lys/pære ikon i Google Home app´en (i bunden af forsiden), hvor der står "køkken Dimmer niveau vask" eller hvad du end har skrevet i din label. 
Her er et tip.. glem dine labels i Google Home appén, og gå manuelt ind i Google Home appén og giv den et andet navn, som fremover er det du skal sige til Googe Home, for at styre det med stemmen. Det er betydelig nemmere og virker klippe stabilt på den måde. I mit tilfælde har jeg valgt at kalde dem "de to lamper ved køkkenvasken" i Google Home appén. Det betyder, at når jeg skal tænde/slukke dem, så siger jeg, "Hey Google, tænd de to lamper ved køkkenvasken". Det er bevidst valgt ud fra, at det var det jeg ville sige, hvis jeg bad en person om at tænde lyset.  Plus at det også gjorde, at jeg ikke skulle til at lave alle mine labels om i OpenHab, da jeg begyndte at bruge Google Home.
Hvis du allerede kan overskue det nu, så kan du sagtens bruge labels fra items i openhab. 

Så skulle du gerne være flyvende.. 

Der skal nok komme en mere detaljeret forklaring på et tidspunkt inkl screendumps osv. Har også overvejet en lille youtube film. Sidstnævnt kræver dog lige at jeg sætter mig ind i, hvordan man får vist sin skærm ordenligt på den måde andre gør.. Jeg aner nada om sådan noget. 
Men pt er jeg en del hængt op med arbejde og ikke mindst min egen installation, fordi jeg (endnu engang) ikke kunne dy mig og opdaterede min ellers klippe stabile openhab 2.3 til den nye Milestone release i forgårs. Det gav selvfølgelig et hav af problemer, som jeg pt døjer med.. Mangler dog kun at få modbus (Nilan ventilationsanlægget) op og køre igen. Men det er en tricky sag for en som mig, der aner nada om modbus, fordi alt er vendt op og ned i den nyeste openhab/modbus binding. Om alt går vel, så håber jeg lige i starten af det nye år, at have en forhåbentlig god guide parat. 

Ny version af IHC Dokumentation værktøjet: http://jemi.dk/ihc/docs   - Nu med "link" visning - Funktionsoversigt visning   Test gerne