Kandersen

Prøv at tage den fra PaperUI så som jeg viste herover. Jeg er ret sikker på, at når temperaturen ikke vises i PaperUI, så må der være noget galt med den ID du forsøger at tage den fra.

Altså, hvis vi lige ser bort fra resourceIDérne i første omgang.. Lige så snart du har sat et Tag på en item (fx [ "Thermostat" ], så bør den komme frem i Google Home appen, når du vel at mærket har husket at synkronisere dine enheder, (Sig til Google "Hey Google, synkronisere mine enheder". Det gælder et hvilket som helst Google Home Tag. Og det er uanset om resourceID (channels) er korrekte eller ej. Du kan sågar gøre det med en proxy item, (virtual item). Hvis du fx laver en test med denne item: Switch dummy1 "Dummy switch" <switch> [ "Switchable" ] Så burde der komme en "dummy1" switch frem i Google Home appén, (HUSK! at synkronisere dine enheder). Hvis ikke det virker, så vil jeg tro at din forbindelse mellem openhab og Google har et problem. Det burde Google også melde retur, når du synkronisere. PS. Ja BasicUI kræver man har lavet et sitemap. Du kan også bruge controlpanelet i PaperUI. Men det er normalt ikke det jeg anbefaler, fordi jeg synes det kontrolpanel er noget skrald der tager 117 år at loade, når man som mig har rigtig mange channels og items. (hele mit setup, ikke kun IHC). Og nogle gange vil controlpanelet bare ikke vise de rigtige data/opdateringer af status. Derfor bruger jeg altid sitemap, fordi jeg tester funktioner osv den vej igennnem.. Det er selvfølgelig lidt mere omstændigt fordi man skal lave en masse ekstra filer, men det giver mig et temmelig godt overblik over alle mine items og specielt groups. Derfor bruger jeg det altid.

Nu er det ikke noget jeg har rodet med Wifi på mine Rpiére. Min grundholdning er, at hvis de skal drive et smarthome, så bør man ikke tilføje en forlænge kommunikation med Wifi.

Tak.. Måske du burde overveje det Hvis du har sat createChannelsAutomatically=true i bindingen. Så kan du "fange" din temperatur føler i PaperUI. Det er præcis den samme, om det er på produktsiden eller FB siden i Visual. (Jeg laver den bare manuelt, fordi jeg ikke vil blande det sammen, så jeg både har PaperUI items og manuelle items). Her er et billede fra min Visual: Som du kan se i min things fil i første indlæg, så stemmer resourceID overens med Visual. I PaperUI ser den således ud, som er produktsiden i Visual: (Rød er temperatur føleren, blå er fugt, hvis man har det i sin føler). Og her er et tip til dem som fx vil lave manualle things (channels) men er træt af at sidde og knokle rundt i Visual for at finde resourceIDére til produkterne. Temperaturføleren på produktsiden har recourceID 13699860). Dette nummer kan man bruge direkte i sin things fil. Så min channel i things filen for denne temperaturføler kunne lige så godt have set sådan her ud: Type number :stortbad_temperatur_fb "Stortbad Temperatur" [ resourceId=13699860, direction="ReadOnly" ] Og det vil give præcis samme resultat. Hvis du ikke kan få vist din temperatur i appen, men at den fx viser sin fint i BasicUI eller openhab app. Så er det fordi der er noget galt med din item og opsætning af termostaten.. Tjek dit Google Assistant Tag.. Eller brug den nye mulighed med Metadata. https://community.openhab.org/t/openhab-google-assistant-integration-v2-0/85573/185 Lige en vigtig melding: Efter i forgårs er der IKKE længere muligt at få vist en temperaturføler alene i Google Hub eller Google Home app. Man SKAL altså opsætte det som en termostat, (som vist i første indlæg). Så hvis det er det du forsøger, så er det nok det som er årsagen.

Nu er jeg ikke HA mand, men primært openHAB. Min opfattelse af HA er dog, at det er samme princip. Dvs det arbejder med resourceIDére i Visual programmet. Det betyder, at alt hvad der har et resourceID i Visual, det kan du påvirke på een eller anden måde udefra, (via Home Assistant, OpenHAB osv). Til gengæld er jeg blevet lidt i tvivl om scenarier i Visual overhovedet har et resourceID. Jeg bruger det ikke selv, da jeg påvirker produkterne eller FBérne direkte, og egentlig ikke har gjort så meget ud af scenarier. Dvs hvis en funktionsblok starter et scenarie, så er det funktionsblokken (input) som jeg påvirker. Og dermed ikke direkte på scenariet. Med Dimmerne er det lidt anderledes, for der kan jeg påvirke produktet (Dimmeren) direkte i den % sats jeg ønsker at sætte den i. Det betyder, at i det tilfælde der bruger jeg sådan set openhab til logikken (eller hændelsen som det rettelig hedder). Fx hvad en Dimmer skal tænde på, i det øjeblik den bliver påvirket, det har jeg bestemt via Bindingen (openhab). Hvis jeg skulle gøre det samme med logikken i IHC, så skulle jeg påvirke funktionsblokken, fordi det er der scenariet (samme % sats) ligger i. Derfor tror jeg faktisk ikke scenarier i Visual har en resourceID. Men det er hurtigt at tjekke ved at åbne Visual og tjekke om scenariet har en resourceID, ligesom du tjekker andre resourceIDére i Visual. (Hvis jeg husker det, så skal jeg prøve det i aften).

I have a TP-link HS110 Wifi socket. And I use it through openHAB2 where my IHC controller is connected to as well. I have not tested the TP-link through IHC Captain.

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.

Netop

Altså et IHC scenarie der aktiveres fra en tryk knap i HA ? Så er det "bare" selve scenariet du skal trigge fra HA. IHC tryk -> Scenarie_xxx i IHC controlleren. Virker helt normalt også uden HA. HA tryk -> Scenarie_xxx i IHC controlleren. Det vil gøre præcis det samme. Jeg tror det som du spørger om er: HA -> IHC tryk -> Scenarie_xxx Det vil som sagt virke, men er lidt unødigt, når du kan trigge scenariet direkte. Men det er muligt jeg misforstår..

Nu er det ikke fordi jeg ved fantastisk meget om HA. Men hvorfor skulle du have behov for at aktivere trykket fra HA? Ville det ikke være mere korrekt, at aktivere det som trykket normalt aktivere? (hvad enten det er et produkt eller en funktionsblok). Jeg formoder at HA er ligesom openhab på dette punkt, da de begge arbejder med reourceID.

Selvom jeg helt klart synes, at IHC har manglet (mangler) en termostat med display. Så må jeg også erkende, at det ihvertfald med tung gulvvarme nærmest er ret ligegyldigt. Uanset hvad den står og viser når man kigger, så er man alligevel henvist til mindst 6-8 timer, før der kommer en evt reaktion. På den tid kan man snildt bruge ServiceView eller alternativ deres møg-dyre app. Havde jeg haft let gulvvarme, så ville jeg helt klart prioritere en rumføler med display på een eller anden måde. Som du selv nævner, så er en lille tablet en mulighed, dog med noget 3.part styring bag. Desværre er tablets bare heller ikke specielt egnet, fordi en del af dem tåler fx ikke at sidde i oplader konstant. Og på batteri løber de alt for hurtigt tør for strøm (selv i standby). Der findes nogle særlige "cowboy trick" man kan lave, så de kan stå med konstant strøm på. Men det er en noget speciel affære og involvere noget lodning og ekstra elektronik. Det jeg ikke forstå ved disse standalone systemer og deres trådløse rumfølere, det er at de ikke benytter en allerede kendt standard, men altid skal opfinde den dybe tallerken gang på gang. Bevars, hver producent vil gerne sætte deres finger på produkterne. Men de bliver altså ikke unikke af at benytte en anden trådløs protokol. Og lige præcis mht rumfølerne, der ville det altså være betydelig nemmere om man bare brugte en kendt standard, og så nøjedes med at lave styringen så unik og intelligent som muligt. Det næste bliver vel, at de laver hver deres telestat også . Der er et mærke (kan ikke huske navnet) de bruger Zigbee til deres rumfølere, (den har ikke IR gulvføler). Danfoss har rodet med noget z-wave, men det er vist droppet igen, eller så er det deres egen lukkede z-wave protokol. Dette er hvad jeg lige kan komme på. Det er ufatteligt at vi forbrugere ikke stiller langt flere krav til producenterne (helt generelt). Det koster os alle vanvittig mange flere penge, og man får oftest ikke noget som helst anderledes ud af det. Synes bestemt ikke vi er off topic.. Det er rimelig relevant for varmestyring generelt. Med eller uden gulvføler

Okay en del af dem er nyere end da jeg kiggede efter det (for snart 3 år siden). Et af mine problemer var også, at jeg helst ikke vil have et trådløst system. I et stort 1-plans hus som vores, så vil alle trådløse muligheder have rimelig store problemer med at dække huset i forhold til hvor manifolden er placeret (og dermed varmestyringen), fordi den er placeret ude i den lukkede garage i den ene ende af huset. Roth (mener jeg det var) kan man få en ekstern antenne til, men med kun med 3m ledning på var min vurdering, at det ikke er nok. Derfor kiggede jeg på fortrådet rumfølere. Jeg havde den fordel, at jeg allerede havde kabel i væggene, der hvor de oprindelige rumføler sad Jeg valgte at opgive skiftet til et nyt trådløst system og lavede IHC varmestyring med IHC følere, som jeg heldigvis kunne bygge ind i de eksisterende termostater-kasser. Prisen havde også en betydning. Med 12 rum (13 kredse) er det en udfordring for disse systemer, plus at det er en rimelig høj pris, alene bare i rumfølere/termostater. Selve styre enhederne er oftest ikke så dyre. Men udfordringen ligger/lå så i antallet af kredse.

Det er langt fra dem alle som har infrarød gulvføler. Dernæst så er det nærmest dobbelt op på styringen, for rigtig nok kan man integrere dem sammen med openhab osv.. Men man skal stadigvæk have styringen.. Sidste problem - Dem jeg har set bruger 230volt.. Skidt ide når man kun har trukket lavstrøms (netværk/alarm/tele/whatever) kabler til rumføleren..

Ohh I know Men er let gulvarme i virkeligheden SÅ meget dyrere, så folk der vælger at bruge flere millioner på et hus, simpelthen vælger at spare denne "fordyrelse" bort tiltrods for den betydelig ringere komfort? Eller er det simpelthen ekstrem ringe rådgivning? (jeg kan godt frygte det sidste, må jeg erkende).

Mja.. Nu er det jo svært at sige om det ville være bedre at vælge traditionel. Hvis du har muligheden for at ændre til traditionel, så kan du vel også få en føler i gulvet, eller? Anyway - vores hus har gulvarme styret af IHC, med rumfølere, og uden gulvføler. Det kan sagtens fungere. Men det ville i visse tilfælde være mere optimalt med en føler i gulvet, da man derved kan slippe for de kolde gulve som ind imellem vil opstå. Så det er altså et komfortmæssig problem der er tale om. Omvendt koster komfort også noget mere. Så lune gulve altid, det er lige med højere varmeregning/forbrug. Skulle jeg vælge i dag, så ville jeg helt klart foretrække at have gulvføler i gulvet og rumføler. Mest af alt, fordi så har man i det mindste muligheden for at vælge komforten. Uden gulvføleren, så er den muligheden udelukket. Eller endnu bedre, så tror jeg faktisk jeg ville have foretrukket let-gulvvarme og så uden gulvføler. (IHC varmestyring kan vistnok slet ikke køre med let-gulvvarme og gulvføler.. Det giver heller ikke så meget mening, synes jeg). Let gulvarme er helt klart langt mere fleksibelt at have med at gøre, og reaktionen kommer promte (inden for få minutter). Jeg er egentlig ikke helt klar over, hvorfor man stadigvæk laver tung gulvvarme i nye huset idag. Det må en klogere kunne svare på. Skyldes det økonomi, så mener jeg ikke det er et godt argument. Så meget dyrere kan let gulvvarme heller ikke være. Ja der skal bruges mere isolering. Og ja der skal nogle stører til. Meeeen så er det vist også det.

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:

Kender det godt. Var selv igennem det for 3 år siden Jo.. Hvad skal man ellers bruge sin sparsomme tid på? Hvis din installation er fra 2012, så er der næppe problemer med controlleren er for gammel.

Mikkel, jeg kan ikke få lov at opdatere fra 1.47 til 1.48. Den bliver ved med at hænge fast i 1.47, hvorefter den selvfølgelig bliver ved med at fortælle mig, at der er en ny version, 1.48..

Hvis dit fokus lige pt ligger på at kunne fjernstyre IHC installationen med app/ipad, så er min anbefaling - Drop LK´s apps. Det er som du selv siger, svine hammerende dyrt, og i flere tilfælde unødigt. Jeg ved ikke hvad Home Assistant har af apps. Jeg bruger selv Openhab2. Openhab2 har en app som fungere ganske glimragende. Via openhab2 og Google Home har jeg også fuld stemmestyring på hele installationen. Så jeg vil ikke se mig tilbage til LK´s apps, selvom jeg har både deres IHCremote og IHCtablet. Men - Både openhab2 og Home Assistant kræver en indlæringsprocess, som kan virke ret stejl. Så man skal have en vis portion interesse og tid til at ville sætte sig ind i det. Ellers går man sandsynligvis lyn hurtig død. Alternativ er Mikkels IHC Captain. Det er super nemt, og han er ekstrem aktiv til at udvikle på det. Det kan du læse mere om her på forumet. Det kræver en Rpi. Men det er en smal sag at få det op og køre. Det er super fedt som app/fjernstyring, selvom det ikke lige er en selvstændig app. Det er et web-interface. Mht til din IHC installation, så er det svært at sige, da det er rimelig begrænset hvad du har givet af oplysninger. Hvis det er en rimelig god/stor installation med tilpas ny controller, så er der faktisk oceaner af muligheder i logik styringen. Men du er nødt til at komme med noget mere info, evt billeder af installationen (moduler/tavle osv) før det er helt muligt at sige noget konkret om det. Jeg har massere af logik styring i min controller, selvom jeg også har openhab2. Det er der flere årsager til. Men den primære årsag er, at hvis openhab går ned (eller jeg mister interessen, sælger huset osv), så kan jeg pille det fra, og huset kører videre næsten som om intet er hændt. Der vil være nogle særlige funktioner, som ikke længere virker. Men grundlæggende, lys, varme, alarm og ventilation med dets IHC logikstyring, virker som det plejer.

No wonder.. Finnish is a strange language (to listen to.. Like dutch is strange as well ). LK should stick with english, and on request, they could provide danish. No need to translate the software into several other languages, when having english at the most. Yes, IHC isnt quite discontinued, (yet). There are quite a few online dealers having most of the devices in stock. Thats good. Did you know, there is a new DIN rail LED Dimmer coming using the RS485 interface? Unfortunatly it requires a newer controller as well, which makes it pretty expencive for quite alot of user. Thats very bad, in my opinion

Thats not a downside.. Thats danish (just kidding ) Its kinda strange Lk has abandonded english. I know IHC is mainly danish, but translating the program and utilities can hardly be such a big job.

Hvilken firmware ligger der på controlleren? Din Visual skal passe med firmwaren. Så måske du skal bruge en ældre Visual.

Der er ting i denne verden som bare ikke kan passe sammen.

Så det er derfor det hedder "ServiceView... " (ironi og sarkasme kan forekomme ). Jeg har ikke rigtig flere "tilladte" ord til overs for den slags diskussioner med dig! Så hvis du absolut føler trang til at ytre dig alligevel, så find en anden der orker at læse det.

Jeg er klar over hvad IHC programmet er tak. Men i min verden burde man holde de to ting adskilt. IHC Captain er et frontend bruger interface. Visual/andet er backend.