Kandersen

Bahhhh 

Såå gutter :) 
Tak for jeres svar! 
Firmwareloader 1.3.3 og firmware 2.8.6 blev uploadet med succes. 
Nu virker IHC REMOTE! 
Tusinde tak for jeres hjælp :) 
Det fedt :) 

God guide Ejvind. Men du bør lægge items og sitemap eksemplerne ind i en formatteret boks (tryk på <> i editor menuen når du skriver et indlæg). Det gør det langt mere læseligt..
 
Den skal ikke i samme folder som .things. Items skal i items folderen 

EDIT 25. januar 2021: Nedenstående er baseret på Openhab version 2. I Openhab version 3 er menuen anderledes, og paperUI er erstattet af anden funktionalitet.
 
Hermed et indlæg om Best Practice for openHAB binding version 2 som opfølgning på mit tidligere indlæg - se link her Først en stor tak til @Pauli Anttila for denne IHC Binding til openHAB ver 2.
Dette indlæg er ikke ment som den nemmeste måde at komme i gang med openHAB 2 på. Tværtimod kan det virke lidt besværligt, men det giver mig mulighed for at styre min installation helt præcis til mindste detalje samt en nem måde at reetablere opsætningen i tilfælde af fejl.
Som hardware kan man med fordel bruges enten Raspberry PI, Synology NAS eller Ubunto installeret på en PC. Gennem årene har jeg benyttet alle 3 varianter, og jeg er nu endt med Ubunto installeret på en ældre laptop med en driftssikker SSD disk. Det vil være nødvendigt at lære lidt om Linux, hvis man ikke kender det. Men det er god viden at tilegne sig....
På det valgte hardware installeres Oracle Java version 8 og dernæst følg installation af openHABian. Se link
I openHAB kan man bl.a. have disse integrationer, og jeg fokuserer her på dem, som er mærket med rød boks.
Efter installationen skal man angive ønskede integrationer - såkaldte bindings - og det gøres via paperUI, som default kan findes på http://lokalIPadresse:8080
Her vælges IHC Binding, som installeres - se skærmkopi:

Nu kan man benytte funktionalitet i paperUI til automatisk at identificere input- og outputs i sin IHC installation, men jeg bruger ikke dette. I stedet angiver jeg alt i filer, fordi det - i det lange løb - er det nemmeste at arbejde med. Filerne skal lagres i /etc/openhab2/conf/things/ folderen - dog ikke Synology, som bruger andre foldere.
Things
Først angives såkaldte Things, som er en forbindelse til fysiske ting - i dette tilfælde IHC Controller med forbundne enheder.
Herunder ses eksempel på en ihc.things fil:

Benyt ikke Notepad i Windows til editering, men brug i stedet Visual Studio Code, som er gratis og med sikkerhed uden virus. Windows Notepad laver nogle karakterer i filen, som ikke fungerer i Linux.
Bemærk "createChannelsAutomatically=false", hvilket gør, at bindingen ikke selv finder input og output. Læs mere her
Hvis direction ikke er udfyldt, kan den pågældende enhed - fx en stikkontakt - både ændres og aflæses af openHAB, hvis den ændres af svagstrømstryk. Dvs. en statusændring kan sendes fra openHAB til IHC og omvendt.
resourceID er entydig decimal værdi fra Visual, og man kan se den ved at holde Ctrl knappen nede, mens musen køres henover fx et svagstrømsinput.
direction="ReadOnly" betyder, at openHAB kun kan aflæses status og ikke sætte den. Í mit tilfælde er det en stikkontakt. direction="WriteOnly" betyder, at openHAB kun kan sende status, men modtager intet ved ændring. I mit tilfælde et det input og output tryk, som jeg sender til. 
pulseWidth=80 betyder, at der kun sendes en puls på 80 millisekunder, hvorefter signalet sættes tilbage. I mit tilfælde er for at gøre det samme som ved fysisk at trykke på et svagstrømstryk. I det viste eksempel kan jeg få stikkontakten til at tænde og slukke, men det sker ved at simulere tryk på et svagstrømstryk. På den måde aktiverer jeg relevante fb'ere i IHC i stedet for blot at ændre output status.
Items
Dernæst skal man oprette en ihc.items fil i folderen /etc/openhab2/conf/items/. Eksempelvis således:
Switch    KaelderVaerVestStikkontakt "Stikkontakt"    <poweroutlet>   {channel="ihc:controller:haldIHC:ThKaelderVaerVestStikkontakt,ihc:controller:haldIHC:ThKaelderVaerVestTrykNederstHojre,ihc:controller:haldIHC:ThKaelderVaerVestTrykNederstVenstre"} Items er logiske objekter i openHAB, som har en status, og man ændre denne status. De kan forbindes til en thing, som viste i eksempler herover.
Bemærk at der er nævnt 3 Things i channel med komma imellem. Det betyder, at modtagne og sendte status er forbundet til alle 3 Things. Men fordi vi har ReadOnly og WriteOnly i Things definitionen, så er det ikke alt, som sendes eller modtages fra IHC Controlleren.
Det virker umiddelbart lidt besværligt, men fordelen er, at man altid vil have en openHAB, som er i sync med IHC også ved almindelig fysisk betjening samt at fb'ere aktiveres i stedet for blot at overskrive et output.
 
Item i eksemplet ovenfor - KaelderVaerVestStikkontakt - skal man dernæst placere i en fil kaldet ihc.sitemap som vist i denne linie:
Switch item=KaelderVaerVestStikkontakt hvorved man kan tilgå det via en browser og se og ændre status. Se eksemper herunder:

Det vil default også være port 8080 på aktuelle ip adresse.
En variant af switch er kip. Kip er karakteriseret ved, at du som bruger kan se, om der er lys eller ej (status) og du bruger dette til at beslutte, om du vil tænde eller slukke. Når det kommer til smart house, er det ikke altid optimalt, at aktuel status skal bestemme, om man vil tænde eller slukke. Ved kip forbinder jeg derfor altid to channels til hhv. Tænd og Sluk i min fb, og så lader svagstrømstrykket fortsat være forbundet til Kip i fb'en. Herved kan man undgå nogle udfordringer med kip.
Dimmer
Brug af lysdæmper i smart house er bedst med tilbagemelding, og det vil sige enten IHC wireless Ø80 eller den nye LED rs485 tavledimmer. I begge tilfælde skal det i openHAB være typen dimmer og resourceID skal pege på "Lys niveau" i Visual. Se eksempel tidligere med "ThKaelderVaerVestDimmer".
ihc.items skal være:
Dimmer     KaelderVaerVestDimmer "Spot i loft dimmer" <light>           {channel="ihc:controller:haldIHC:ThKaelderVaerVestDimmer"} ihc.sitemap skal være:
Slider item=KaelderVaerVestDimmer hvorved man får en "slider" som vist i tidligere skærmkopi.
Det var det! - så er man i gang med smart house til IHC med detailkontrol og fuld 2-vejs sync af ændringer. 
Tilmed er der rigtig mange muligheder i openHAB, og kan jeg ikke gennemgå alle her.

Jeg forstår. 
Men jeg forstår ikke det du oplever.. Det virker som om at du upladdar til en anden controller. Og jeg forstår ikke hur Visual ikke kan melde fejl, når den tydligan ikke har modtaget projektet. 
Jeg har aldrig hørt om det problem før.. Og jeg vet ikke helt hvad som kan gøres.
Kan du opladdar et tomt projekt?

Dit billede viser da ingen fejl???
Hvorfor tror du at controlleren ikke har taget imot projektet?

Kan godt være du har ret, Henning. Kan ikke finde den tråd med afstemningen i. Og nu jeg tænker over det er .33 vist også ret ny, så det kan næppe være den. 

Kombi tæller med.

Var det ikke bedre at hive openhab eller IHC Captain fra, og på den måde finde ud af, om een af dem laver ballade?
At fjerne controlleren fortæller dig jo ikke rigtig noget, (efter min mening). Og slet ikke at du skal vente til dagen efter. Hvis noget udefra sløver din controller, så ville/burde det stoppe, så snart du fjerner "udefra". Udefra kan være openhab, IHC Captain, men det kan også komme "længere udefra", fx internettet. 
Derfor ville jeg starte med det mest oplagte, openhab og bagefter IHC Captain. 
Hvis der stadigvæk er problemer der, så kan det jo være andet, udefra, eller måske er det i virkeligheden "indefra".  Det er svært at sige præcist. Så du må igen bruge udelukkelsesmetoden.

EDIT - Glem det.. Jeg sidder og snork sover 

Min gamle HW6.1 installerede jeg firmwaren på. Den havde ingen problemer i de par uger jeg brugte den, og den fik daglig "tæsk". (Skiftede til en HW6.2 kort efter).  

En forskel er, at den længe ventede IHC DIN LED dimmer åbenbart kun kan bruges med Visual 3. Det er ærgerligt.

Klø du bare på Mikkel.. Jeg har en ekstra HW6 controller liggende, så bare venter på et oplagt emne at misbruge den på 

Inspireret af Zafranski´s indlæg fra August 2019 om Roth varmestyring, så kommer her en lille hurtigt vejledning til, hvordan man får IHC varmestyring til at virke med openHAB2 og Google Home. 
Det forudsætter at man har opsat sin openHAB2 med forbindelse til myopenhab.org cloud. openHAB skal/bør helst være version 2.5. eller nyere. 
Det er IKKE tiltænkt som en guide til openhab generelt. Det forudsætter derfor man har en vis viden om things og items, eller i det mindste kan gennemskue det grundlæggende.

Der er brugt en temperatur & fugt sensor fra Zigza, men en "original" IHC gør præcis det samme. 
Der er brugt IHC avanceret varmestyrings blok 5.2.05.c på en HW6.2 controller med firmware 2.8.4.

Bemærk - Det er opsat med en things fil, fordi man skal bruge setpunkt i varmestyrings funktionsblokken. Setpunktet er ikke tilgængelig via produktet, desværre. Det er muligt man kan hekse noget på een eller anden måde. Spørg en IHC ekspert :-)


ihc.things:
ihc:controller:elko [ hostname="IP", username="username", password="password", timeout=10000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: // Stort bad - Rum Type number :stortbad_temperatur_fb "Stortbad Temperatur" [ resourceId=7986196, direction="ReadOnly" ] Type number :stortbad_temperaturSet_fb "Stortbad Temperatur setpunkt" [ resourceId=7989780 ] Type number :stortbad_fugtighed "Stortbad Fugtighed" [ resourceId=13699623, direction="ReadOnly" ] Type number :stortbad_sensorfejl "Stortbad sensorfejl" [ resourceId=7989522, direction="ReadOnly" ] Type switch :stortbad_telestat "Stortbad Telestat" [ resourceId=6144859, direction="ReadOnly" ] } Forklaring:
things filen gør intet andet end, at den laver dels laver selve bridge (broen) mellem openhab og IHC controlleren.
Og nedenunder defineres channels manuelt, ud fra de resourceIDére som man skal bruge (dem der står i [  ] klammerne). direction=ReadOnly" giver sig selv. OpenHAB læser kun fra IHC controlleren på disse resourceIDére. Der hvor der ikke er sat noget direction, der er det ReadWrite, fordi det er default. Og det er netop det man skal bruge til setpunktet, for at man kan skifte temperaturen (setpunktet) på en IHC "termostat" fx via Google Home. 
 
ihc.items:
//Stort Bad Group g_Stortbad_TSTAT "Stort Bad Termostat" [ "Thermostat" ] Number stort_bad_Temperature "Stort Bad Temperatur [%.1f °C]" <cu_heating> (g_Stortbad_TSTAT) [ "CurrentTemperature" ] { channel="ihc:controller:elko:stortbad_temperatur_fb" } Number stort_bad_Tempsetpunkt "Stort Bad Temperature setpunkt [%.1f °C]" <temperature> (g_Stortbad_TSTAT) [ "homekit:TargetTemperature" ] { channel="ihc:controller:elko:stortbad_temperaturSet_fb", autoupdate="false" } Number stort_bad_fugt "Stort Bad Fugtighed [%.0f %%]" <Humidity> (g_Stortbad_TSTAT) [ "CurrentHumidity" ] { channel="ihc:controller:elko:stortbad_fugtighed" } String stort_bad_Mode "Stort Bad Mode [%s]" (g_Stortbad_TSTAT) [ "homekit:TargetHeatingCoolingMode" ] Switch telestat1_stort_bad "Stort Bad Telestat [%s]" <cu_switch> (g_Stortbad_TSTAT) { channel="ihc:controller:elko:stortbad_telestat" } Forklaring:
Først skal der laves en Group item. Den hedder i det her tilfælde g_Stortbad_TSTAT. Og den skal bruge Google Home tagget [ "Thermostat" ]. Denne group fortæller Google, at der er tale om en termostat.
Derefter tilføjes de items som skal bruges til samme group for at Google kan forstå og arbejde med denne termostat korrekt. Dvs items som har disse tags:
"CurrentTemperature", den reelle temperatur. 
"Homekit:TargetTemperature", der reelt er setpunktet. <- (Derfor skal den channel være ReadWrite) 
"Homekit:TargetHeatingCoolingMode" som gør det, at den fortæller hvilken "mode" termostaten er i.

Normalt vil man have en "rigtig" termostat som sender et nummer, alt afhængig af om den er heat, cool, ON, OFF eller fx Auto. 
Sådan en funktion har vi ikke med IHC sensorene og varmestyringen, da den reelt "bare" er sensorer/følere, der sender data retur til controlleren, så så kan tænde/slukke en telestat. Derfor er der ikke linket til nogen IHC resourceID for Mode status. Men vi kan sagtens bruge Mode alligevel, og ret smart endda. 

Det gør vi ved at bruge en String type item til "Homekit:TargetHeatingCoolingMode". Ved brug af den og telestaten fortæller vi simpelthen Google om "termostaten" varmer eller ikke-varmer(køler). (heat eller cool). Simpel logik.   

Men først et par billeder af "termostaten i Google Home, når det er sat op, og man har synkroniseret sine enheder. Det ser således ud i Google Home (virker også i Google Nest Hub):

 
Bemærk, det er samme termostat men den er rød på det ene billede og blå på det andet. Det er her Mode og String type item og en simpel rule kommer ind.. 
Den aktuelle temperatur aflæses under teksten "Indendørs". På begge billeder er aktuelle temperatur altså 22.5. Men dreje knappen er den man stiller setpunktet på.
På det røde billede er setpunkt sat til 23grader. Men da temperaturen kun er 22.5 grader, så er den altså i varmetilstand. Telestaten er tændt.
På det blå billede har jeg skruet setpunktet ned til 22 grader. Altså mindre end den egentlig temperatur. Og derfor er den i køletilstand. Telestaten er slukket.

Det her er ikke noget Google selv finder ud af.. Det laves via en simpel rule som benytter telestaten til at fortælle Google, via Mode, hvad status er. Den ser således ud:
rule "heatingmode stortbad" when Item telestat1_stort_bad changed then if (telestat1_stort_bad.state.toString == "ON" ) { stort_bad_Mode.postUpdate("heat") } else { stort_bad_Mode.postUpdate("cool") } end Hvis man har en smule indblik I openhab, så vil man lyn hurtigt gennemskue denne rule. 
Den betyder simpelthen:

Hvis telestat1 er ændret
  så
       Hvis den er ændret til ON
       Sendes "heat" til item stort_bad_Mode
ellers
       Sendes "cool" til item stort_bad_Mode
end

Kort sagt - Er telestaten ON, så sættes Mode til "heat" og ellers er telestaten OFF, og Mode sættes til "cool". 

Det er netop det der trigger Google Home termostaten - "heat" så er den rød, "cool" så er den blå.
Og dette kan vi gøre, fordi det er en String item type. 
 
Selve telestaten styres helt normalt via IHC og setpunktet i varmestyringsblokken. Og fordi vi har ReadWrite på setpunktet, så kan vi også skrue op/ned for setpunktet i IHC varmestyringen via Google Home. 

Så nemt er det faktisk.

Det virker i Google Home app (både Android og IOS). Det virker med Google Nest Hubs, (dem med skærm). Og det virker med stemmekontrol. 
Spørger jeg fx Google "Hey Google, hvad er temperaturen i stort bad" - Så får jeg svaret 22.5 grader. 
Hvis jeg beder Google om at ændre termostaten til 23 grader, så gør Google også det, og setpunktet ændre sig til 23 grader i IHC varmestyrings blokken.
Fordi det er en temperatur og fugt sensor, så kan jeg også sige, "Hey Google, hvad er luftfugtigheden i stort bad". Og Google svarer retur, hvad luftfugtigheden er. 

Man kan IKKE se luftfugtigheden angivet nogle steder.. Der er faktisk ingen der kan forklare, hvorfor man ikke kan se det. Men det er en feature som Google åbenbart ikke mener er nødvendig at kunne se, men som man skal spørge ind til.. Lidt mystisk holdning, men det er altså Google´s skyld. 

Thats it.. Håber det kan bruges til noget. 
Spørgsmål - Så bare skyd løs.

 

Da vi købte vores hus for 3 år siden med IHC, der var min viden omkring smarthome begrænset til Philips Hue, som jeg havde haft siden det kom på markedet. Og allerede på det tidspunkt var jeg rimelig træt af det.
Da det gik op for mig, hvad IHC egentlig var for noget, så tog tingene (interessen) i den grad til. Bla med at sætte mig ind i hvordan det her IHC var strikket sammen, (der var absolut ingen dokumentation på hele huset, som i min optik er en rimelig stor installation fordelt på 296m2 og 13 rum). Samtidig med jeg blev klogere på IHC, så gik jeg stille og roligt i gang med at udvide installationen, bla med IHC alarm, og derefter IHC varmestyring. Ydermere gik det også op for mig, hvor begrænset IHC egentlig var i sig selv. Jeg synes jeg manglede nogle ting, specielt integration til de relative nemme Z-wave enheder, som oprindelig var min plan at tilføje en hulens masse PIR til udendørsbelysningen, og måske også noget varmestyringspanel i værelser/rum. Derfor begyndte jeg at kigge på, hvordan man kunne "smelte" IHC sammen med andet, og fik da også rodet mig ud i nogle systemer, som dengang påstod de kunne en hel masse sammen med IHC, først openhab, der selvom det virkede med IHC, så var det simpelthen for tidskrævende til min tålmodighed, på det tidspunkt. Så prøvede jeg Domiticz og Home Assistant, men fandt hurtigt ud af, at de var på det tidspunkt ikke specielt klar til IHC. Og de var kun lidt mindre besværligere end openhab. Så efter nogle få ugers forgæves forsøg, blev jeg stædig og vendte tilbage til openhab. Det skulle jeg nok aldrig ha gjort, for selv efter mere end 2 år, sidder jeg stadigvæk næsten dagligt og pille-roder-rager i det. Og hele min oprindelige plan (med integrering af Z-wave og smart udendørsbelysning og overvågning) blev vendt fuldstændig op og ned, specielt efter der kom mulighed for stemmestyring.
Min første prioritet blev at få fuld stemmestyring i hele huset. Samtidig med det, så vil jeg have en ordentlig monitor, hvor man kan se status på hele huset på een gang. Jeg har IHCremote og IHCtablet, men må erkende, det er ikke godt nok, (og jeg har ikke haft tålmodighed nok til at sætte mig ordentlig ind i Scene viewer/Design, selvom det nok i virkeligheden kunne give mig det samme, ihvertfald med IHC installationen. Men med openhab har jeg til gengæld åbnet en mega dør til praktisk talt alt muligt andet, samtidig med jeg kan lave en ordentlig monitorering af husets tilstand. Så der var ikke umiddelbart nogen grund til at begynde at rode med noget begrænset IHC. 

Status i dag er, at nærmest alt hvad der kan integreres er integreret. Det er langt langt overgået min oprindelige plan, fordi jeg "desværre" har for vane at ikke kunne begrænse mig. Det betyder at jeg faktisk har fuld overvågning og styring på tværs af: (tilfældig rækkefølge)
Chromecast enheder i huset, inkl Google Home enheder. 
Philips Hue
IHC
IPkamera
Modbus (til Nilan ventilations anlæg og solcelleanlæg med batteri)
MQTT (snakker sammen med Sonoff enheder, som jeg bruger til at måle strøm på forskellige forbrugsgenstande)
Netamo (vejr station)
Netværk (alle faste og Wifi enheder i huset inkl specifik Ubiquiti Unifi, som bla bruges til at finde ud af, hvem der er hjemme)
OpenWeatherMap - En online vejr data udbyder.
TP-Link Smart Home produkter. Jeg har selv kun en enkelt stikkontakt som kan måle strøm forbrug). 
Velux, som styres via et KLF200 interface.
Xiaomi Mi og Aqara enheder, inkl en støvsugerobot. 
Lidt forskellige Z-wave enheder, primært PIR enheder.
Zigbee - Igen primært PIR.

Alt er som sagt integeret på tværs, hvor openhab mest af alt leger gateway. Jeg har nogle forholdsvis få rules i openhab, som dog primært bruges til at overvåge forskellige enheder. Men det er bla via openhab, at jeg har fuld automatisk vinduestyring af vores 8 ovenlys Velux vinduer, som bla arbejder sammen med IHC Alarm. (Er vinduerne åbne og alarmen kobles til, så lukkes de automatisk). 
Jeg kan, hvis jeg vil, styre nærmest alt fra IHC tryk rundt omkring i huset. Men som nævnt, så er det en funktion jeg bare ikke gider bruge ret meget, hvis jeg kan undgå det. Meningen er det skal passe sig selv. Og når der er behov for at trykke på noget, så er der kommet stemmestyring på, så familien selv kan vælge, om de vil rende rundt efter trykkene, og stå og lege med dem, eller de bare vil sige, hvad der skal ske
Det hele er integereret via en grafisk plantegning af huset som viser alt, (eller dvs det er meningen med det.. Jeg knokler mig igennem at lære SVG kodning/vektor grafik). 
Planen er at den skal placeres centralt, (eller hvor den giver bedst mening) og kunne aktiveres med stemmen, (muligvis et IHC tryk også). Og så kan man som sagt se status på hele huset. 
Det lyder af meget, hvorfor det også er inddelt i forskellige lag, som selvfølgelig kan aktiveres/deaktiveres med stemmestyring. 
Her er en foreløbig plan. Når mine kreative evner er blevet gode nok, så kommer det forhåbentlig til at se lidt bedre ud:
 
 

 

Inspireret af Zafranski´s indlæg fra August 2019 om Roth varmestyring, så kommer her en lille hurtigt vejledning til, hvordan man får IHC varmestyring til at virke med openHAB2 og Google Home. 
Det forudsætter at man har opsat sin openHAB2 med forbindelse til myopenhab.org cloud. openHAB skal/bør helst være version 2.5. eller nyere. 
Det er IKKE tiltænkt som en guide til openhab generelt. Det forudsætter derfor man har en vis viden om things og items, eller i det mindste kan gennemskue det grundlæggende.

Der er brugt en temperatur & fugt sensor fra Zigza, men en "original" IHC gør præcis det samme. 
Der er brugt IHC avanceret varmestyrings blok 5.2.05.c på en HW6.2 controller med firmware 2.8.4.

Bemærk - Det er opsat med en things fil, fordi man skal bruge setpunkt i varmestyrings funktionsblokken. Setpunktet er ikke tilgængelig via produktet, desværre. Det er muligt man kan hekse noget på een eller anden måde. Spørg en IHC ekspert :-)


ihc.things:
ihc:controller:elko [ hostname="IP", username="username", password="password", timeout=10000, loadProjectFile=true, createChannelsAutomatically=true ] { Channels: // Stort bad - Rum Type number :stortbad_temperatur_fb "Stortbad Temperatur" [ resourceId=7986196, direction="ReadOnly" ] Type number :stortbad_temperaturSet_fb "Stortbad Temperatur setpunkt" [ resourceId=7989780 ] Type number :stortbad_fugtighed "Stortbad Fugtighed" [ resourceId=13699623, direction="ReadOnly" ] Type number :stortbad_sensorfejl "Stortbad sensorfejl" [ resourceId=7989522, direction="ReadOnly" ] Type switch :stortbad_telestat "Stortbad Telestat" [ resourceId=6144859, direction="ReadOnly" ] } Forklaring:
things filen gør intet andet end, at den laver dels laver selve bridge (broen) mellem openhab og IHC controlleren.
Og nedenunder defineres channels manuelt, ud fra de resourceIDére som man skal bruge (dem der står i [  ] klammerne). direction=ReadOnly" giver sig selv. OpenHAB læser kun fra IHC controlleren på disse resourceIDére. Der hvor der ikke er sat noget direction, der er det ReadWrite, fordi det er default. Og det er netop det man skal bruge til setpunktet, for at man kan skifte temperaturen (setpunktet) på en IHC "termostat" fx via Google Home. 
 
ihc.items:
//Stort Bad Group g_Stortbad_TSTAT "Stort Bad Termostat" [ "Thermostat" ] Number stort_bad_Temperature "Stort Bad Temperatur [%.1f °C]" <cu_heating> (g_Stortbad_TSTAT) [ "CurrentTemperature" ] { channel="ihc:controller:elko:stortbad_temperatur_fb" } Number stort_bad_Tempsetpunkt "Stort Bad Temperature setpunkt [%.1f °C]" <temperature> (g_Stortbad_TSTAT) [ "homekit:TargetTemperature" ] { channel="ihc:controller:elko:stortbad_temperaturSet_fb", autoupdate="false" } Number stort_bad_fugt "Stort Bad Fugtighed [%.0f %%]" <Humidity> (g_Stortbad_TSTAT) [ "CurrentHumidity" ] { channel="ihc:controller:elko:stortbad_fugtighed" } String stort_bad_Mode "Stort Bad Mode [%s]" (g_Stortbad_TSTAT) [ "homekit:TargetHeatingCoolingMode" ] Switch telestat1_stort_bad "Stort Bad Telestat [%s]" <cu_switch> (g_Stortbad_TSTAT) { channel="ihc:controller:elko:stortbad_telestat" } Forklaring:
Først skal der laves en Group item. Den hedder i det her tilfælde g_Stortbad_TSTAT. Og den skal bruge Google Home tagget [ "Thermostat" ]. Denne group fortæller Google, at der er tale om en termostat.
Derefter tilføjes de items som skal bruges til samme group for at Google kan forstå og arbejde med denne termostat korrekt. Dvs items som har disse tags:
"CurrentTemperature", den reelle temperatur. 
"Homekit:TargetTemperature", der reelt er setpunktet. <- (Derfor skal den channel være ReadWrite) 
"Homekit:TargetHeatingCoolingMode" som gør det, at den fortæller hvilken "mode" termostaten er i.

Normalt vil man have en "rigtig" termostat som sender et nummer, alt afhængig af om den er heat, cool, ON, OFF eller fx Auto. 
Sådan en funktion har vi ikke med IHC sensorene og varmestyringen, da den reelt "bare" er sensorer/følere, der sender data retur til controlleren, så så kan tænde/slukke en telestat. Derfor er der ikke linket til nogen IHC resourceID for Mode status. Men vi kan sagtens bruge Mode alligevel, og ret smart endda. 

Det gør vi ved at bruge en String type item til "Homekit:TargetHeatingCoolingMode". Ved brug af den og telestaten fortæller vi simpelthen Google om "termostaten" varmer eller ikke-varmer(køler). (heat eller cool). Simpel logik.   

Men først et par billeder af "termostaten i Google Home, når det er sat op, og man har synkroniseret sine enheder. Det ser således ud i Google Home (virker også i Google Nest Hub):

 
Bemærk, det er samme termostat men den er rød på det ene billede og blå på det andet. Det er her Mode og String type item og en simpel rule kommer ind.. 
Den aktuelle temperatur aflæses under teksten "Indendørs". På begge billeder er aktuelle temperatur altså 22.5. Men dreje knappen er den man stiller setpunktet på.
På det røde billede er setpunkt sat til 23grader. Men da temperaturen kun er 22.5 grader, så er den altså i varmetilstand. Telestaten er tændt.
På det blå billede har jeg skruet setpunktet ned til 22 grader. Altså mindre end den egentlig temperatur. Og derfor er den i køletilstand. Telestaten er slukket.

Det her er ikke noget Google selv finder ud af.. Det laves via en simpel rule som benytter telestaten til at fortælle Google, via Mode, hvad status er. Den ser således ud:
rule "heatingmode stortbad" when Item telestat1_stort_bad changed then if (telestat1_stort_bad.state.toString == "ON" ) { stort_bad_Mode.postUpdate("heat") } else { stort_bad_Mode.postUpdate("cool") } end Hvis man har en smule indblik I openhab, så vil man lyn hurtigt gennemskue denne rule. 
Den betyder simpelthen:

Hvis telestat1 er ændret
  så
       Hvis den er ændret til ON
       Sendes "heat" til item stort_bad_Mode
ellers
       Sendes "cool" til item stort_bad_Mode
end

Kort sagt - Er telestaten ON, så sættes Mode til "heat" og ellers er telestaten OFF, og Mode sættes til "cool". 

Det er netop det der trigger Google Home termostaten - "heat" så er den rød, "cool" så er den blå.
Og dette kan vi gøre, fordi det er en String item type. 
 
Selve telestaten styres helt normalt via IHC og setpunktet i varmestyringsblokken. Og fordi vi har ReadWrite på setpunktet, så kan vi også skrue op/ned for setpunktet i IHC varmestyringen via Google Home. 

Så nemt er det faktisk.

Det virker i Google Home app (både Android og IOS). Det virker med Google Nest Hubs, (dem med skærm). Og det virker med stemmekontrol. 
Spørger jeg fx Google "Hey Google, hvad er temperaturen i stort bad" - Så får jeg svaret 22.5 grader. 
Hvis jeg beder Google om at ændre termostaten til 23 grader, så gør Google også det, og setpunktet ændre sig til 23 grader i IHC varmestyrings blokken.
Fordi det er en temperatur og fugt sensor, så kan jeg også sige, "Hey Google, hvad er luftfugtigheden i stort bad". Og Google svarer retur, hvad luftfugtigheden er. 

Man kan IKKE se luftfugtigheden angivet nogle steder.. Der er faktisk ingen der kan forklare, hvorfor man ikke kan se det. Men det er en feature som Google åbenbart ikke mener er nødvendig at kunne se, men som man skal spørge ind til.. Lidt mystisk holdning, men det er altså Google´s skyld. 

Thats it.. Håber det kan bruges til noget. 
Spørgsmål - Så bare skyd løs.

 

Da vi købte vores hus for 3 år siden med IHC, der var min viden omkring smarthome begrænset til Philips Hue, som jeg havde haft siden det kom på markedet. Og allerede på det tidspunkt var jeg rimelig træt af det.
Da det gik op for mig, hvad IHC egentlig var for noget, så tog tingene (interessen) i den grad til. Bla med at sætte mig ind i hvordan det her IHC var strikket sammen, (der var absolut ingen dokumentation på hele huset, som i min optik er en rimelig stor installation fordelt på 296m2 og 13 rum). Samtidig med jeg blev klogere på IHC, så gik jeg stille og roligt i gang med at udvide installationen, bla med IHC alarm, og derefter IHC varmestyring. Ydermere gik det også op for mig, hvor begrænset IHC egentlig var i sig selv. Jeg synes jeg manglede nogle ting, specielt integration til de relative nemme Z-wave enheder, som oprindelig var min plan at tilføje en hulens masse PIR til udendørsbelysningen, og måske også noget varmestyringspanel i værelser/rum. Derfor begyndte jeg at kigge på, hvordan man kunne "smelte" IHC sammen med andet, og fik da også rodet mig ud i nogle systemer, som dengang påstod de kunne en hel masse sammen med IHC, først openhab, der selvom det virkede med IHC, så var det simpelthen for tidskrævende til min tålmodighed, på det tidspunkt. Så prøvede jeg Domiticz og Home Assistant, men fandt hurtigt ud af, at de var på det tidspunkt ikke specielt klar til IHC. Og de var kun lidt mindre besværligere end openhab. Så efter nogle få ugers forgæves forsøg, blev jeg stædig og vendte tilbage til openhab. Det skulle jeg nok aldrig ha gjort, for selv efter mere end 2 år, sidder jeg stadigvæk næsten dagligt og pille-roder-rager i det. Og hele min oprindelige plan (med integrering af Z-wave og smart udendørsbelysning og overvågning) blev vendt fuldstændig op og ned, specielt efter der kom mulighed for stemmestyring.
Min første prioritet blev at få fuld stemmestyring i hele huset. Samtidig med det, så vil jeg have en ordentlig monitor, hvor man kan se status på hele huset på een gang. Jeg har IHCremote og IHCtablet, men må erkende, det er ikke godt nok, (og jeg har ikke haft tålmodighed nok til at sætte mig ordentlig ind i Scene viewer/Design, selvom det nok i virkeligheden kunne give mig det samme, ihvertfald med IHC installationen. Men med openhab har jeg til gengæld åbnet en mega dør til praktisk talt alt muligt andet, samtidig med jeg kan lave en ordentlig monitorering af husets tilstand. Så der var ikke umiddelbart nogen grund til at begynde at rode med noget begrænset IHC. 

Status i dag er, at nærmest alt hvad der kan integreres er integreret. Det er langt langt overgået min oprindelige plan, fordi jeg "desværre" har for vane at ikke kunne begrænse mig. Det betyder at jeg faktisk har fuld overvågning og styring på tværs af: (tilfældig rækkefølge)
Chromecast enheder i huset, inkl Google Home enheder. 
Philips Hue
IHC
IPkamera
Modbus (til Nilan ventilations anlæg og solcelleanlæg med batteri)
MQTT (snakker sammen med Sonoff enheder, som jeg bruger til at måle strøm på forskellige forbrugsgenstande)
Netamo (vejr station)
Netværk (alle faste og Wifi enheder i huset inkl specifik Ubiquiti Unifi, som bla bruges til at finde ud af, hvem der er hjemme)
OpenWeatherMap - En online vejr data udbyder.
TP-Link Smart Home produkter. Jeg har selv kun en enkelt stikkontakt som kan måle strøm forbrug). 
Velux, som styres via et KLF200 interface.
Xiaomi Mi og Aqara enheder, inkl en støvsugerobot. 
Lidt forskellige Z-wave enheder, primært PIR enheder.
Zigbee - Igen primært PIR.

Alt er som sagt integeret på tværs, hvor openhab mest af alt leger gateway. Jeg har nogle forholdsvis få rules i openhab, som dog primært bruges til at overvåge forskellige enheder. Men det er bla via openhab, at jeg har fuld automatisk vinduestyring af vores 8 ovenlys Velux vinduer, som bla arbejder sammen med IHC Alarm. (Er vinduerne åbne og alarmen kobles til, så lukkes de automatisk). 
Jeg kan, hvis jeg vil, styre nærmest alt fra IHC tryk rundt omkring i huset. Men som nævnt, så er det en funktion jeg bare ikke gider bruge ret meget, hvis jeg kan undgå det. Meningen er det skal passe sig selv. Og når der er behov for at trykke på noget, så er der kommet stemmestyring på, så familien selv kan vælge, om de vil rende rundt efter trykkene, og stå og lege med dem, eller de bare vil sige, hvad der skal ske
Det hele er integereret via en grafisk plantegning af huset som viser alt, (eller dvs det er meningen med det.. Jeg knokler mig igennem at lære SVG kodning/vektor grafik). 
Planen er at den skal placeres centralt, (eller hvor den giver bedst mening) og kunne aktiveres med stemmen, (muligvis et IHC tryk også). Og så kan man som sagt se status på hele huset. 
Det lyder af meget, hvorfor det også er inddelt i forskellige lag, som selvfølgelig kan aktiveres/deaktiveres med stemmestyring. 
Her er en foreløbig plan. Når mine kreative evner er blevet gode nok, så kommer det forhåbentlig til at se lidt bedre ud:
 
 

 

Vanen tro, trods adskillige forsøg på at undgå at kommunikere med dig, så besvarer du igen et af mine indlæg, fordi du ikke bryder dig om indholdet, samtidig med du anfægter mig personligt.
Endnu mere vanen tro missede du, som sædvanlig, "bare" den kontekst som lå i det jeg citerede, eller så blev et ord "essentielt" simpelthen for svært for dig at forstå. (Måske du burde slå det op, og så lige minde dig selv om, at det faktisk var en anden der skrev det, og det jeg citerede. Men dit personlig angreb vendte du igen imod mig).  

LK lytter ikke til privatpersoner, hvad du selv flere gange har påpeget. Så hvad nytter det at jeg brokker mig til dem? (Lad være med at svare - Dit svar kan aldrig komme til at give mening). 
Netop fordi LK ikke kommunikere (og lytter) med private, så finder jeg det vigtigt at ytre mig om det, så andre uvidende har mulighed for at vide, hvordan det forholder sig. Heller en gang for meget end for lidt. I stedet for at "gemme" virkeligheden i et LK regi, hvor andre ikke ser det, som åbenbart er din foretrukne metode. 
Der findes moderatorer her, der nok skal fortælle, hvis visse ytringer ikke er i orden. Måske du skulle overlade vurderingen til dem, (igen).  
 
"Ingen" er et stort ord, udtalt af en enkelt person, som tilsyneladende har travlt med noget der mere minde om personlig forfølgelse!
Du havde alle muligheder for at lade være med at kommentere mit indlæg. Du er sågar flere gange blevet opfordret til at lade være. Alligevel gør du det!
Apropos at forpeste - Kan du få forklare mig forskellen på mine indlæg, og så dine evige tilbagevende omkring min holdning og ytringer ang LK, præcis som denne gang?  (<--- et ordsprog der har ord som "sten" og "glashus" kan måske være en ledetråd for dig her).
 

Det er skam ikke mit største problem (igen tager du fejl). Men det er, på trods af omstændighederne, et stort unødige problem. Som du netop også ville have kunnet tydet, hvis du ikke havde været så fokuseret på få af de ord du har citeret, og dermed (igen) forsøgt at manipulere konteksten, i det jeg ytre mig om. 

Der var en fejl - det er nu løst :p

ServiceView er også et fronend bruger interface, og der kan man sætte rampetider, runtime værdier og initial værdier, så dit argument holder som sædvanlig ikke.

Hej Kandersen
Tak for dit svar, og undskyld den sene respons :).
Jeg kan se fejlen jeg har lavet er, at jeg oprettede dem som Generic number..
 
 

Det virker fint.. Her er resultatet jeg får:
 
2019-10-21 19:28:04.760 [vent.ItemStateChangedEvent] - test_Ur changed from NULL to 2000-01-01T07:31:00.000+0100 2019-10-21 19:28:15.777 [vent.ItemStateChangedEvent] - test_Ur changed from 2000-01-01T07:31:00.000+0100 to 2000-01-01T08:31:00.000+0100 Jeg har indsat FBén og lagt resourceID in i min manuelle things til sådan her:
 
Type datetime :testur "Test ur" [ resourceId=17534733 ] I items har jeg defineret den således:
 
DateTime test_Ur "Test Ur [%1$tH:%1$tM:%1$tS] " <time> { channel="ihc:controller:elko:testur" } Og sådan her i sitemap:
 
Text item=test_Ur Og ser således ud i sitemap:

Jeg har ikke prøvet at skrive tilbage til controlleren. Men det burde være det samme. 
 
EDIT: Jeg har heller ikke prøvet i Habpanel. Men jeg formoder det virker fint derfra, når det virker i BasicUI (og ikke mindst at jeg får data i loggen).

De her relæer kan bruges på et output modul:
https://www.elsag.dk/relae-24v-ac
Kontakten bruges så til at åbne eller lukke porten med. 

Jeg var ved at skrive et langt svar på din kommentar til mit indlæg. Men da jeg kom til slutningen kom jeg til den konklusion at det hele handler om hvad der er "godt nok". Du skrev selv noget om at 5-10 Mbit var godt nok. Det er det ikke til mig. Hvis man køber en +300MBit internet forbindelse og forventer at man kan udnytte den med wireless så snyder man sig selv.
Jeg sidder lige nu i min stue. Der er 3 meter line-of-sight til et Cisco WAP581 access point. Når jeg gennemfører en speedtest ender jeg på 300MBit ... med et kabel i væggen ender jeg på 900MBit. Både computer og AP har er moderne. Netværk er 5GHz 80MHz "channel width" og internet forbindelse er købt som 1GBit. Der er selvfølgeligt mange der vil sige at 300MBit er fint og det er det også. Men husk på at dette er absolut best case. 3 meter. Line-of-sight. Hvis jeg går ind i et andet rum falder hastigheden. Havde jeg kun et AP eller brugte Yousee's AP så ville der ikke være forbindelse på 5 GHz båndet i halvdelen af lejligheden. Dette har jeg ikke kun oplevet i egen bolig, men også i andre boliger, men det afhænger selvfølgeligt af boligens beskaffenhed.
I ældre etage ejendomme med etageadskillelse af træ er det min erfaring at signalet propagerer fint igennem gulve og dårligt gennem vægge. Dette betyder at under- og overboens signal i nogle tilfælde støjer over det svage signal fra eget AP. Wireless i en-familie huse er selvfølgeligt en helt anden sag.
Så er der diskussionen om godt nok. Folks behov er meget forskellige og nogen gange forstår de ikke hvad de har behov for. Gamere har behov for lav latency - streamere har behov for høj båndbredde. Wireless har højere latency (og specielt meget højere varians i latency) i alle tests jeg har lavet. Med ISP access points er den nogen gange alt for høj. Båndbredde kan vi diskutere fra nu og til solen brænder ud. Alle moderne streaming protocoller vil indrette sig efter båndbredden så der vil altid dukke et billede op på skærmen. Jeg har set 4K 60Hz streaming bruge mere end 100Mbit. Meget få steder kan Chromecast Ultra streame i 4K 60Hz over wireless - af samme grund leverer Google dimsen med ethernet adapter.
Men som sagt handler det om behov. Og de er åbenbart forskellige.