Lars1

Jeg er ikke 100% sikker på hvad du forsøger at lave, men LK IHC wireless ver. 1 dimmer og lampeudtag virker kun hvis min. belastningen er opfyldt. Dvs. Du kan ikke bruge en ver. 1 dimmer som tryk, medmindre min. belastningen på dimmeren er opfyldt. Hvis du ikke har ret meget LK IHC wireless og ikke har nogen LK IHC controller, vil jeg ikke bruge penge på LK IHC wireless. Så vil jeg isteddet kigge på zwave. Det kan LANGT mere end wiser.

En gateway er integration til andre produkter som f.eks. IHC captain, OpenHAB etc. Hvis ikke du vil være afhængig af andre produkter til program afvikling, så er det en ny controller du forsøger at lave fremfor en gateway. Det vil selvfølgelig være MEGET interessant, men det er voldsomt mere komplekst end en gateway.

Det er RIGTIGT mange år siden jeg sidst rodede med en TermIHC controller, så min hukommelse på det område er langt fra den bedste. Jeg mener dog at Putty burde være ganske fin til formålet. I din fejlsøgning kan du prøve at checke nedenstående punkter. Verificer at det er en TermIHC controller du har og ikke en Visual 1 controller. De 2 controller ligner hinanden RIGTIGT meget, så brug evt. denne guide. https://www.ihc-user.dk/forum/forums/topic/11132-hvilken-controller-har-jeg/ Check at du bruger de rigtige parameter m.m. til controlleren. Kig evt. på https://www.lk.dk/professionel/support/varktojer/download-software/. Såvidt jeg husker er der under TermIHC en oversigt over baud rate m.m. Jeg kan aldrig huske om TermIHC og Visual 1 controller brugte RS232 eller nul-modem kabel. Forskellen på de 2 er at RX og TX er krydset i nul-modem, mens de er lige igennem i RS232. Men det står muligvis også på SW download siden.

Din idee om en gateway er langt fra ny. Jeg har samlet en oversigt over de forsøg jeg har kendskab til i bunden af mit indlæg i denne tråd. https://www.ihc-user.dk/forum/forums/topic/10812-hvad-er-alternativerne-til-lk-ihc/ Som du kan se er nogen af dem nået lidt længere end dig, men alle, bortset fra den sidste, er stoppet seneste da de skulle til at lave gateway API'et. Dernæst vil jeg sige at bekymringen for at controlleren står af deler jeg ikke. Controlleren har vist sig at være MEGET stabil. Det som plejre at stå af er strømforsyningen eller wireless enheder. Resten synes at være RIGTIGT holdbart. Hvis controlleren endeligt skulle stå af, så har LK jo lovet at de kan reparer en Visual 3 controller nogle år frem. Der går endda rygter om en ny firmware der skulle fikse problemet med LED dimmer og scenarier. Derudover kan man sikkert finde en brugt visual 2 controller hvis det går helt galt. Personligt så jeg gerne en gateway, med et standard inteface som f.eks. modbus eller andet som kan bruges via f.eks. OpenHAB, men sandsynligheden for at jeg erstatter min IHC installation med kip relæer når den ikke længere virker, er større end at jeg kaster mig ud i en gateway og OpenHAB eller tilsvarende.

Det er egentligt et spørgsmål du bør stille til den elektriker som skal erstatte dit kiprelæ med wireless. Men hvis du bare vil undersøge marked, så er LK IHC wireless et rigtigt dårligt valg, da det udgår efterhånden som eksisterende lager bliver solgt. LK stoppede udviklingen af LK IHC for mange år siden og stoppede produktionen i August 2023. Det som bliver solgt i webshops m.m. idag er restlageret. En liste over mulige alternativer til LK IHC findes i denne tråd. https://www.ihc-user.dk/forum/forums/topic/10812-hvad-er-alternativerne-til-lk-ihc/

Du skal hente softwaren til Visual 2 på LK's website (https://www.lk.dk/professionel/support/varktojer/download-software/). Du kan ikke bruge hverken Visual 3 software eller firmware sammen med en HW 6.2 controller.

Når man leder efter fejl på netværk, er det ofte ganske banale fejl som er skyld i problemerne. Derfor er det vigtigt at gå systematisk til værks. Jeg tvivler på at det er fiberboksen som var problemet. Det har nok nærmer været en dårlig forbindelse i LK IHC controller porten eller kablet. Men godt at det kom til at virke.

Og så længe det er tilfældet er det spild af tid at rode med app's på mobil devices. Som minimum skal du have adgang til LK IHC controllerens forside via en browser på din PC eller mobil enhed, før du begynder at rode med app's m.m. Det er den mest simple konfiguration, og så længe den ikke virker, virker de mere komplekse ting næppe heller. Hvor i din router ser du din LK IHC controller? At den kun optræder sommetider, kan meget vel være problemet. Jeg har fornylig set enkelte billige switche og router, som kun understøtter 1Gbit. Problemet er så at LK IHC kun understøtter 100Mbit, så prøv at se om din router kan konfigureres til kun at køre 100Mbit fuld duplex på den port hvor LK IHC controlleren er tilsluttet. Hvis din varmestyring også kun køre 100Mbit, kan du prøvet at bytte de 2 kabler hvis det er muligt. Bare for at udelukke at det er et defekt kabel eller en defekt router port som giver problemerne. Hvis du har en switch liggende, som du ved understøtter 100Mbit, kan du også prøve at sætte den mellem din router og din LK IHC controller.

Hvis du ikke kan nå din LK IHC controller fra din PC via dit lokal net, er der stor sandsynlighed for at du heller ikke kan via app's m.m. Derfor. Fokuser på at få din PC til at virke først. Den er nemmer at fejlsøge på end en app på en mobil tlf. Netværks opsætning på LK IHC er lidt gammeldags, men hvis man ved hvad man gør er det ikke så svært. Det kræver kun relativ banal netværks forståelse, samt at man ikke bare prøver sig frem og ændre ting i blinde, eller ændre flere ting samtidig. Hvis du har ændret sikkert port på LK IHC controlleren tilbage til 443, den har IP adr. 192.168.1.5, og din router opsætning er som i dine sidste screenshots, så bør du nu kunne nå LK IHC controlleren fra din PC på følgende måder. URL i browser http://192.168.1.5 eller bare 192.168.1.5. Dette bør give dig forsiden på din LK IHC controller. https://192.168.1.5 bør give dig en sikkerheds advarsel hvis du bruger firefox som browser. Hvis du aksepter advarsel bør du få en lyserød siden med en 403 forbidden meddelse. Via visual med 192.168.1.5 port 443 eller 192.168.1.5:443 som kontakt informationer, alt efter hvor du ser dem i Visual Via serviceview eller adminview med 192.168.1.5 port 443 eller 192.168.1.5:443 som kontakt informationer, alt efter hvor du ser dem i Visual Før end en af 3 ovenstående metoder virker, er det spild af tid at rode med app's på mobil enheder. Er dit netværk iøvrigt kablet eller wireless? Hvis begge dele. Hvad er kablet og hvad er wireless forbundet til din router?

Du har efterhånden lavet så mange ændringer at det kan være en god idee at prøve at genstarte alt, incl. router og LK IHC controller. Det kan sommetider være en fordel at genstarte routeren først og sikre at den køre før du genstarter LK IHC controlleren. Når alt er genstartet, så check at alt er konfigureret korrekt, jvf. det jeg har skrevet i tidligere indlæg. Hvis det fortsat ikke virker, så upload venligst screenshots af LK IHC controllerens konfiguration, ipconfig fra din PC, samt routerens IP konfiguration, samt evt. routerens arp, mac address eller DHCP lease tabel, hvis du har adgang til den.

Jeg vil anbefale at du ændre LK IHC controllerens IP tilbage til 192.168.1.3. Så slipper du for at skulle ændre noget i LK IHC Visual m.m. Med DHCP range .10-.100 og routerens default GW på .1, har du .2-.9 som du kan bruge som statiske addresser til LK IHC controller, printer m.m. Webport er http. Normalt port 80. Sikker port er https normalt port 443. Du kan f.eks. starte LK IHC Visual og se at du har forbindelse til controlleren, eller du kan åbne serviceview eller adminview via netværket i steddet for USB. Der er ingen grund til at rode med port forward før det er på plads. Du bør også gå ind i controllerens tids menu og verificer at den kan nå tids serveren før du begynder at rode med port forward.

Hvad mener du med dette? Hvis det er default gateway du har ændret, skal du ændre det tilbage til .1 Det eneste du skulle ændre i dit router screen shot var IP address range som skulle ændres fra 192.168.1.2 - 192.168.1.254 til f.eks. 192.168.1.10 - 192.168.1.100. Alt andet var korrekt. DNS er ikke så kritisk. Det eneste LK iHC controlleren bruger DNS til er når den skal slå NTP (tids serverne) IP addressen op, samt når den skal hente opdaterede helligdages informationer. Du vil dog få et mere rent setup ved at ændre LK IHC controllerens DNS til det samme som din router har. Du har ikke brug for port forward for at få adgang til LK IHC controllerne hvis du kun bruger din PC og IHC remote på dit lokal net. Direkte adgang fra internet er ikke noget som anbefales, og det kræver at du har fast IP. Men hvis du ønsker det, skal du forwarde den HTTPS port som er konfigureret i IHC remote til at pege på port 443 på din LK IHC controller, samt HTTP porten til port 80 på LK IHC controlleren. Men inden du begynder på dette skal du sikre dig at du kan nå din LK IHC controller fra din PC via dit lokal net.

Jeg har endnu aldrig mødt en ISP router, hvor man ikke selv kan ændre DHCP scopet, men jeg har på de anden side heller aldrig før mødt en ISP router, hvor DHCP scopet bruger samtlige IP addresser i lokal nettet. Men hvis du ændre DHCP scopet, så det ikke inkluder den IP som din LK IHC controller bruger, så bør det virke. Default gateway, subnet størrelse m.m. er korrekt. Det er kun DHCP scopet som ikke passer med IP konfigurationen på din LK IHC controller.

.255 er en broadcast addresse hvis lokal nettet er et /24 netværk. Den kan ikke bruges som IP til din LK IHC controller. Jeg har aldrig før set en ISP router bruge hele lokal nettet som DHCP range. Normalt bruger den max halvdelen, således at man kan give printer m.m. en fast IP. Spørgsmålet er derfor om lokal nettet er større end et /24 netvæk. F.eks. et /23. I såfald skal du både ændre størrelsen på lokalnettet og DHCP ranges for at du kan kommuniker med din LK IHC controller. Men det kan vi hurtigt afgøre hvis du lægger et screenshot op af din routeres lokal net konfiguration. Grunden til at størrelsen på lokal nettet også skal passe sammen, er at ellers kan LK IHC controlleren ikke beregne den korrekt broadcast addresse (192.168.1.255 jvf. LK IHC controllerens IP konfiguration) Din router skal have følgende lokal net konfiguration for at den funger med LK IHC controlleren. Lokal net 192.168.1.0/24 (subnet maske 255.255.255.0) Default GW 192.168.1.1 DHCP range 192.168.1.32 - 192.168.1.254 (kan være alt mellem .4 og .254, men giv god plads til statiske addresser ved at bruge .32 som start addresse)

Du skal checke at LK IHC controlleren IP er på samme subnet som lokal nettet på routeren. Nogle ISP'er bruger som default 192.168.0.0/24 som lokal net, mens andre bruger 192.168.1.0/24, hvilket også er det subnet hvor din IHC controller befinder sig. Læg evt. et screenshot af routeren lokal net konfiguration op her. Derudover skal du checke at LK IHC controlleren IP addresse IKKE er i det DHCP range som din router bruger. LK IHC controlleren understøtter IKKE DHCP. Hvis ovenstående ikke er korrekt, er det nemmeste at rettet routeren til, så den passer med din LK IHC controller. Når der er skabt forbindelse til din LK IHC controller via netværk fra din PC, kan du begynder at kigge på NAT og forward regler i firewallen i routeren, således at du også kan nå din LK IHC controller fra din mobil.

Jeg har for lidt data til at jeg kan sige om rækkefølgen har noget at sige. Efter ændringen så tilbagemeldingen kommer efter indstillingen, har jeg som skrevet kun set problemet 1 gang på 3 uger, mens jeg så problemet 2 gange på 2 uger før ændringen. Det kunne jo tyde på at det har noget at sige, men problemet er på den anden side opstået så sjældent at det ligeså godt kan være en tilfældighed. Hvordan får man fat i den test firmware?

Efter at jeg har ændret rækkefølgende så er problemet med at eb enkelt dimmer ikke slukker om morgen kun opstået en enkelt gang. Jeg kan dog ikke sige om det også opstår når styrken skal skrues op på 100%. Jeg har kun monitorering af aktuel lysstyrke via OpenHAB. Det vil være noget omstændigt at skulle lave en log på om den forventede lysstyrke er den samme som den reelle lysstyrke. Siden ændringen til styring via lys niveau har jeg dog ikke set at lyset er forblevet på 100% ret meget længere end det burde. Har du hørt noget nyt om hvornår LK vil frigive en ny firmware som skulle løse scenarie problemet? Måske den også kan løse de lys niveau problem jeg er løbet ind i.

LK IHC wireless enheder kan kun kommuniker med andre LK IHC wireless enheder, herunder også LK IHC controller såfremt denne er Visual 2 eller 3. Selvom Schneider sælger både LK IHC wireless og Wiser, kan de 2 produkter IKKE kommuniker med hinanden. De baser sig på 2 forskellige wireless standarder. Det der endnu ikke er udgået fra LK IHC wireless produkt kataloget finder du her https://www.lk.dk/produkter?iid=159 Alternativer til LK IHC incl. wireless kan du finde i denne tråd. https://www.ihc-user.dk/forum/forums/topic/10812-ihc-eol-hvad-er-alternativerne/

Den eneste grund jeg kan se til at du skal ændre tiderne er hvis du bor i den anden side af landet i forhold til de sol op/nedgangs tider som er brugt i det virtuelle skumrings relæ. Solen står op/går ned ca. 25 min. før på Bornholm end i Esbjerg. Du kan finde de præcise sol op/nedgangs tider for din addresse her. https://soltider.dk/

Det er længe siden jeg brugte de virtuelle skumrings relæ, men såvidt jeg husker tændte lyset somregl fortidligt og slukkede forsent i forhold til hvad der er optimalt. Selv om sommeren, hvor problemet er størst grundet en længere sol op/nedgang, var det max 15-30 min. Fysisk skumrings relæ eller lux måler er heller ikke uden problemer. De kan blive påvirket hvis en bil lyser direkte på dem, eller når der er spredte skyer i sol op/nedgangs tiden, samt at en indstilling som passer om vinteren passer ikke nødvendigvis om sommeren grundet den længere tid sol op/nedgangs tid. Et fysisk skumrings relæ har derudover ofte den udfordring at hvis man vil stille på dem skal man have fat i en stige. En LK IHC lux måler kan justeres via LK IHC programmet. Men selvom jeg har et delay på 5 min. på ændringer på min lux måler, sker det ind i mellem at lyset tænder og slukker igen et par gange i sol op/nedgangs tiden. Dette skyldes somregl at en sky går for solen, og kan ikke 100% undgåes. Hvis jeg gøre delayet længere, eller ændre niveauet for hvornår lyset skal slukke eller tænde, får jeg problemer med at lyset tændes eller slukkes forsent. Dette problem er særligt slemt om vinteren, grundet den korte sol op/nedgangs tid. Og om vinteren er det tidspunkt hvor hvor der er mest brug for lyset. Jeg kunne selvfølgelig lave forskellige delays og lys niveaus for sommer og vinter, men det er ærligt talt at skyde gråspurve med kanoner, for et problem som optræder 2-3 gange pr. mdr (ekstra tænd/sluk) eller at lyset tænder/slukker 15 min. fortidligt/sent om sommeren. Bottom line. Om du bruger et virtuelt skumrings relæ, fysisk skumrings relæ eller lux måler gør ikke den store forskel. Du vil altid opleve at lyset på et eller andet tidspunkt i løbet af året tænder/slukker 15-30 min. fortidligt/sent i forhold til hvad der vil være det optimale. De er dog alle MEGET mere præciset end manuel tænding og slukning af lyset. Edit: Jeg tjekkede lige loggen på min lux måler. Om sommeren ændre lys niveauet sig max 75 lux i løbet af 1 time før eller efter at det rammer 0 lux første gang. Om vinteren ændre lys niveauet sig mindst 100 lux og helt op til 500 lux i samme periode. Tilgengæld peaker lys niveauet om vinteren på 300-5.000 lux, mens det om sommeren peaker mellem 3.000-20.000 lux.

Du bliver nød til at komme med lidt flere oplysninger, som f.eks. hvilken IHC controller har du, hvor ser du fejl koden m.m.

IHC controlleren har aldrig haft brug for internet adgang for at hente opdateringer. Dem har du altid skulle hente ned på din egen PC og uploade via firmware uploadere installaret på din egen PC. Du bør dog give IHC controlleren DNS og NTP adgang, således at den kan opdater uret. Ellers risiker du at tiden skrider og går helt skævt efter en genstart.

Jeg kender ikke den pågældende FB, men normalt vil det være sådan at en tidsbestemt event kun trigges på det tidspunkt den er sat til. I dette tilfælde vil det sige at eventet ignorer sol nede, kun trigges præcist kl. 20.01.00. Det giver nogle udfordringer når man simuler program afviklingen, da eventet ikke bliver trigget hvis man skruer tiden frem til 21.09.00. For at trigge eventet kl. 20.01.00 skal man i simulering spole tiden frem til 20.00.55 og vente nogle sekunder til tiden selv når 20.01.00. Herefter skulle eventet gerne trigge. Jeg ved dog ikke om det er det som er sket for dig.

Der er forskellige ting som kan være årsage. Den mest nærliggende er at du har åbnet for adgang til IHC controlleren fra internettet, og at nogen forsøger at hacke den, eller er lykkes med at hacke den. Har du i sceneview (mener der er der man konfigurer e-mail afsendelse) konfigureret noget e-mail afsendelse ved specifikke events? Jeg lagde på et tidspunkt en mail server ned (min egen) ved at få controlleren til at sende en e-mail hvergang en PIR gik ON. Når solen stod ind på PIR'en begyndte den imidlertid at pulse, og så blev der ellers sendt mail's afsted. Forkert konfigreret NTP server. Forkert konfigureret DNS server.

Alarm systemer kan være lidt forvirende at arbejde med, da alt alarm material er ON når det er upåvirket. Hvis du har en alarm PIR med lys diode, vil du opleve at indgangen på IHC går OFF, når nogen går forbi PIR'en og dioden går ON. Det er præcist sådan det skal virke. Det samme gælder for magnet kontakter. I det øjeblik du åbner vinduet, går IHC indgangen OFF. At alarm materiel er default ON er også grunden til at man anbefaler at det er tilsluttet et 24/3 input modul, da det kun bruger 3ma pr. indgang, når indgangen er ON. Et input 24 eller 24/24 modul, som de også sommetider kaldes, bruger 30ma pr. indgang når den er ON. At magnet kontakterne skal gennem en and/og FB før de forbindes til alarm blokken skyldes at LK IHC er event styret. Det vil sige at hvis 1 magnet kontakt er OFF, så vil der ikke ske noget når magnet kontakt 2 går OFF, men går magnet kontakt 2 ingen ON så vil magnet kontakt indgangen gå ON, selvom magnet kontakt 1 fortsat er OFF. Dette sker ikke hvis du køre dem gennem en and/og FB før de forbindes til LK IHC indgangen. PIR'ne har hver deres indgang. Derfor er det ikke nødvendigt at køre dem gemmen en and/og FB.