Lars1

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.

Denne del af dokumentationen er også tilgængelig via adminview.

Fejltilstand opstår sommetider når en HW 6.1 eller 6.2 controller crasher med firmware 2.7.220. Controlleren plejre at komme ud af fejltilstand når den bliver genstartet, enten via adminview eller ved at man tager strømmen til den. I fejltilstand kan man ikke uploade/download programmet, men såvidt jeg husker er det en anden fejl tekst man får, men det er efterhånden et par år siden jeg sidst oplevede det problem, så jeg er ikke 100% sikker.

Du kan godt føje mig til listen. Min HW 6.1 køre ganske fint efter jeg lagde 2.8.x firmwaren i den. Jeg vil dog ikke sige jeg er tilfreds med den, men det er jeg heller ikke med hverken HW 6.2 eller 7.

Såvidt jeg husker passer firmware 2.7.220 og Visual 2.7.349 godt sammen, men jeg har opgraderet til 2.8 for noget siden, så jeg er ikke 100% sikker. Prøv at genstarte controlleren før du forsøger at downloade/uploade programmet igen. Det løser sommetider problemet.

Det skyldes at antenne par'et er permanent parallel koblet til alle drop i IHC NET Basic boxen, så kortslutter du antenne parret i 1 vægudtag, er det kortsluttet i alle vægudtag. Det samme gælder tlf. par'et. Eneste forskel er at du kan vælge om et vægudtag skal være koblet på tlf. line 1 eller 2. Inden du køber en ny box, så få en lokal elektriker, som reklamer med IHC til at checke din installation. Det bør max koste 1 time. Han kan også skifte boxen for dig. Nogle er endda så flinke at de lader dig købe boxen på nettet i stedet for gennem dem.

Der er ikke nogen mulighed i IHC controlleren selv, men hvis IHC controlleren er tilsluttet dit netværk via en managed switch eller firewall, kan du højeste sandsynligt trace traffiken deri. Prøv at genstarte IHC controlleren. Det løser problemet hos mig når jeg har et tilsvarende problem. Det er nok at genstarte den via adminview.