Kandersen

Smart at linke på den måde? Jeg forstår slet ikke det skulle være nødvendigt.. Den er jo fortrådet, og ikke trådløs.. Hvorfor skal den så linkes?

Enig, men min erfaring siger mig, der er ikke nødvendigvis sammenhæng mellem listepris og udsalgspriser. Men det vil helt klart være rart om den blev billigere. Måske kunne det endda også motivere mig til at skifte controller, (selvom det reelt er et dårligt argument). Det er faktisk meget godt tænkt med den kanal synkronisering. Men ja, det er nok kun i meget store installationer (erhverv olign.) det bliver aktuelt. Jeg lurede på om det ville være nemmere at dæmpe 12volt (trafo) med den dæmper. Det er lidt dyrt at indkøbe som forsøg (controller + dæmper), bare for at konstatere, det ikke ændre noget.

Ca. 1800,- inkl moms. (mit gæt). Det er ca 2 x ø80 og så lige lidt mere. Btw. Hvad er kanal synkronisering til i Visual for dæmperen?

Velbekomme.. Ja men openhab´sk er ikke altid nemt Lige pt er jeg ved at prøve at lave en software baseret rollershutter.. Det er dælme ikke nemt, når man ikke har helt styr på de rules altid

Måske en dimbob kan løse dit problem. Eller nogle af de der såkaldt LED støjkondensatorer. https://www.greenline.dk/search?charset=utf-8&q=+Støjkondensator

Jeg mangler endnu at finde en 24" iPad (eller 32", når/hvis det lykkes mig at få integreret video overvågning) Du har for sin vis ret. Problemet er bare, at iPad (og en del andre tablets) er vanvittig langsomme til mit formål, (Jeg har allerede en ældre iPad som jeg også tester med). Og hvis det skal være en rigtig god og hurtig tablet, tja så er prisen igen derefter.

Men det er nok mere et valg fra LK end det er en teknisk begrænsning i de ældre controllere.

Helt enig. Jeg forstår det heller ikke. Men jeg tror det har noget med udbud & efterspørgsel at gøre. Det er svært at "mase" en Rpi ned til 5-7mm Men der findes altså rimelige løsninger som ser relativ godt ud, hvis man altså kan leve med nogle få cm "kasse". Jeg går selv med tankerne om at splitte en 24" skærm/TV ad, og tage selve indmaden/skærmen ud, skrue den i en ramme, og så montere en RPI i forbindelse med den. Hvis man har mulighed for det, så kan man evt hakke et hul i væggen, hvor en tilpas dåse inkl Rpi/kabler kan være i. Det eneste der pt forhindre det for mig er, at den løsning jeg har i tankerne, der er Rpi3B+ ikke god nok, (Linux browser op imod openhab med habpanel). Og jeg har ikke besluttet mig for, om jeg vil bruge min Odroid C2 eller indkøbe en ny Rpi4 til formålet. Se evt denne video, og forstil dig man fjerne hele rammen så man kun har indmaden. Der findes også mere "smarte" løsninger, som desværre involvere Magic Mirror, som ikke er formålet med det du efterlyser. Men metoden kan være med til at give nogle ideér. Alternativ er at trække et langt HDMI kabel (og evt. strøm) som trækkes til et andet sted, hvor Rpién(PC)/strøm er placeret, (fx på loftet).

Korrekt. På fuldstændig samme måde som du skriver herover. Dvs du skal bruge en ledning mere. Men det lader også til du har flere løse ledninger liggende i dåsen. Så derfor skal du have en ekstra indgang. Mener faktisk der er en rimelig god vejledning med, netop til hvordan du forbinder den til IHC.

Lige et follow up på termostat her, så har jeg netop stillet spørgsmålstegn ved, om den måde det er lavet på i openhab integration 2.0, om det ikke er principielt forkert, eller rettere, at der mangler en "Switch" type option.. Jeg mener, at "HeatingCoolingMode" principielt burde kunne sættes ud fra hvad telestatens status. (det kunne også være et varmelegme, gasflamme eller lign). Men fordi telestaten er en Switch type, så mangler der simpelthen den mulighed i GA integrationen. Det ville ihvertfald løse vores problemer, for os der bruger gulvvarme systemer. Se mere her: https://community.openhab.org/t/openhab-google-assistant-integration-v2-0/85573/69 EDIT: Ovenstående indlæg fra openhab community har jeg netop opdateret, da jeg testede det princip som jeg stillede spørgsmålstegn ved hjælp af en rule. Og det virker helt som forventede, og som det skal.. Ved at bruge String for HeatingCoolingMode, så kan man ved hjælp af en rule skifte Mode, ud fra om telestaten er tændt (ON) eller slukket (OFF). Og jeg mener helt principielt at det er sådan det også skal være, hvorfor jeg fastholder, at vi mangler en Switch type. Med den Switch type, så behøver man nemlig slet ikke at bruge en rule for at få Google Home app til at reagere/vise korrekt. Er nogen i tvivl, så er her et eksempel på, hvordan jeg har lavet det: items 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) [ "homekit:TargetTemperature" ] { channel="ihc:controller:elko:stortbad_temperaturSet_fb", autoupdate="false" } Number stort_bad_fugt "Stort Bad Fugtighed [%.0f %%]" <Humidity> (g_Stortbad_TSTAT,Fugtighed,gHumidityBathRoom) [ "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,gTelestat) { channel="ihc:controller:elko:stortbad_telestat" } Og her er rules rule "heatingmode" 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 Når/hvis vi får en Switch type til HeatingCoolingMode, så behøver man ikke hverken den String eller en rules mere, da telestaten direkte kan aggere targetHeatingCoolingMode. Jeg satser stærkt på, at Michael kan se det fornuftige i dette, og vi inden længe får en Switch type til [ "homekit:targetHeatingCoolingMode" ]

Nok noget i retning af 2 x ø80 dimmer, 'and then some'.

Ja beklager at jeg ikke fik skrevet her, at det er blevet opdateret og skal ændres for at virke. Det var ellers min plan, men jeg fik travlt med andet.. Jeg har selv døjet med det siden sidste weekend hvor google integrationen blev opdateret til V2.0.. Jeg kan ikke ligefrem sige jeg er pænt tilfreds med resultatet af den nye opdatering, fordi den har ødelagt en del af det gamle setup.. Bla virker dimmere nu ikke længere som dimmere i iPhones Google Home app.. De virker som on/off Hvor har du det fra, at værdien skal være =1 (spørger fordi jeg forsøger hjælpe Michel krug med at fejlrette dette). Jeg mener nemlig det er helt forkert den måde de nu har lavet det på.. Og hvor præcis er det så du har linket til, backup modul 24V er lidt som en nål i en høstak Edit - Jeg har løst problemet her, ved at bruge String to qHeatingCoolingMode.

Jeg har ikke selv erfaring med det, (endnu). Men det findes som Android tablet. https://www.alibaba.com/showroom/wall-mount-android-tablet-poe.html https://www.digiverse.co.uk/product/10-android-multi-touch-commercial-tablet-with-poe/ https://www.amazon.de/AllNet-25-7cm-Display-Tablet-PoE/dp/B0757KX8QL/ref=olp_product_details?_encoding=UTF8&me= https://www.amazon.de/dp/B074S1GM6K/ref=pd_sbs_107_t_2/258-6993576-1231047?_encoding=UTF8&pd_rd_i=B074S1GM6K&pd_rd_r=dd76e783-2158-4265-8a3c-7ebd0faf2acd&pd_rd_w=PkyqY&pd_rd_wg=mt1ub&pf_rd_p=a2f6bca6-dcb1-4822-8e28-66b64b37970e&pf_rd_r=6AGE87KQGZ5JGQ9N3THG&psc=1&refRID=6AGE87KQGZ5JGQ9N3THG Men de er pænt dyre, så der skal virkelig være tungtvejende argumenter for det, efter min mening.

The Visual manual show how to. (dont recall what page though). You´ll need to program each controlleres individually.

Pkt. 2 og 3 kan jeg nikke genkendende til. Er sket flere gange netop med wireless ø80 dæmper. Man lærer at ikke trykke flere gange meget hurtigt efter hinanden på trykket Alle mine wireless dæmpere sidder ca. 0.5cm - 1m fra antennen. Så jeg har ingen problemer med signal.

Ikke kun din side. Jeg har også haft mine besvær med at forstå hans dokumentation.. Det er lidt hagen ved disse mennesker som udvikler til openhab. Rigtig mange af dem er sindsyg gode til at udvikle, men det der med dokumentation, der halter tingene ofte.. Meningen er så også, at det der med dokumentation, det skal vi alle helst hjælpe til med. Men det er dælme svært at gøre, hvis man ikke fatter hvad det er udvikleren skriver og har lavet. Du generer bare løs....

Det er fair nok at de fortæller at IHC controlleren sagtens kan køre sammen med andet, selvom det nok har været en svær kamel at sluge for dem, da de jo har sagt det modsatte i flere år, og faktisk direkte frarådet det :-) Men jeg tror ikke vi skal forvente at se dem gøre noget for det. De kan jo læne sig tilbage og lade andre gøre det for dem.

Nej selvfølgelig ikke. Så får de jo ikke solgt den "nye" controller. Men lad os nu se når/hvis den nye dæmper engang kommer.. Den er nok så simpel, så den styres med modbus, (ville være mest logisk med et RS485 interface).. Så behøver vi, der fx køre openhab/home-assistant, slet ikke den nye controller til det

Hvis man sætter lamper op, men ikke har kabel, så tænker jeg man er ovre i noget med batteri og/eller solceller. Trådløs strøm er vist endnu en fremtidssag. (Sagt på en anden måde - Jeg forstår ikke helt, hvad det er du vil ud fra din tegning).

Kender det alt for godt! Når jeg engang imellem opgradere openhab, så gør jeg altid det, at jeg lader den gøre hele opgraderingen færdig så den starter op første gang. (jeg holder øje i tail log). Og når den mere eller mindre har fået alt med, så lukker jeg openhab ned, og rebooter. Jeg har simpelthen for mange gange prøvet det der med, at enten tålmodigheden ikke lige holdt, eller at noget er gået galt under første opstart. Så jeg har vænnet mig til at genstarte efter hver opgradering.

Mja.. Jeg ved ikke hvad version du bruger. Men hvis du begiver dig ud i at lave dem i filer, og du før havde dem i PaperUI, så skal du huske at fjerne dem i PaperUI. Det er kun den absolut seneste version som kan "håndtere" begge dele med samme serielnummer. Anyway.. Din fil herover er lidt svær at tyde. Det ser ud som om det er et screendump fra VSC.. Det er nemmere, hvis du markere det hele og indsætter det her i et indlæg ved at bruge den der knap <> i menuen herover. Og så paster/kopiere du bare det hele ind i boksen der kommer frem.. En god ide når man gør det på denne måde med manuelle filer, det er at holde det til een ting ad gangen. Først få things things til at virke. Når de virker, så kan du se dem online i PaperUI. Der er absolut ingen grund til at rode med items, hvis things ikke er online. Ligesom det heller ikke giver mening at sidde og lave sitemaps, hvis items ikke virker. Man risikere at man sidder og roder i 117 ting på een gang. Derfor tager jeg altid et punkt ad gangen. Så: Først Bridge (i dette tilfælde fordi der er en Brigde). Den skal vise ONLINE i PaperUI. Dernæst things. Disse skal også vise online i PaperUI. Så items. Hold øje med loggen. Og til sidst sitemaps. Igen hold øje med loggen. Det gør det også nemmere at hjælpe, når man fx ved, at Bride og Things er ONLINE, men items ikke virker, (hvis det var det). Dit opsæt: I din things fil herover ser det ud til du mangler en } som afslutter dine things. Det er muligvis en paste fejl. Og ellers burde den brokke sig i loggen, og things burde ikke være online. Men din items er nok her den rigtige synder er. Alt afhængig af hvilken version of KLF bindingen du bruger, så har du ikke defineret dem rigtigt. Se fx mine things og items her: Bridge velux:klf200:home [ ipAddress="10.4.28.252", tcpPort=51200, password="secret" ] { // Velux IO-homecontrol devices Thing actuator VindueTh01 [ serial="56:08:1D:26:06:29:06:C7",inverted=true ] Thing actuator VindueTh02 [ serial="56:08:1D:26:06:30:0A:CD",inverted=true ] Thing actuator VindueTh03 [ serial="56:08:1D:26:06:29:12:03",inverted=true ] Thing actuator VindueTh04 [ serial="56:08:1D:26:06:29:08:7B",inverted=true ] Thing actuator VindueTh05 [ serial="56:08:1D:26:06:29:14:5B",inverted=true ] Thing actuator VindueTh06 [ serial="56:08:1D:26:06:30:0C:A1",inverted=true ] Thing actuator VindueTh07 [ serial="56:08:1D:26:06:29:0D:0D",inverted=true ] Thing actuator VindueTh08 [ serial="56:08:1D:26:06:29:14:5C",inverted=true ] } Rollershutter Vindue01 "Vindue stue syd-øst 1 [%d]" [ "Blinds" ] { channel="velux:actuator:home:VindueTh01:position", autoupdate="false" } Rollershutter Vindue02 "Vindue spisestue øst 2 [%d]" [ "Blinds" ] { channel="velux:actuator:home:VindueTh02:position", autoupdate="false" } Rollershutter Vindue03 "Vindue stue nord-øst 3 [%d]" [ "Blinds" ] { channel="velux:actuator:home:VindueTh03:position", autoupdate="false" } Rollershutter Vindue04 "Vindue køkken syd-øst 4 [%d]" [ "Blinds" ] { channel="velux:actuator:home:VindueTh04:position", autoupdate="false" } Rollershutter Vindue05 "Vindue stue syd-vest 5 [%d]" [ "Blinds" ] { channel="velux:actuator:home:VindueTh05:position", autoupdate="false" } Rollershutter Vindue06 "Vindue spisestue vest 6 [%d]" [ "Blinds" ] { channel="velux:actuator:home:VindueTh06:position", autoupdate="false" } Rollershutter Vindue07 "Vindue 1 [%d]" [ "Blinds" ] { channel="velux:actuator:home:VindueTh07:position", autoupdate="false" } Rollershutter Vindue08 "Vindue stue nord-vest 8 [%d]" [ "Blinds" ] { channel="velux:actuator:home:VindueTh08:position", autoupdate="false" } Den nemmeste måde at ramme item link til channel korrekt i items, det er simpelthen ved at klippe den direkte fra PaperUI. Specielt med KLF bindingen, fordi ham der laver den bytter rundt på navnene, og det er møg forvirrende.. Derfor gør jeg altid det, at jeg opretter things i filen og sikre mig de er online. Derefter går jeg ind i paperUI og tager "stien" til channel.. Se dette screendump fra PaperUI: Når du klikke på den som pilen peger på, så kopieres stien til clipboard.. Og så kan du bare indsætte/paste det direkte ind imellem " " i { channel="velux:actuator:home:VindueTh01:position" } Sådan, ikke så meget pjat i det. Og chancen for at skrive forkert (manuelt indtastet) er minimalt :-)

Kun hvis Windows ikke har den i forvejen :-D

Hmm det var egentlig den løsning jeg ikke håbede på. Det er jo lidt underligt, at man skal installere en USB (netkort) driver, i et OS, der allerede har en USB driver. Og helt generelt, jo mindre "ekstra unødig" software man kan undgå at skulle installere, jo mere simpelt er det, og jo flere kan "være med".

Hvad skriver man så i stedet for IP:port adresse? Jeg formoder den skal vide hvilken USB port controlleren er forbundet til?

Naah, kun 2K og 4K. Venter lidt endnu med 8K :-) Det er samme opløsning, når jeg bruger LK´s java programmer. Skal prøve at lave to screenshots i aften. Bare husk, det er en meget lille detalje, og bestemt ikke noget jeg ikke kan leve med. Det er nok mest af alt vanen som spiller ind her. Anyway - Kom til at tænke på, om du har tænkt dig at lave USB support også? Der er jo en del som slås med, at de heller ikke kan få forbindelse via USB. I så fald vil du have klaret alles problemer, som LK ikke har formået.