Lars1

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.

Da du var i serviceview, checkede du så status på lys indikering? Mit eneste bud på hvorfor du kan styre via openhab og ikke via den fysiske installation er hvis lys indikering af en eller anden grund er kommet ud af sync. Når du skruer op og ned via openhab, gør du det sikkert direkte på lampeudtaget, mens den fysiske installation går via FB'en.

Jeg kan finde masser af årsager til at styre huset med en kalender. Jeg kan bare ikke se at det giver mening at have disse events i samme kalender som fødselsdage etc. Jeg anker jo netop over at tanken om at bruge en google kalender til IHC fremfor en ordentlig lokal kalender funktion.

Det lyder umiddelbart som en overbelastet strømforsyning. Det kan også være en dårlig forbindelse, hvilket også kan være årsagen til at alarmen gik. Prøv evt. også og måle om du fortsat har 230V på indgangen til din 24V strømforsyning.

Jeg må sige at jeg har svært ved at se hvilke kalender events i min kalender, som kunne være relevante for min IHC installation. Dertil kommer at min primære kalender er min arbejdskalender, og min arbejdsgiver tillader ikke at vi sync'er vores arbejds kalender med goggle eller andre obskure public cloud services. Selv sync. med den indbyggede kalender i smartphones er blevet blokeret nu. Vi er nu tvunget til at bruge outlook kalenderen.

Prøv at downloade installations filen igen. Hvis det ikke hjælper, så uploade et screen shot af hvor installationen går i stå.

Nej. Jeg arbejder bare med bl.a. IT sikkerhed til dagligt, så for mig er det meget naturligt at have min egen FW med flere funktioner end de du kan få i en ISP router. At internet forbindelsen ryger fordi router og FW bliver uenig er en fejl, men eftersom jeg kender workarounden har det ikke høj prioritet at få den rettet. Når jeg er bortrejst har jeg alligevel ikke brug for internetforbindelsen. Det er jo bare en gentagelse af diskutionen om hvorvidt det er nemmer at lette røven og skrue op/ned for lyset via afbryderen på væggen eller logge ind på sin telefon, starte app'en og gøre det den vej. Personligt har jeg det sådan at alt IHC skal virke også selvom du er uden internet forbindelse.

Prøv at klikke på LK IHC Administrator, eller hvis det er rapporterne du vil have fat i, så klik på Online rapporter. Det er ikke forbudt at prøve sig frem. Man lære faktisk ganske ofte en hel del af det.

Nope. Routeren skal genstartes for at den kan reetabler internet forbindelsen. Det er forbindelsen mellem min firewall og routeren der er problemet, og jeg har opgivet at finde ud af hvorfor. Men bortset fra det vil jeg fortrække at calendar events ligger lokalt, fremfor i en offentlig kalender.

Jeg vil fortrække en kalender, som ikke er afhængig af en cloud service. Årsagen er at hvis jeg er ude og rejse, og internet forbindelsen ryger (sker desværre alt for tidt), så vil kalender funktionen ikke virke før jeg kommer hjem og kan genstarte ISP routeren.

Generelt er alt med datoer i LK IHC noget skrammel. Det var sikkert godt nok for 20 år siden, men idag forventer man fuld kalender funktionalitet, og det er ikke tilstedde i LK IHC. Desværre. Jeg har for snart 10 år siden lavet en kalender funktionalitet ala den som Henning beskriver, men droppede at opdater den på et tidspunkt med det resultat at huset en dag vi havde gæster, skiftede til bortrejst mode, fordi vi ramte tidspunktet for forrige års sommer ferie. Kalender FB'en er nu helt slettet, da selv default tidspunktet 1/1 00:00:00 er et aktivt tidspunkt, som system dato/tid = tidspunkt reager på.

Jeg synes der har været en del skriveri om problemer med helligdags funktionen i Visual 3 controlleren. Hvis jeg husker ret var der et tidligere indlæg, hvor det blev beskrevet at funktionen ikke virker ordentligt medmindre man også har aktiveret NTP, men jeg er ikke 100% sikker.