Kandersen

Funger perfekt, Mikkel. Inkl genvejen på skrivebordet! En enkelt, meget lille detalje. Det er som om fonten er en del anderledes end hvis man starter det samme via "det sædvanlige". Fonten er mere grov i det. Men det er så absolut til at leve med, hvis alternativet er, at man skal slås med java. Ps. er testet på min controller HW 6.2 med FW 2.8.4 og windows 10, pro.

Okay, så længe har jeg ikke forsøgt at vente

Det gør den helt sikkert ikke. Først når jeg logger ud og ind igen.

Det skal lige siges - Når jeg laver ændringer i Visual, så stopper jeg IHC Captain (ellers tager det for lang tid for Visual at connecte), men logger ikke ud. Når jeg er færdig i Visual og har uploadet det nye program, så starter jeg IHC Captain igen. Og det er i det tilfælde at IHC Captain ikke ser, at der er kommet et nyt program. Hvis jeg logger ud og ind igen, så henter den fint nok det nye program. Så måske virker det i virkeligheden som det skal, det er bare mig der "ødelægger" det, fordi jeg stopper IHC Captain.

Hej @Mikkel Skovgaard Er der mulighed for at IHC Captain kan "lytte" med, når man fx uploader et ny program til controlleren, at IHC Captain så auto loader dette program, uden at man først skal logge ind? Lidt inspiration fra openhab med IHC binding. Hvis openhab (med IHC bindingen) kører samtidig med jeg laver ændringer i Visual. Når jeg så uploader det nye program til controlleren, så går IHC bindingen på en slags "pause", og venter indtil controlleren er klar igen, hvorefter bindingen selv loader det seneste program, helt automatisk. Jeg tænkte om noget lign ikke skulle være muligt i IHC Captain?

Jeg kan ikke hjælpe så meget med problem 1, da jeg aner nada om homekit. Mht problem 2 så har jeg aldrig prøvet det, så derfor er det nok bedst som Ejvind siger, at Pauli kan kommenterer det. Men måske det skyldes du ikke har brugt de rigtige " " i din trigger.. Se fx denne: (en xiaomi regel jeg tester med). rule "Tænd lyset kontor" when Channel "mihome:sensor_switch:158d0002016481:button" triggered SHORT_PRESSED then kontor.sendCommand(ON) end rule "Doorbell" when Channel "mihome:sensor_switch:158d0002016481:button" triggered DOUBLE_PRESSED then sendCommand(SmartHomeGateway_SoundVolume, 3) sendCommand(SmartHomeGateway_SoundSelector, 10) Thread::sleep(5000) /* wait for 5 seconds */ sendCommand(SmartHomeGateway_SoundSelector, 10000) sendCommand(SmartHomeGateway_SoundVolume, 0) end Bemærk " " i trigger linjen. I dine linjer ser det forkert ud. Hvad angår den første regel i problem 2. Så forstår jeg ikke umiddelbart hvorfor den skulle være langsom. Mit bedste bud er, at det er fordi tradfri er langsom, hvis du sender to commands på samme tid til to forskellige enheder. Det er svært at gøre noget ved, hvis det er årsagen.

Kan du poste dine things og items her, eller er det hele lavet i PaperUI ?

Fordi neden under ikke giver mulighed for at ændre setpunkt uden at du skifter tilstand. Og hvis man ikke bruger tilstand, så er det ikke hensigtsmæssigt. (jeg bruger ikke tilstand, da det ikke giver meget mening i den daglige drift med tung gulvvarme). Men man kan sagtens have behov for at ændre setpunkt alligevel, skulle jeg mene. Jeg har dog ikke prøvet om "Normal" virker under indstillinger. Hvis det virker, så har du ret i, at det nok ville være mest korrekt at ændre setpunkt der.

Prøv om du kan skrue skruen ind. Det ser ud som om den er kommet for langt ud, og dermed ikke har fat i pladen som trykker på ledningen. Ved at skrue skruen ind igen, kan du måske få pladen til at løsne sig, mens du vrikker i ledningen (uden at hive den ud, medmindre den skal ud selvfølgelig). Mht til om du kan købe en connector tilsvarende, så vil jeg tro det er muligt. Måske på https://dk.rs-online.com/web/ når nu Aldi ikke gider forhandle det som alle efterspørger :-) Men jeg har ingen ide om, hvad kategori man skal lede under.

Ahh come on.. Du skrev tidligere: Det virker helt klart som den nemmeste løsning med den motor du har fundet der.

Danalock skulle efter sigende være det bedste til det. Men der er nogle tanker man skal gøre sig, fordi Danalock fåes i forskellige interfaces, (bluetooth, homekit, zwave osv). Bluetooth ville nok være det absolut at foretrække, hvis du vil over i noget automatisk (geofencing), da den udbredelse er relativ kort (og dermed langt mere sikker). Mht til at automatisk få den til at låse på bestemte tidspunkter, der er du omvendt over i en anden slags styring, (jeg mener ikke Danalock appén kan det pr default). Her ville jeg personligt foretrække en zwave version. Men det kræver så der er noget automatisk til at styre det med. Jeg har ikke selv rodet med det, andet end at læse om det. Mest af alt fordi jeg er hammerende nærrig når det kommer dertil. Dels fordi vi har gjort det til en vane, altid at låse efter os, både når vi kommer hjem eller forlader huset. Så en elektronisk lås vil i det tilfælde bare være ren li´r. Men også fordi jeg synes de er vanvittig dyre i forhold til hvad man får. Der er mig bekendt ikke engang en potentiale fri kontakt, som man i givet fald ville have kunne koble sammen med IHCén, og fx få den til at slå alarmen fra. Sidst men ikke mindst - Den funger kun delvist på en 3punkt lås, hvor man skal rive håndtaget op før man kan låse. Og når man alligevel skal gør det, så forsvinder hele ideen med en elektronisk lås, for så er vi tilbage til vores vaner (i mit hjem), at vi alligevel låser efter os hver gang.

Ja helt sikkert, at det er mere sikkert end IHC controlleren. Jeg synes bare du snakkede om på et tidspunkt, at du ville lave en slags VPN?

Det lyder mærkeligt. Sådan her ser det ud i min PaperUI. (bemærk den skriver 2.5M2 fordi jeg stadigvæk køre openhab 2.5M2).

Kan du godt, hvis du åbner porten for adgangen til IHC captain (dvs Rpién) på din router. Men Mikkel anbefaler det ikke, da der ikke er nogen ordentlig sikkerhed i det. Men Mikkel arbejder vist på det. Men hvis du selv laver en VPN så burde der ikke være noget galt i det.

Det her er den seneste .jar fil jeg kan finde af bindingen. Den er fra august 2019. https://openhab.jfrog.io/openhab/online-repo-milestone/2.5/org/openhab/addons/bundles/org.openhab.binding.ihc/2.5.0.M2/ Som sagt så bør du installere 2.5M4. Så behøver du ikke installer nogen binding manuelt.

Jeg kender kun til metoden med at bruge Rest API. Og der har det virket dengang jeg afprøvede det. Men til daglig bruger jeg manuelle oprettede items. Jeg har ikke tålmodighed til PaperUI, og slet ikke Rest API bare for at sætte tags. :-)

Du skyder bare løs.. Men lige en detalje.. hvis det er mere konkret for openhab, så bør du skrive i det område der er her specifikt for openhab. https://www.ihc-user.dk/forum/forums/forum/46-openhab/

Nix, Google Home håndtere fint æ, ø å. Men du må ikke bruge æ,ø,å i items navne i openhab2, hvis det er det du mener med "koekken". Her er et eksempel på en dimmer fra mit køkken: Dimmer koekken_underskablys_niv "Lyset under køkkenskabe [%.0f %%]" <light> (vLys) [ "Lighting" ] { channel="ihc:controller:elko:koekkenunderskab_dimmer", autoupdate="false" } I ovenstående eksempel siger jeg til Google, "Hey Google, tænd lyset under køkkenskabe". Og vupti, så tændes det :-) Ved ikke hvad version af openhab det er. Men hvis det er fornylig, så er det nok 2.4 stable. Som bozidar er inde på, så opgrader til 2.5M4. Den er bedre end 2.4 stable. I 2.5M4 behøver du ikke downloade .jar filen, for den ligger allerede under addons-> bindings i PaperUI.

Spændende produkter, Klaus. Og spændende det er direkte til modbus. Helt generelt, hvad er egentlig årsagen til, at de der Co2 målere de er så ekstremt dyre? Det er nærmest alle steder at prisen ligger i det leje.

Det er sgu lidt underligt, at "Nuværende setpunkt Rum" ikke virker i alle tilstande. Jeg bruger den avanceret varmestyringsblok 5.2.05.c. Der er en udgang der hedder "Rummets aktuelle setpunkt". Den virker i alle tilstande. Det er den jeg bruger. "Nuværende setpunkt Rum" i den funktionsblok du bruger, den burde gøre præcis det samme. Prøv med den avanceret. Det virker som sagt for mig, og setpunkt følger med, når man skifter tilstand, (beboet/ubeboet, dag/nat osv).

Wireless er max 64 enheder.. Det bliver hurtigt alt for lidt hvis du skal lave en større installation med det.

Det må der være, for jeg kan fint få det til at virke, hvad enten jeg beder Google Home om at ændre temperaturen til xx grader, eller jeg bruger Google Home appén. Setpunkt bliver ændret, og er den over aktuelle temperatur, så tændes telestaten: 2019-11-12 00:27:42.071 [ome.event.ItemCommandEvent] - Item 'kontor_Tempsetpunkt' received command 25 2019-11-12 00:27:43.282 [INFO ] [eclipse.smarthome.model.script.debug] - En telestat er åbnet ==> /var/log/openhab2/events.log <== 2019-11-12 00:27:43.290 [vent.ItemStateChangedEvent] - telestat5_kontor changed from OFF to ON Her er mine items fra mit kontor: (eksemplet herover) Group g_kontor_TSTAT "Kontor Thermostat" [ "Thermostat" ] Number kontor_Temperature "Kontor Temperatur[%.1f °C]" <cu_heating> (g_kontor_TSTAT,Temperatur,gTvaer,gSugeTemp) [ "CurrentTemperature" ] { channel="ihc:controller:elko:kontor_temperatur_fb" } Number kontor_Tempsetpunkt "Kontor Temperature setpunkt [%.1f °C]" <temperature> (g_kontor_TSTAT) [ "TargetTemperature" ] { channel="ihc:controller:elko:kontor_temperaturSet_fb", autoupdate="false" } Switch telestat5_kontor "Kontor Telestat [%s]" <cu_switch> (g_kontor_TSTAT,gTelestat) { channel="ihc:controller:elko:kontor_telestat" } Er du sikker på du har ramt den korrekte resourceID til dit setpunkt? ? Det vil du aldrig opdage i LK IHCremote app eller på Ipad´en. Det skal være resourceID fra funktionsblokken. Dit setpunkt må heller ikke være readonly i things settings. Den skal være readWrite. Lav et sitemap hvor du kan teste det i BasicUI.. Det er betydelig nemmere at teste tingene sådan. Så kan du samtidig følge med i tailog. Her er mit sitemap (igen fra kontor). Frame label="Varme" { Text item=kontor_Temperature Setpoint item=kontor_Tempsetpunkt minValue=18 maxValue=25 step=0.5 Text item=telestat5_kontor }

Jeg ser ikke mængden af kabler som et problem. Faktisk er det det som man bør tænke over, når man bygger, på samme måde som du ville gøre med en traditionel installation. At du skal tænke lidt mere over det i en "smarthome" installation. Det er bare sådan udviklingen er. Har man et problem med det, så bør man rådfører sig med nogen der har forstand på det. (Jeg ved det, de hænger ikke lige på træerne, men det er vel det ønske scenarie man bør stræbe efter). I øvrigt behøver du ikke trække 8 x 3x1.5mm2 bare fordi du har 8 outlets. Det kan altså også klares med 2 x 7x1.5mm2 og så bruge flere faser (mellemledninger) i hvert kabel. At gå wireless løsningen er efter min mening helt idiotisk og komplet unødigt, samt sandsynligvis også væsentlig fordyrende, hvis man alligevel er i gang med at bygge. Så ville det give langt mere mening at lave en installation, hvor du har decentrale moduler/komponenter. Det kræver selvfølgelig at bygningen er til dette. Skulle det så vise sig at man mangler en enkelt eller to, så har LK lavet wireless outlets (230v stik). https://www.yousave.dk/shop/stikkontakt-146c1.html Eller som mobile stik: https://www.yousave.dk/shop/mobil-stikkontakt-495c1.html Sidst men ikke mindst - Det er sandsynligvis de færreste der ligefrem har brug for så mange individuelle outlets i et rum. Jeg er kæmpe tilhænger af, at man trækker så mange kabler som man skal bruge, og gerne lidt flere, til et centralt sted, fordi er en massiv fleksibilitet, samt er enormt nemt at have med at gøre (overblik). Prisen på kabel kan/må ikke være afgørende for dette, for så er der noget rivende galt i budgettet. Min største bekymring ved denne metode er, at man hurtigt kan rende tør for moduler på een controller, og skal sandsynligvis ud i at bruge to/flere controllere, i større boliger. Det findes der selvfølgelig en løsning for, men jeg synes ikke den er speciel god, fordi den dels lægger beslag på antallet af input/output, samt at man skal programmere hver enkelt controller hver for sig. Det havde været at foretrække, at man kunne have nøjes med eet program.

Så længe skiftet er mellem 5 og 130 sekunder, så burde det virke. Det er ihvertfald sådan jeg forstod manualen.

Arrgh okay det er godt nok en irriterende situation at ryge ud i :-( Men godt du trodsalt fik det løst.