-
Antal indlæg
3.308 -
Medlem siden
-
Senest besøgt
-
Days Won
39
Indholdstype
Profiler
Forummer
Downloads
Galleri
Alt der er opslået af Kandersen
-
IHC, M-bus, Nilan og DanTherm ventilation.
topic svarede på Kandersen's Lars1 i IHC - Generelle spørgsmål
Det er jeg også ved at finde ud af i OpenHab, men kan ikke lige få rrdj4 til at virke.. Vistnok en kendt fejl i OpenHab som "nogen" kæmper med. Vores Netamo i stuen siger 42,1% IHC målerne på badeværelserne siger 39,7% og 39,4% Nilan anlægget siger 38,4%. Det er en forskel jeg godt kan acceptere, specielt fordi Nilan anlægget ikke suger fra stuen. Altså jeg er kommet frem til, at dioden på panelet (LED 1), det er den som tænder, når spjældet er åbent. Reelt er jeg ret ligeglad med de 4 minutter spjældet åbner og lukker. Det vigtigste er at vide, om spjældet er åbent eller lukket. Men det kan være en god måde at evt finde fejl på. Så jeg tror bare jeg affinder mig med den konklusion -
My mistake, I missread your screendump
-
Pauli - Is it normal to create items as things? From you screendumps, it looks like you´re creating items (switch) as a thing?
-
Haha, ja det glemte jeg så lige i farten. Havde ellers siddet og lavet det Sgu da godt jeg gemte det i min dropbox, så jeg kan komme til den nu. Har i øvrig lige editeret i ovenstående items og sitemap og markeret de linjer røde, som er dem vi snakker om. Og så får du også lige screendump af hvordan sitemap ser ud i BasicUI. Edit igen.. Nu opdagede jeg lige, at jeg har faktisk lavet en fejl i min items fil i beskrivelse af trykkene. Jeg har byttet om på højre og venstre. Derfor ser det forkert ud i sitemap filen. Men fordi IHC IDén er rigtig, så er det kun rent visuelt at det har betydning. Apropos det med at jeg har linket trykkene, så er det endnu ikke noget jeg har besluttet mig for, om jeg vil gøre fast eller ej. Reelt set behøver man det ikke, da du kan påvirke dimmeren direkte enten i Fbén eller direkte på produkt-siden i Visual. Årsagen til jeg startede ud med at bruge trykkene, det var med den tanke, at hvis jeg en dag ikke gad OpenHab mere, så kan jeg bare slukke Rpién, og IHC controlleren kørere videre som om intet er sket. Men efterhånden som jeg er kommet dybere ind i OpenHab, så hælder jeg mere og mere til at slet ikke tage hensyn til IHC controlleren mere. Faktisk sad jeg den anden dag og overvejede at lave alt i OpenHab. Og IHC programmet bare vil indeholde produkterne. Dvs ingen Fbére overhovedet. Principielt kan man sagtens gøre det sådan. Men man skal tænke sig om, for hvad nu hvis.... Så er det godt at have et fungerende IHC program i baghånden, inden man springer ud i en fuldblods OpenHab løsning. JEg skal bare lige overbevise mig selv om det sidste, plus jeg skal lærer alt indgående i Openhab, specielt i forbindelse med rules.. Det er en hård omgang. Værs´go!
-
Pauli, what will happen if I add this to an already exsisting Openhab 2.2 with IHC controller installed? (my main installation)
-
Uni400 Dimmer ID adresse til Openhab. Her er først item filen for vores store badeværelse som pt køre halogen spot på en Uni400 dimmer IHC/SA. Bemærk, jeg tænder dimmeren ved at mappe selve trykket, "øverste højre på et 4-tast tryk". Status fra dimmeren hentes i højre side i Fbén under "Dimmer tændt". stortbad.items: //Stort Bad Number stort_bad_Temperature "Temperatur stort bad [%.1f °C]" <cu_heating> (Temperatur) [ "CurrentTemperature" ] {ihc="13699860"} Number stort_bad_Tempsetpunkt "Temperature setpunkt" <temperature> {ihc="7989780"} Number stort_bad_fugt "Fugtighed stort bad [%.1f %%]" <Humidity> (Fugtighed) ["TargetHumidity"] {ihc="13699623"} Switch stort_bad_OEV "Tryk øverste højre" <WallSwitch> ["lighting"] {ihc=">[ON:20058:100]", autoupdate="false"} Switch stort_bad_OEH "Tryk øverste venstre" <WallSwitch> ["lighting"] {ihc=">[ON:20314:100]", autoupdate="false"} Switch stort_bad_NV "Tryk nederste venstre" <WallSwitch> ["lighting"] {ihc=">[ON:20570:100]", autoupdate="false"} Switch stort_bad_NH "Tryk nederste højre" <WallSwitch> ["lighting"] {ihc=">[ON:20570:100]", autoupdate="false"} Switch stort_bad_halogenlys "Dimmer status" <light> ["lighting"] {ihc="5540626", autoupdate="false"} stortbad.sitemap: sitemap stortbad label="Stort Bad" { Frame label="Lys" { Switch item=stort_bad_OEH label="Halogenlys" mappings=[ON=Kip] Text item=stort_bad_halogenlys label="Halogenlys" } Frame label="Fugt, Varme & Ventilation" { Text item=stort_bad_fugt label="Relativ Fugtighed [%.1f %%]" // Text item=stort_bad_fugt label="Relativ Fugtighed" Text item=stort_bad_Temperature label="Temperaturen" Setpoint item=stort_bad_Tempsetpunkt minValue=18 maxValue=25 step=0.1 label="Juster varmen [%.1f °C]" Text item=telestat1_stort_bad label="Telestat [%s]" } Frame label="Ventilation" { Switch item=stort_bad_NV label="Tænd ventilation i 15 min" mappings=[ON=Kip] Text item=Nilan_Output_UserFunc Text item=nilan_output_ExhaustSpeed Text item=nilan_output_InletSpeed } }
-
This sounds incredible. I can test as well, Openhab 2.2, Openhabian on an Rpi3. Specially these days as I seem to get a strange error. OpenHab can read fine from the controller, but writing to the controller ends in a timeout error. This started a few days ago, and I have no idea why.
-
Bingo! Det var jo netop det jeg kunne se serviceview. Inkl i Openhab appén. Vil du vædde? Jeg ved det ikke endnu, men jeg har i sinde af forsøge det, når jeg får fundet det ekstra ø80 udtag frem jeg har liggende. Har efterhånden et mindre lager her på mit skrivebord (testbord) med strømforsyning, den gamle HW 6.1 controller, en Z-wave dimser, div tryk osv.. Mangler bare ø80 dimmer udtag (og lidt oprydning ).
-
Service view: Missing holiday file
question svarede på Kandersen's Jørgen Møllegaard i IHC Visual 3.0
Kalenderen virker på faste skematiske events, og i gældenden for hele boligens medlemmer/sammensætning. Afviger noget fra det planlagte, så skal kalenderen rettes til. Så er det op til den enkelte at afgøre, hvornår det passer ind. -
Tjekkede jeg ikke. Det ER en mulig fejl jeg skal kigge nærmere på næste gang. Ganske simpelt - Openhab sender værdi fra 0 til 100 direkte ind på IDén på fx niveauet. På lysindikering´s ID modtager OpenHab ON eller OFF. OpenHab kan reelt set også sende ON/OFF den anden vej. Det vil bare ikke give noget mening at sætte lysindikering ON, hvis lampeudtaget er slukket. Så det gør man selvfølgelig ikke. Det var mere for at forklare, hvor simpelt det reelt er.
-
Betyder denne, at du nu har styr på, hvis Controlleren har været genstartet? Jeg opdagede det forleden, i forbindelse med min fejlsøgning på et ø80 lampeudtag. Der endte jeg ud med at slukke controlleren (tage spændningen). Efter jeg havde gjort det, så havde IHC Captain ikke længere forbindelse, og fik heller ikke forbindelse igen. Da jeg gik ind i IHC captain i går, der stod den til "stoppet". Glemte at melde tilbage til dig..
-
Service view: Missing holiday file
question svarede på Kandersen's Jørgen Møllegaard i IHC Visual 3.0
Yep, men hvad hvis du under normale omstændigheder har unormal døgnrytme eller flere personer i hjemme operere på forskellige tidspunkter -
Hov, glemte at svar på denne.. Openhab operere direkte på de fysiske IDér som produkterne og dets funktioner har. Prøv at start Visual op, load dit program ind. Hold CTRL tasten inden, mens du holder musen over en eller anden funktion på et produkt (produkt siden). Så vil du se funktionens fysiske ID. Du kan gøre det samme i Fbérne hvis du vil det.. Hmm, nok nemmere at vise som screenshot.. Skal se om jeg kan hitte ud af det mens der er infomation på vinduet..
-
Det er faktisk lige præcis det jeg skriver. Lampeudtaget bliver påvirket. Dimmer Niveauet ændre sig i serviceview, Lydindikering går ON. De fysiske LEDére (lyset) tænder IKKE. <--- Dette ændre sig ikke på noget tidspunkt under forløbet. LYSET TÆNDER IKKE. Det er derfor jeg siger, at der må være tale om mindst 2 fejl.
-
IHC, M-bus, Nilan og DanTherm ventilation.
topic svarede på Kandersen's Lars1 i IHC - Generelle spørgsmål
Det vil jeg meget gerne låne.. Hmm ja, det mener jeg.. I det ene link ligger der en folder "Scripts" hvor der ligger noget phyton script i. Men det kræver jo du kender det.. Her er linket: https://github.com/starze/openhab2/tree/master/openhab2 Men du må ikke helt holde mig op på det. En anden bruger på openhab community guidede mig igennem, i denne tråd: (se indlæg 23 og efterfølgende): https://community.openhab.org/t/openhab1-2-nilan-heatpump/23538/23 Der forklarer NickMa mig, lidt om det. I øvrigt kan jeg sige, at jeg er ved at have gennemskue alle items osv, fra det der andet Openhab setup. Og pt har jeg en alen lang liste af respons fra Nilan anlægget, som jeg ikke anede jeg kunne få respons fra, inkl at konfigurere (sætte sommer/vinter grænse osv). Det eneste jeg pt ikke har fundet, det er hvordan jeg indstiller Uret. Det går nemlig 1 time og 12 minutter forkert. Udfordringen er at ikke rende ud i garagen og indstille det fra panelet.. Det er jo nærmest som at snyde nu Nåjo, en anden ting.. Ang det der Bypass (spjæld) sjov. Så har jeg også fået gennemskuet det.. Det er som der var en der tidligere sagde (husker ikke hvem). BypassOpen og BypassClose er OPEN i ca. 4 minutter. Og det er tiden hvor spjældet enten åbner eller lukker. Det mystiske er så, at Nilan ikke har en adresse for, hvad status spjældet reelt har. Der tror jeg omvendt, at man skal bruge LED1 (dioden). Hvis den er tændt, så er spjældet åbent. Men det er mystisk at man kan aflæse i panelet, at spjældet er åbent, men det er ikke som en selvstændig modbus adresse/register (eller hvad det nu end hedder). Jeg kan ihvertfald ikke finde den i Modbus vejledningen for anlægget. I går aftes forsøgte jeg mig så for første gang med at lave noget charts (rrd4j database) over det.. Det gik foreløbig ikke specielt godt. Så det sidder jeg og roder lidt med nu, indtil jeg nok opgiver. Det er såen en lidt side-ting som jeg gerne vil have, bare fordi man kan -
Service view: Missing holiday file
question svarede på Kandersen's Jørgen Møllegaard i IHC Visual 3.0
Nix, ikke med det forhold. Men jeg vil sige, det kommer nok meget an på, hvor fast en skematisk døgn/uge/måned/år rythme man har. Jo mere fast det er, desto mere taler for det du nævner. -
Det mener jeg du gør.. Se det her igen: Det fortælle mig, at når lampeudtaget er i slukket tilstand, så kommer IHC trykket igennem Fbén og aktivere det. Men IHC trykket kommet IKKE igennem anden gang, for at deaktivere det. Bemærk, lysindikering er ON. Dvs Fbén burde derfor vide, at lampeudtaget er tændt, hvilket jeg forstår er sikkerheden for at det er i sync. Jeg har et ekstra ø80 lampeudtag (dimmer) liggende. Og nu bliver jeg sgu lidt stædig Jeg har i sinde at afprøve det, for jeg er næsten 110% overbevist om, at jeg via Openhab kan styre lampeudtaget, uden at der overhovedet er en Fb indblandet på noget tidspunkt. Faktisk har jeg tænkt en del over det siden jeg skrev det tidligere. Jeg vil tro jeg reelt set kan strippe alt i højre side i Visual og lade Openhab påvirke samtlige produkter i venstre side, for på den måde at styre det hele via OpenHab.. Højre side er jo reelt kun beregnet til at styre logikken og dets hændelser i IHC controlleren. Men produkterne som skaber hændelserne, dem er jeg sikker på man kan styre netop ved hjælp af noget udefra, fordi hver enkelt produkt og dets funktion har en unik ID. Hvis min antagelse er korrekt. Så burde lampeudtaget have fungere forleden aften, (og det fysiske lys burde have reageret), uanset hvordan Fbén end opfører sig, da jeg via OpenHab påvirkede slideren (dimmer niveauet). Det var jo netop det jeg så skete i serviceview. Men det fysiske lys forblev som sagt slukket. Derfor antager jeg, at det er en selvstændig fejl i sig selv. Årsagen KAN muligvis være opstået via en Fb. Men jeg tvivler, hvis jeg skal være helt ærlig. Jeg tror mere det er noget logik styring i/omkring selve produktet (lampeudtaget) i controlleren, som er stoppet. Alle andre produkter virkede jo fint. Så det var ikke noget der havde generel forbindelse til fx den trådløse del. At IHC trykket ikke kunne deaktivere lampeudtaget, det er så den anden fejl. Og her kan det snildt være Fbén som er gået i baglås. Men det kan også være noget af logikken i IHC controlleren som også på denne del er gået i baglås. Jeg er ikke sikker på, at jeg vil kunne se det på Fbén, næsten gang det sker. Faktisk så den jo helt normal ud. Derfor tror jeg det er en lidt dead end.. Men det er helt klart noget jeg vil kigge nærmere på, næste gange det sker. Evt ved at prøve at udskifte Fbén som det eneste, hvis ikke der umiddelbart er noget at se.
-
Service view: Missing holiday file
question svarede på Kandersen's Jørgen Møllegaard i IHC Visual 3.0
Nej, det frygter jeg også lidt, uanset om det er IHC, Openhab eller andre systemer, så har jeg dælme svært ved at se lyset forenden af tunnelen Men på den anden side, når nu man også samtidig hygger sig med det, og det er blevet en slags hobby (nogle vil kalde det en besættelse), så sidder man heller ikke ligefrem og keder sig. Det eneste der er bekymrende, det er de for få irriterende 24 som døgnet rummer Helt enig. Problemerne opstår desværre bare, når en helligdag pludselig er en almindelig dag, fordi man står tidligt op, (man har en anden aftale).. Så skal man huske at korrigere for dette i sin kalender/sit program/whatever man nu engang har. Man kan selvfølgelig altid sige, at det sker så sjældent, så det er nemmere bare at lade det ske. Men pointen er jo netop at får sat alt i korrekt skema/kalender. Så tendens med at sige, "nåja" det er lidt et brud med princippet. -
Service view: Missing holiday file
question svarede på Kandersen's Jørgen Møllegaard i IHC Visual 3.0
Jo helt klart. Men vi mennesker har det jo med at glemme, specielt hvis der skal en manuel handling til. Det er lidt ærgerligt at tage til den anden ende af jorden, og så komme i tanke om, at huset køre på normal døgnrythme. Selvfølgelig ville det kunne klares, hvis man har adgang udefra. Men som Lars1 er inde på, så er det jo netop ikke sagen af rent sikkerhedsmæssig årsager. Derfor skal man, som du er inde på, ind og sætte denne start/stop dato et sted. Dette skal man huske. Lige så vel som man skal huske at aflyse aftaler i kalenderen, såfremt man bruger events til noget aktivt. -
Var netop det jeg gjorde. Forskellen på IHC trykket, Funktionsblok og og app/serviceview påvirkning af lampeudtaget! Der er ikke så mange andre muligheder her, selvom du virker som om du søger nogle helt specifikke, som jeg ikke lige kan få øje på. Du må meget gerne forklare mere detaljeret hvad du mener, fremfor blot at konstatere. Ikke enig. Men du må lige korrigere mig hvis jeg tager fejl. Er det ikke korrekt, at man kan styre et produkt (i det her tilfælde et wireless ø80 lampeudtag) direkte fra fx serviceview i venstre side? Altså helt uden brug af Funktionsblok? Hvis det er tilfælde, så er min konklusion helt korrekt. Der ER tale om mindst to fejl. 1. Forbindelsen mellem IHC tryk <-> Funktionsblok <-> Lampeudtag (produkt <-> Fb <-> produkt). Denne virkede delvist. 2. Direkte påvirkning af produktet, (lampeudtaget i venstre side), som virker, men fysisk lys reagere ikke. Om den ene fejl så er skyld i den anden opstår eller omvendt, det ved jeg ikke, og det kan jeg ikke umiddelbart se, hvordan jeg skal kunne komme frem til det.
-
Den første item er IDén på selve IHC trykket. Den anden items er IDén på "Dimmer status", i Funktionsblokken for dimmeren. Denne går ON, når du tænder dimmeren, (eller det gør den på en Uni400 dimmer. Jeg ved ikke om det er anderledes på en Uni350. Jeg tror ikke det er anderledes, da det vist er samme Funktionsblok for begge, og hedder vistnok noget med "fortrådet dæmper" eller lign. i Visual 2. Bemærk, jeg bruger Visual 2 og en HW .2 controller. Hvis du har behov for det, så kan jeg vise det mere præcist med et Screenshot fra Visual?
-
For mig fokusere du på flere ting her. Og når jeg læser det, så virker det som om, at du dels fejlsøger, men du vil samtidig finde årsagen til fejlen. Det kan man godt, hvis man har tiden og muligheden for det. Men hvis ikke man har det, så er man nødt til at behandle det i flere tempi. Ja, det involvere desværre, at man nogle gange må fjerne fejlen, uden at have fundet årsagen. Men sådan er det bare nødt til at være engang imellem. Næste gang det sker, så er jeg nået længere i fejlsøgningen og kan gribe det an derfra. Jeg behøver ikke koncentrere mig om, at produktet (lampeudtaget) reagere fint ved direkte påvirkning fra Openhab (udefra), men kan fokusere på, at der intet sker indefra (Fbén og controllerens styring) ved påvirkning fra IHC trykket. Men jeg kommer ikke uden om, at forsøge finde ud af, hvorfor lampeudtaget, som reagerede fint ved påvirkning udefra, alligevel ikke kunne tænde/slukke det fysiske lys. Det er helt klart en detalje som jeg mener er ret væsentlig her. Som nævnt, så er jeg overbevist om, at der er mindst to problemer (to ting er gået galt) i det her. Om de hænger sammen, det er nok kun LK der kan svare på det. I min verden burde de ikke hænge sammen. Men meget kan være gået galt inde bag al styringen i controlleren. Og meget af det får jeg nok aldrig mulighed for at kunne finde frem til, da jeg vil tro det kræver en debug log fra controllerens interne styringer og handlinger. Men jeg tror enten jeg har formuleret mig dårligt, eller du har misforstået mig. Så jeg prøver lige kort igen. Faktum Udgangspunkt (2. dagen, da jeg kom hjem fra arbejde) - Lampeudtaget (lyset) slukket OFF, der er ikke lys i lysindikering. Dette kunne jeg konstatere i Serviceview samt i Openhab appén: 1. Ved første påvirkning af IHC trykket - Lampeudtaget BLEV påvirket. Skyderen (slideren) bevæget sig op på 30% og Lysindikering gik ON. Dette blev konstateret i både ServiceView og Appén. 2. Ved næste påvirkning af IHC trykket - Lampeudtaget BLEV IKKE påvirket. Skyderen (slideren) forblev på 30% og Lysindikering forblev ON. Dette blev konstateret i både ServiceView og Appén. 3. Efterfølgende påvirkning fra IHC trykket ændrede ikke lampeudtaget på nogen måde. Ved påvirkning af skyderen (slideren) i appén. 4. Lampeudtaget BLEV påvirket hver gang, Lysindikering skiftede fra ON til OFF, alt afhængig af om slideren var i bund eller ej. 5. Ved at "slukke" lampeudtaget via Appén eller Serviceview, så kom jeg tilbage til udgangspunktet, og pkt 1. kunne nu gentages. Dvs IHC trykket kunne nu påvirke lampeudtaget, men kun een gang og til tænd. Derefter var jeg i pkt 3. igen. Det er derfor jeg skrev (og mener), at Fbén virkede delvist. Ellers burde IHC trykket jo slet ikke kunne aktivere (tænde, pkt 1) lampeudtaget. Og derfor jeg mener, at der er tale om mindst 2 fejl, fordi det fysiske lys ikke reagerede. I alle tilfælde reagerede det fysiske lys IKKE. Hvis nogen er i tvivl om, hvad jeg mener med appén så kommer her et billede, (godt ikke lige fra appén men fra Web interfacet BasicUi, som viser det samme som appén). Bemærk Spisebord. Det er denne skyder (slider) og pæren til højre for, som er koblet direkte sammen med lampeudtaget´s ID. Slideren styre niveau, og pæren Lysindikering. EDIT - Ahh I får også lige fra appén alligevel. Havde lidt problemer med screenshot på mobilen, så derfor jeg tog fra web interfacet.. Men nu lykkedes det. Så hermed tilføjet...
-
Service view: Missing holiday file
question svarede på Kandersen's Jørgen Møllegaard i IHC Visual 3.0
Ahh, nu bevæger du dig lidt ud over emnet med problemet for/imod lokal/cloud kalender samme/ikke samme kalender og styring af huset. Det du nævner er jeg helt enig med dig i, det bruger man ikke en kalender til. Nok er vi mennesker vanedyr, men vi er også fleksible på ofte mere eller mindre "frivillig" basis. Og det smadre hele ideen med at have et system styret af en kalender. Jeg kunne aldrig drømme om at lade min kalender styre huset på den måde. Problemerne du nævner, de ligger desværre dybt begravet i IHC, og har ligget der i årtier. IHC ved ikke og kommer aldrig til at vide, hvornår du er hjemme/ikke hjemme. LK´s bedste intentioner var, at give dig mulighed for at trykke på en knap, der så indstiller Driftformen i huset. Men udover det, så kan IHC ikke mere end det, (passer ikke helt, da til/frakobling af alarm også kan bruges, men pointen er relevant). Lige præcis den her del er noget jeg studere ret meget for tiden. Det var een af mine hovedårsager til at jeg valgte at bruge Openhab sammen med IHC. Jeg er stadigvæk langt fra mål, men foreløbig har jeg fået lavet det sådan: Openhab har 100% adgang til alt i IHC controlleren. <-- Vigtig deltalje, da resten ellers var ligegyldigt. Openhab har pt næsten styr på: Om der er nogen hjemme. og Hvis der er. Hvem der er hjemme. Der er stadigvæk visse huller og usikkerheder jeg skal have knækket, som bla skyldes, at det er banale og simple styring/overvågningsmetoder jeg bruger. Men jeg er ved at være ret tæt på. Foreløbig resultat sker vha af mobiltelefoner (WiFi), sensorer (Pir´s) og Alarm (IHC) til/frakobling. Og det har været uhyre nemt at nå hertil indtil videre. Nu kommer den svære del, bla med at fjerne mulige og allerede kendte usikkerheder, for dem er der en hel del af. Og de løses nok bedst ved at blande endnu flere mulige løsninger ind i det, fx kamera med ansigtsgenkendelse, som er noget jeg håber at kommer i gang med inden længe. Når/hvis jeg nogensinde bliver færdig, så vil der faktisk slet ikke der vil være behov for en kalender overhovedet. Huset vil udelukkende være fokuseret på personer i huset eller ej, uanset hvad kalenderen end synes der skal ske. Men jeg kan godt se en mulighed i at bruge en kalender i visse og meget faste og længerevarende perioder. Fx ferier olign. -
Well, Lars en gang imellem er den hjælpende hånd lige foran næsen på en. Serviceview har jo heldigvis en logværdi funktion. Og den brugte jeg, netop til at sikre mig, at det ikke var IHC trykket som drillede Men der er ingen tvivl om, at næste gang det sker, så skal fokus ligge på funktionsblokken. Jeg kan dog godt tvivle på, at jeg får noget egentligt resultat ud af det. Hvis funktionsblokken er "gået i stå", så er det sandsynligvis begrænset hvad man kan se, uanset hvor mange vi er om at trykke på knapper. Jeg er stadigvæk overbevist om, at når det her problem opstår, så er der flere ting som går galt i selve controlleren. Ellers burde lampeudtaget (fysisk lys tænde/slukke) jo have virket ved styring fra OpenHab, og/eller direkte fra Serviceview. Og det der sker i controlleren, det er ikke noget man bare lige kan se nogen steder. Her tror jeg mere en decideret debug log af controlleren kommandoer vil være et langt bedre værktøj. Jeg er dog ikke bekendt med, om man kan komme til sådan en, eller om den i det hele taget eksistere. Det er nok kun LK der ved det.