Kandersen

Er der nogen der kender Salus´s selv-balancerende telestater? https://salus-controls.com/dk/product/selvbalancerende-telestat-24v-gulvvarmesystem/

Med den firmwaren han bruger, (som jeg formoder i virkelig er 2.8.4) så burde Java ikke være problemet.

Korrekt. Man kan godt "tale til" Hubén og få svar. (Det er Assistenten). Men rent grafisk melder den at mode ikke er understøttet.

Se det fra den lyse side - Nu ved du hvordan man ikke skal gøre Det er hammerende irriterende, specielt at ingen kan svare på hvorfor. Der burde ikke være forskel, men Google laver det åbenbart ikke ens. Det skal nok lykkes på et tidspunkt, når ham der laver Google integrationen kommer i gang igen. Så håber jeg at jeg i det mindste kan få at vide, hvorfor og hvor problemet ligger og evt løses.

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

Ja, når/hvis den kommer. Men det ændre jo ikke på udfordringerne med LED og specielt stribes. Det er unægtelig bedre. Men det er ikke sådan så træerne vokser ind i himlen med ø80 dimmerne. Der er stadigvæk problemer med visse LED kilder. Og specielt lav volt, så er man rigtig udfordret.

Henning, hvorfor skal det være en wireless dimmer (løsning 2) ? Det giver da absolut ingen mening i et "møbel" som det der vises, medmindre man er ovre i noget natsænkning. En UNI400 dæmper / anden type DIN dæmper der bare skal have en puls og som kan indstilles til 2 niveauer styret af ur, vil da være langt mere korrekt, så længe man forholder sig til minimum niveauet for dæmperen. Jeg er enig i at LED stripes i siderne (som lyser ind i skabet) er klart at foretrække fremfor lys der lyser ovenfra og ned på en hylde, (som i øvrig vil skygge for resten af skabet). Men så skal man tænke sig ret godt om hvis man vælger dæmper løsningen, også med en wireless ø80 dæmper. LED med dæmper er ikke nemt. LED stripes med dæmper er endnu værre. Måske man i stedet skal tænke i noget 1-10volt styring så. Det er en noget dyrere løsning, men skulle efter sigende virke langt mere effektivt.

I både 1. og 2. skal der vel bruges en kontakt.. Det gælder vel også alle andre muligheder. Du kan ikke overvåge en låge/port/dør/vindue uden een eller anden form for kontakt på. Så en kontakt skal der til. Det burde være muligt at finde en låge/skab kontakt der virker til sådan noget. Fx sådan en her: https://www.wattoo.dk/elartikler/diverse/skabsafbrydere Mht om lyset skal tænde sammen med andet lys, på en dimmer, så er det selvfølgelig muligt. Men medmindre det er dæmpbar lys i skabet, så mener jeg bare du skal køre det på en alm 230v udgang. Derfra kan du under alle omstændigheder kode dig frem til, om det skal tænde sammen med andet eller ikke.

You dont TAG things. TAG goes into the items

@Pauli Anttila, would it be possible to get a link to the latest .jar file of the binding?

"på det kraftigeste...." er en finurlig måde at udtrykke det på. Ser man på LK´s hjemmeside, så står der: IHC Controller FW (CTR.R.03.03.23) Kritisk opdatering Øger system stabiliteten Bevars, der står kritisk opdatering. Men at ligefrem kalde det for "på det kraftigste" uden yderligere forklaring, det er sgu for tyndt! Det jo lidt et paradox. Brugerne oplever at deres controller "dør" ved opdatering af firmware. Men det anbefales på det kraftigste at opdatere firmwaren. Det burde resultere i en noget tydeligere forklaring.

Du kan bruge ServiceView i IHC. Der kan du se og logge alt hvad der foregår i IHC controlleren, (on/off osv). Men jeg er lidt forvirret. Du skriver du kører udelukkende med Wireless enheder. Hvordan har du så koblet relæet på IHC installationen? Og hvad formål har relæet? Min formodning er, at det er i openhab der opstår et problem. Så hvis du kan vise item/channel opsætning, og ikke mindst din regel, så vil det være en god hjælp.

Sker det også hvis du kobler openhab fra? Du siger det er en KIP, men du bruger ikke pulsewidth?

Nicolai, den linie du efterlyser, den står lige oppe over, som du svare til, at det ingen ændringer giver.

Hvilken version var det du brugte af bindingen?

Husk at "lukke den af" med: { Channels: } Dvs: ihc:controller:elko [ hostname="192.168.1.2", username="openhab", password="secret", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: }

Prøv at slet linket på selve lampeudtaget (mener det er B knappen nede i mindst 5 sekunder). Og prøv derefter at link det igen i Visual.

Btw.. I forbindelse med bla TAG til brug for Google Assistant, så kan jeg se at dokumentationen endelig er blevet opdateret. Den findes her: https://www.openhab.org/docs/ecosystem/google-assistant/

Jeg har faktisk vist det en del gange efterhånden, (måske har det være i en anden tråd). Og der findes også en rimelig god vejledning fra Pauli her: https://www.openhab.org/addons/bindings/ihc/ Men vi kan godt prøve at tage det lidt mere slavisk (og på dansk): Det første du skal, det er at forstå filerne og meningen med filerne. Dvs hvad er things og hvad er items. Der er en nogenlunde brugbar forklaring (grafisk vist) her: https://www.openhab.org/docs/concepts/ En thing kan så bestå af flere channels (det er her hvor jeg mener ovenstående er alt for overfladisk i sin forklaring). En channel i IHC er fx en ResourceID. Denne er unik, ligesom den også er i Visual. Via IHC bindingen, kan openhab så "snakke" sammen med IHC controlleren om, hvordan status/værdi på en Channel er. Hvis det fx er en temperatur føler. Så kan IHC bindingen få oplysninger fra IHC controlleren om, hvad status er på temperatur føleren. Med en temperatur føler, så er det en "ReadOnly" channel, da det ikke giver meget mening at "Write" en værdi til IHC controlleren for en temperatur føler. Dvs først og fremmest, så skal vi skabe forbindelsen mellem openhab og IHC controlleren. Det er en absolut forudsætning for, at der overhovedet kan kommunikeres. Den vender jeg lige tilbage til, før vi skal lige have en yderst vigtig detalje på plads først, når vi snakker om at arbejde med tekst baseret konfigurationsfiler. Filerne SKAL hedde noget helt bestemt til ´efternavn´. Og de SKAL placeres i deres respektive foldere. (fornavn bestemmer du selv) fx: ihc.things SKAL hedde .things til efternavn. Og den SKAL placeres i things folderen. ihc.items SKAL hedde .items til efternavn. Og den SKAL placeres i items folderen. Der er desværre mange som laver den klassiske fejl, at deres filer kommer til at hedde ihc.things.txt eller ihc.items.txt - Det virker ikke! Tilbage til forbindelsen. Forbindelsen skabes som det første i .things filen, fx som ved denne linie: ihc:controller:elko [ hostname="192.168.1.2", username="openhab", password="secret", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] ihc:controller:elko er "navnet" på controlleren. Jeg anbefaler du beholder ihc:controller:(selv valg, i dette tilfælde elko. Du kunne også kalde den for :mincontroller). Men hvis vi holder os til eksemplet, så er controlleren benævnt: ihc:controller:elko Det næste er så parametrene til forbindelsen. hostname er obligatorisk og den skal henvise til IP nummeret for din controller. Derfor står der ="192.168.1.2". Hvis din controller har et andet IP nummer på dit netværk, så skal du selvfølgelig skrive det. Derefter kommer username og password. Det er brugernavn og adgangskode til din IHC controller. Og ligesom med hostname skal du skifte det der står i " ", så det passer til din controller. Så er der timeout. Den giver sig selv. Det er den tid som controller og openhab forventer at få svar på forespørgelse ved kommunikationen. I det konkrete tilfælde står den til 5000ms. Det er muligt du skal sætte den op til fx 80000. Ellers kan du opleve du ind imellem får fejl i kommunikationen. loadProjectFile fortæller om IHC bindingen skal loade Visual programmet. Egentlig forstår jeg ikke meningen med det, for hvorfor skulle man ikke.. Men lad den stå til true. createChannelsAutomatically er også selvsigende. Hvis den står til true, så betyder det at bindningen vil læse ALLE produkterne i Visual programmet fra IHC controlleren, og automatisk laves channels ud fra dem. Her er det vigtigt at vide, at hvis man vil bruge de automatiske channels, så vil der være nogle ting man ikke kan. Fx kan man ikke bruge pulseWidth, hvilket er en forudsætning for, at en KIP funktion i IHC kommer til at virke korrekt. Men omvendt kan man bruge de automatiske channels til at se resourceID på de channels man selv vil lave. Så derfor anbefaler jeg, at man sætter createChannelsAutomatically=true. Alle parametrene pakkes ind i [ ] som vist i eksemplet. Og filen skal, (fordi den også skal være klar til channels), "lukkes af" med {Channels: } Dvs en things fil med forbindelse og UDEN manuelle channels ser således ud: ihc:controller:elko [ hostname="192.168.1.2", username="openhab", password="secret", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: } Det er det der skal til for at skabe forbindelsen mellem openhab og IHC controlleren. Hvis IHC bindingen er installeret i openhab. Så vil du i PaperUI - Configuration - Things kunne se, at der ligger en IHC Elko thing. Hvis du klikker på den, så vil du også kunne se alle de automatiske channels. Herfra kan du så vælge om du vil gå videre med de automatisk channels, eller om du vil lave dem manuelt. (HUSK hvad jeg skrev omkring pulseWidth. Du kan ikke rette i en automatisk channel og indsætte pulseWidth i parameter, da den ikke bliver gemt i en automatisk channel). Du kan vælge at laves manuelle channels ved at klikke på +. Eller du kan vælge at lave channels i din .things fil. Jeg anbefaler .things filen. Så tilbage i din ihc.things fil: Som skrevet tidligere, så er en channel i iHC det samme som ResourceID. Dvs når du skal lave en channel, så skal den henvise til resourceID fra Visual funktion. Det kan være et tryk, en fb eller hvad du nu end vælger det skal være. Her er et eksempel: Type switch : my_test_switch "My Test Switch" [ resourceId=3988827 ] Det første er Type switch. Det fortæller hvad for en slags channel det er tale om. Det er fx et IHC tryk. Det næste er yderst vigtigt : my_test_switch er navnet på denne channel, som skal bruges når du linker den til en item senere. Her kan man med fordel bruge noget der giver mening. Forsøg dog at holde det kortfattet. navnet er unikt og kan derfor ikke genbruges i andre channels. Bagefter kommer en label "My Test Switch" Denne label er ikke synlig andre steder, og er blot ment som en information til dig om, hvad navnet på channel (my_test_switch) dækker over. Til sidst har vi [ resourceId=3988827 ] Dette er selve linket til resourceID i Visual programmet. Det er også her man kan indsætte channel parametrene fx den famøse pulseWidth jeg har nævnt et par gange. For at forstå denne linje/channel på en nem måde, så læses den baglæns: IHC ResourceID er nu linket til channel (navnet) my_test_switch som er af typen switch. I .things filen skal denne manuelle channel så indsættes således: ihc:controller:elko [ hostname="192.168.1.2", username="openhab", password="secret", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: Type switch : my_test_switch "My Test Switch" [ resourceId=3988827 ] } Og så skal det læses som: ResourceID 3988827 er nu linket til channel-navnet my_test_switch med label "My Test Switch" som er af Type switch til IHC controller på IP 192.168.1.2 som hedder elko. Så simpelt er det faktisk at lave en manuel channel. Og hvis vi tager den famøse pulseWidth med. Så ser det hele sådan her ud: ihc:controller:elko [ hostname="192.168.1.2", username="openhab", password="secret", timeout=5000, loadProjectFile=true, createChannelsAutomatically=false ] { Channels: Type switch : my_test_switch "My Test Switch" [ resourceId=3988827, pulseWidth=300 ] Type number : my_temp_sensor1 "Min temperatursensor1" [ resourceId=2898765, direction="ReadOnly" ] } Dette er opsætning af forbindelsen til en IHC controller, hvor en manuel channel er linket til ReourceID på et IHC tryk. PulsWidth sørger for at sætte channel i OFF 300ms sekunder efter den har været i ON. Ligesom når du har trykket på trykket og sluppet trykket igen. Det er derfor pulseWidth er en forudsætning for, at en KIP funktion i IHC kan virke fra openhab. Uden pulseWidth, så vil item forblive ON i openhab, og den er derfor ikke i synk med selve trykket mere. Bemærk, jeg har lavet 2 manuelle kanaler, jeg har nemlig også lavet en kanal til en temperatur sensor. Bemærk lighed og forskellene. (Type, navn og resourceID). ITEMS! For at bruge en Channel til noget brugbart (aflæse værdierne eller betjene en switch) i openhab, så linker man en item til denne channel. En switch er en ON/OFF, og en temperatur sensor er et nummer(tal). items skal også bruge en type.. Vi starter med at oprette et tomt dokument som vi kalder for ihc.items. Denne skal ligge i items folderen: Jeg har i ovenstående lavet to manuelle channels, så derfor laver jeg også to manuelle items. De ser således ud: Switch test_switch "Test Switch" { channel="ihc:controller:elko:my_test_switch" } Number temp_sensor1 "Temperatur sensor 1" { channel="ihc:controller:elko:my_temp_sensor1" } Det første er typen Switch. Det fortæller openhab, at denne item er af Switch typen. Det næste er en label "Test Switch". Denne vises i sitemap (BasicUI) og er brugbar på mange måder. Det er derfor en label der skal afspejle, hvad er det vi har med at gøre. Det sidste er her "magien" kommer ind. { channel="ihc:controller:elko:my_test_switch" } Det er her man skaber selve linket til sin channel. Bemærk sammensætningen i det. Den består netop af IHC controller navnet "ihc:controller:elko" samt navnet på den channel vi netop lavede :my_test_switch Igen kan man med fordel læse det bagfra. IHC channel my_test_switch er linket til item test_switch af typen Switch som har label "Test Switch". På samme måde med den temperatursensor jeg sætte ind. type er Number itemnavn er temp_sensor1 label er "Temperatur sensor 1" linket er Number test_number "Test Number" altså { channel="ihc:controller:elko:my_test_number" } Håber det giver lidt mere mening nu.

Det er svært at lave billeder af tekst filer, og giver ikke ret meget mening fremfor at bare skrive teksten Min opfattelse er, at hvis man tager det et skridt ad gangen, så hænger det hurtigt fast. Og når man så har styr på det første skridt, så er de næste skridt nærmest gabende kedelige (nemme), og resultatet er omvendt imponerende. Når du har lavet din første things, så vil den være synlig i PaperUI - Configuration - Things. Når du har lavet din første items, så vil den være synlig i PaperUI - Configuration - Items. Når både things og items er lavet, så vil du kunne se det i PaperUI - Control. Herfra kan du godt styre/betjene det, men det er anbefales ikke. Det er mere ment som et administrator overblik over, hvilke things (med items) som er installeret. I stedet skal du overveje hvor du evt vil hen med de things/items du laver. Personligt laver jeg sitemaps til alle funktioner (items), fordi det er nemmere at overskue i sitemap fremfor i PaperUI - Control. Men det betyder så også, at man liiige skal forholde sig til endnu en tekst fil (.sitemap). Jeg bruger kun BasicUI som overblik. (Jeg kan godt bejtene derfra, men bruger det yderst sjældent). Min plan som jeg arbejder ud fra er, at ALT skal over på en rigtig grafisk brugerflade, hvor jeg kan monitorer hele huset. Min plan er IKKE, at man skal kunne tænde/slukke/betjene noget fra denne brugerflade. Min ideelle plan er, at alt som evt kan/skal kunne betjenes, det foregår via IHC trykkene (som normalt) OG som stemmestyring. Det er det mål jeg har med det openhab/smarthome system. Fx har jeg de sidste par dage brugt lidt tid på at få mine solcelle inverterer over i openhab (via modbus). I basicUI ser det foreløbig sådan her ud: Dette er bare et hurtigt setup i en sitemap fil. Og på den måde kan jeg lyn hurtigt se de forskellige funktioner (items) at de virker som de skal, eller hvis de ikke gør. På et tidspunkt flyttes det så over i en "endelig" grafiske brugerflade, som opbygges i en grafisk .SVG (vektor) fil, som foreløbig ser således ud (meget rå, men giver en ide om, hvilken retning jeg har valgt). De to grønne "knapper" nederst til venstre aktiver/dekativere forskellige informationer på skærmen. (PIR og Klima foreløbig). Det er den ENESTE form for aktivitet der kommer til at være med brugerfladen, (der kommer selvfølgelig flere muligheder). Og de vil kunne aktiveres/deaktiveres med stemmen. Så hvis jeg fx siger, "hey Google, sluk PIR", så fjernes de fra skærmen, og knappen skifter til rød. Det der underlige grafiske nede i venstre halvdel, det er de foreløbige forsøg på et integrere mit Nilan anlæg grafisk.. Det er ikke helt heldigt endnu. Men ventilatorene er animeret og drejer rundt. Det er meget sjovt at se på, synes jeg. Alle de der PIR sensorer (personen i en grå cirkel) de skifter til rød når der er bevægelse. Alle døre/vinduer/garage port med "grønne bjælker" skifter til rød, når de åbnes/er åbne, (der mangler dog en del sensorer endnu, men de kommer). De orange "kasser" er mine ovenlys vinduer, der viser hvor mange procent de er åbne. Alle lys/lamper er påført, og tænder (skifter til gul), når lyset tænder. Det er den foreløbige rå plan/oversigt med mit mål. Meningen er at denne "skærm" skal være monitor og være placeret et centralt sted i huset, så man hele tiden kan få et overblik over, hvordan husets tilstand er. Der er langt endnu, men det går støt og roligt fremad. Så måske en dag når jeg skal på pension, så kan jeg sidde og nyde det færdige resultatet.. (Det kommer ikke til at ske, fordi hele det her smart home halløj, det ændre sig konstant. Men så har jeg også lidt at pille med til den tid ). PS. Forvent ikke alt for gode svar fra min side på, hvordan det her SVG (grafisk skærm) laves.. Lige så sikker jeg føler jeg er på at opsætte openhab, lige så usikker er jeg på det her. Og rent grafisk er jeg bare en kæmpe kegle.. Så jeg kæmper mig frem ved brug af InkScape, som jeg med jævne mellemrum sidder og bander og svovler over, og tit er tæt på at opgive.. Men jeg giver mig ikke uden kamp

Søgte lige på openhab community.. Det er åbenbart ikke uden udfordringer med tail log på en windows. Så meget desto bedre grund til ikke at bruge openhab på windows Addons er jo noget af det bedste ved openhab. Meeen, det er også dem der er forbandede skyld i at man bruger enorme mængde timer på det

Det er betydelig nemmere på en Rpi/Linux. Selvom jeg ikke er linux mand, og aldrig bliver det, så husker jeg windows versionen som en noget broget affære.

På en Rpi kører den ip:9001 (hvis man har aktiveret den i openhabian-config). Jeg er lidt på herrens mark med windows. Det er simpelthen for længe siden jeg har testet det. Prøv at se hvad der sker hvis du browser http://ip:9001 (ip er din openhab server). Den kan også startes fra Karaf, men kan ikke huske hvordan.. Hmm..

Hmm troede de havde fået udnerstøttelse for det i openhab 2.5 M3. Men det er nok udskudt til openhab 3.0

Det er også enormt vanskeligt ind imellem. Så jeg kan godt forstå man kan blive forvirreret. Godt så.. Så laver du ikke den fejl igen, (lige med det samme) PS. Et godt tip (selvom det er elendigt mht Google Assistant i openhab). Når i sidder og roder med noget, så er det en god ide at have tail loggen kørende i et browser vindue. Der bliver man oftest klar over med det samme, hvis der er noget galt et sted.