Lars1

Umiddelbart ser de ud til at være potential frie, men du er nød til at checke dokumentationen for at være sikker. Værd iøvrigt også opmærksom på at sålænge en IHC indgang er sluttet, så trækker den strøm. 3mA hvis det er et 24/3 input modul og 24mA hvis det er et 24/24 input modul. Ved 24V er det 0,72W eller 5,76W.

Er indikering af alarm - Røg forbundet til andre produkter/FB'er?

Hvis Sonoff relæerne har et potentialt frit kontakt sæt bør det ikke være noget problem. Hvis ikke skal du have overdragelses relæer mellem IHC input modulerne og Sonoff relæerne.

Tja. Der er vi jo så forskellige. Jeg vil fortrække at være hjemme, så jeg kan forsøge at slukke branden inden den æder hele huset.

Den udgang på alarm FB'en, som trikker e-mail'en er det den samme som tænder lyset og starter sirenen og sender entry til alarm loggen? Hvis ikke, er den udgang så linket til andet, som kunne være skyld i at der bliver sendt en alarm mail?

Der findes såvidt jeg husker ingen firmware 2.7.349, men der findes en Visual version 2.7.349. Der er firmware versionen i controlleren som er vigtig. Den finder du via adminview.

Du reager på et indlæg fra 2007. At linket ikke længere virker er vel meget naturligt.

Hvilken firmware version ligger der i controlleren? Det skal mindst være 2.7.220 såvidt jeg husker, ellers er fugt sensor ikke understøttet. Hvis det er den version, så prøv at genstarte controlleren inden du uploader programmet.

Hvis den anden FB ikke løser dit problem, kan du bare linke rum temperaturen på din temp. sensor til gulv temperaturen på FB'en og vælge gulv styring i FB'en.

Jeg kunne ikke lige finde et bedre fora til dette indlæg, så skyd mig ikke hvis mener indlægget er malplaceret. Dette er et rigtig godt eksempel på hvorfor cloud services er en rigtig dårlig ide til IHC installationer. https://www.dr.dk/nyheder/indland/danmarks-stoerste-sikkerhedsfirma-oplever-teknisk-nedbrud Det er IMHO ret grotesk at man ikke engang kan slå alarmen fra hvis forbindelsen til cloud servicen er nede.

Med den forklaring så bør du kunne se ændring i lysstyrken på lampeudtags produktet i serviceview, hvad enten lysstyrken rent faktisk ændre sig eller ej. Lys indikation tror jeg ikke du kan sætte via openhab. Den kommer fra de fysiske lampeudtag, og hvis din controller ikke kan kommuniker med lampeudtaget, vil lys indikationen ikke ændre sig selvom du sætter lysstyrken til 0% via FB'en eller openhab. I det mindste er det sådan jeg husker det da jeg sidst legede med de wireless dimmer. Det er relativt nemt at test. Prøv at sætte lysstyrken til f.eks. 50%, fjern strømmen til lampeudtaget, og prøv så at sætte lysstyrken til 0% og se hvad der sker. Når du tilslutter stømmen til lampe udtaget igen, så vil det tænde på de 50%, og du vil ikke se nogen ændring i serviceview før du selv ændre på lysstyrken. Lampe udtagne husker desværre det niveau de havde da strømmen røg, og der sker ingen tilbage melding når strømmen kommer tilbage. Det har snyt mig et par gange når der var gået en pære. Det sker selvfølgelig ALTID når de er tændt

Det kan kalenderen ikke tage højde for, men igen med kalenderen har du op til 80 dage om året hvor du på forhånd kan forudsige unormal døgnrythme, og der med på forhånd tilpasse husets tilstand, mens du uden kalenderen vil have 80 dage hvor du vil have en forsinket tilpassning af husets tilstand.

Blinker den blå diode på controlleren når du ændre på lysstyrken? Jeg ved godt hvordan man finder ID'erne, men det fortælle mig fortsat ikke hvordan openhab styre lyset.

Well. Alt efter hvornår helligdagene falder har du mellem 10 og 15 helligdage som falder på en hverdag. Læg dertil 5-6 ugers ferie. så ender du pludselig på 40-50 dage om året, som giver en unormal døgn rythme. Har du børn i skole alderen er der yderlig op til 30 dage. Alle samme dage som med fordel kan lægge i en kalender, så man kan forudsige unormal døgn rythme.

Jeg må indrømme at jeg kan ikke følge dine tests. Når du skriver at lampeudtaget bliver påvirket, er det så at lyset ændret sig, eller at du i service view kan se at lys styrken ændre sig i lampeudtags produktet? Nu bruger jeg ikke openhab, så jeg ved ikke hvordan den styre lampeudtag m.m. Men det ændre ikke ved at du via serviceview kan styre lampeudtaget manuelt og direkte uden brug af FB'en, men når du gør dette sker der en tilbage melding til FB. Hvis du f.eks. går fra 50% til 0%, så går lys indikering off. Om lysniveauet også bliver sendt tilbage til FB'en er jeg i tvivl om. Jeg bruger fortsat de gamle touch FB'er.

Så du vil heller have 20 dage om året som ikke passer med din døgn rythme end 1 dag som ikke passer?

Dette er jeg ikke enig. Den "kalender" funktion som findes i LK IHC idag er knap 20 år gammel. Den stammer fra en tid hvor time managers i fysisk form var mere normal en en online kalender på en computer eller en telefon. På det tidspunkt var LK IHC langt foran hvad mange kunne forstillig sig at bruge det til, men som med så meget andet i LK IHC har udviklingen desværre stået stille, så de idag er håbløst bagefter. En ægte nørd bliver aldrig færdig med at videre udvikle på sin IHC installation. Kalenderen bliver IMHO aldrig overflødig. Den skal som Lars Jakobson beskriver jo netop bruges til proaktivt at forudsige unormal opførsel, fremfor dit setup, som reaktivt reager på unormal opførsel. Med en kalender kan du f.eks. forudsige at det er helligdag i morgen, og derfor går du senere seng idag og står senere op i morgen. Natsænkningen kan dermed tilpasses dette. Det er lidt kedeligt først at hæve temperaturen i huset når du står op. Specielt på hverdage vil du ikke få gavn af den hævede temperatur før du tager afsted på arbejde, og så er det tid for at sænke temperaturen igen.

Jeg har muligvis overset noget, men såvidt jeg kan se så må jeg sige nej. I det senario hvor en påvirkning af trykket, ikke får lyset til at ændre sig har du ikke været nede og kigge på detaljerne, som om trykket når til FB'etc. Du har genbrugt konklusionerne fra det senario, hvor en påvirkning af trykket får lyset til at ændre sig, men eftersom slut resultet her er forskelligt, kan du ikke bare assume at det som virkede før også virker her. Som jeg plejre at sige til de IT arkitekter jeg har til at arbejde for mig på div. projekter. Assumptions are the mother of all f...ups. Der er ikke nødvendigvis tale om 2 fejl. Når du påvirker et lampeudtag direkte via serviceview, sker der en tilbagemelding til FB'en, og denne tilbagemelding kan ændre på hvordan FB'en reager når du næste gang påvirker trykket.

Hvis du ikke går systematisk frem og checker hvert led i kæden et efter et, så vil du lede efter en nål i en stor høstak. Det er meget nemmer at finde nålen hvis du kan fjerne halvdelen af hø stakken. Prøv at tænke på en juletræs kæde. Her sidder pærene i serie, og hvis en af dem springer holder hele kæden op med at lyse. Hvis du prøver at skifte dem en efter en, og gør dette ustruktureret tager det lang tid før du finder den som er sprunget. Hvis du der imod fjerner den miderster først, og måler om der er gennemgang fra midten og til stikket, kan du hurtigt udelukke halvdelen af lyskæden som en mulig fejl kilde. Herefter tager du igen den miderste pære i den halvdel som er fejl ramt. Sådan fortsætter du til du har lokaliseret den pære som er sprunget. Ved en lyskæde med 100 pære kan du finde den defekte pære med 7 tests eller mindre. Ved fejlsøgning er det mindst ligeså vigtigt at dokumenter hvad virker, som at dokumenter hvad ikke virker. Problemet med din fejlsøgnings metode er at dine tests kan påvirke resultatet af den næste test, fordi et flag i FB'en kan ændre sig selvom lyset ikke ændre sig. Tænk bare på alle de cases der har været hvor nogen har undret sig over at de skulle trykke 2 gange på en afbr. for at lyset tænder eller slukker. Samtlige jeg kan huske skyldes at første tryk bringer FB'en i sync med lyset, hvorefter andet tryk udføre den handling man forventede første tryk ville udføre.

Har du prøvet at kigge på LK's normale varmestyrings FB's? De har alle alarm for høj gulv temperatur såvidt jeg husker.

I min varme styring sænker jeg temperaturen i huset om natten, og mens jeg er på arbejde. Disse events giver det ikke mening at have i den private kalender. Når jeg tager på 2-3 dages forretnings rejser, sætter jeg huset i bortrejst mode, hvor der er lukket for vandet, temperaturen er sænket, alarmen slået til etc. 6 timer før jeg kommer hjem bliver temperaturen igen hævet. Jeg har en event i min kalender som notificer mig om hvornår jeg skal afsted til lufthavne, men ofte er jeg forsinket, og kommer ikke afsted til tiden. Der er ikke meget sjovt ved at huset skifter til bortrejst mode inden jeg er kommet af sted, så det sker først 1 time senere. Tilsvarende er der mange andre eksempler på at hus events ikke er linket 1-1 med personlige events, og det derfor ikke giver mening har have dem i den samme kalender som hurtig vil blive uoverskuelig hvis man skulle have dobbelt events for alt.

For at finde root cause, er første step at udelukke fejl kilder. Det gøres bedst ved systematisk at følge flowet i programmet. F.eks. når du påvirker et tryk, bliver dette så overført til indgangen på FB'en? Hvis påvirkningen bliver overført til FB'en, er det ikke trykket som er problemet, og du kan kigge på om der sker nogen ændring i FB'en? Hvis ikke må du ned i programmet og kigge om der er nogle flag som bloker for ændringer af lysstyrken. Når du styre lys niveauet via openhab, bliver det så reflekteret tilbage til FB'en? Når du har fundet ud af præcis hvor i flowet at kæden hopper af, kan du fokuser din fejlsøgning om dette. Og tror mig. Langt de fleste fejl jeg har fundet i egne og andres IHC programmer skyldes et flag som ikke stod som forventet. En hard reset af controlleren nulstiller ofte disse flag. En soft reset via adminview, beholder ofte status. Log funktionen er god, men du skal så logge alle ind og udgange på FB'en og tilsluttede produkter (både tryk og lampeudtag) samt alle interne variabler i FB'en. Gør man det kan loggen hurtig blive uoverskuelig.

Hvis det går galt igen, må du være lidt mere grundig i dine test. Det kan være besværligt hvis man er alene, men jeg har tidligere fundet fejl i mit program ved at kigge på ind/udgange i FB's og produkter via serviceview samtidig med at en anden påvirkede tryk m.m. Det er den eneste måde jeg umiddelbart kender til hvor man kan finde ud af hvor kæden er knækket.

Også er vi tilbage til at det ikke giver mening at have IHC events i sin normale kalender.

Problemet med at bruge samme event til både IHC kalenderen og den private kalender, er at start og slut tidspunktet ofte ikke vil være det samme. Hvis man f.eks. skal på ferie, ønsker man jo ikke at huset går i ferie mode før man er taget af sted. Ligesom man jo gerne vil have at det er varmt/nedkølet når man kommer hjem.