Lars1

LK IHC controllerens overfølsomhed overfor netværks trafik er den primære årsag til at jeg aldrig kunne drømme om at give direkte internet adgang til en IHC controller. Jeg kender ingen som har fået hacket sin IHC controller, men jeg havde en overgang som test åbnet for direkte internet til min test controller, og den blev efter 1 mdr. lagt ned af et DDOS angreb. Jeg har logning på min firewall, så jeg kunne dokumenter angrebet overfor min ISP. For at få nogle logger ind på den ja, men ikke for at nogen kan lægge den ned med et DDOS angreb. Selv en 10 år gammel PC kan uden problemer lægge en LK IHC controller ned med et DDOS angreb. Hvis man absolut vil give direkte internet adgang til sin LK IHC controller, så bør man som minimum ændre både default bruger ID OG password. Det er ikke nok bare at ændre en af tingene. Derudover bør man lave portmapping i sin router/firewall, således at det er andre porte end 80 og 443 som man bruger på den offentlige IP. Mange ISP'er overvåger og bloker for port scanninger så sandsynligheden for at en hacker finder de nye porte er ikke så stor som den var for 5-10 år siden. Man er dermed nogenlunde beskyttet mod DDOS angreb.

Jeg vil fortsat påstå at en del af dit problem var et sensor problem, eller at der måske er byttet om på nogle rør, hvilket er set før med ventilations anlæg. Hvis du prøver at lave en varme tabs beregning på 10M uisoleret Ø160 kanal med en omgivelses temperatur på 0 grader og en start temperatur på 23 grader vil din slut temperatur være en del over 13 grader. Bare 50mm isolering omkring kanalen vil drastisk reducer dit varmetab. Ingen af mine sensor er på nogen måde kalibreret, men de er ikke 5 grader ved siden af. Min rum temperatur ligger generelt på 20-22 grader og selvom hele min udsugnings kanal pt. er uisoleret og der i vinters var ned til 5 grader på min 1. sal kom min udsugnings temperatur målt af mit Nilan anlæg aldrig under 17 grader. Min udsugnings kanal er stortset Ø160 hele vejen og ca. 15M lang når man tager alle grene med.

Jeg har en Raspberry PI liggende i en DMZ hjemme, som jeg kan nå med SSH udefra. Via Putty kan jeg bruge den som web proxy, så jeg kan nå web interfacet på mine IHC controller, IHC Captain m.m. via deres lokale IP addresser på mit netværk. Jeg har også en SSH VPN klient hvis jeg har behov for at få adgang til controlleren via Visual. Jeg vil mene at løsningen er fuldt ud ligeså god som alle gængse VPN løsninger, men den kan være lidt tricke at sætte op hvis man ikke normalt roder med Linux eller netværk. Her er en simpel guide til at sætte Putty op som web proxy sammen med SSH og en Linux server som f.eks. en Raspberry PI. https://linuxhostsupport.com/blog/ssh-tunnel-using-putty-and-firefox/

@AsgerHJeg checkede min indsugnings temperatur og udetemperatur her til aften nogle timer efter solen var gået ned. Ude temperaturen var ca. 6 grader, indsugnings temperaturen ca. 8 grader og rum temperaturen ca. 18 grader. Det passer noget bedre med den temperatur ændring jeg vil forvente i 10M uisoleret ventilations kanal. At temperatur forskellen midt på dagen er en del højer, skyldes sandsynligvis at min IHC ude føler sider på nordsiden af huse og dermed er i skygge det meste af dagen, mens indsugningen til ventilations anlægget sidder på en tagflade som vender sydøst, som dermed er badet i sol fra solen står op og til omkring kl 16-17 stykker. Indsugnings luften bliver derfor højst sandsynligt opvarmet af tegltaget inden den bliver suget ind.

Jeg ved ikke hvordan man kalibre Nilan temp sensor. Faktisk tror jeg slet ikke det kan lade sig gøre. Når jeg skriver kalibrering, så er det mere rettet på at de 2 sensor man bruger til at måle start og slut temperaturen er kalibreret ens. Udsugning er den luft som suges ud af huset, så den burde ikke ændre sig meget ved skiftende udetemperatur. Jeg spekuler derfor på om der måske er byttet om på nogle kanaler hos dig. Udsugnings temperaturen skulle gerne ligge rimelig konstant, mens indsugnings temperaturen følger ude temperaturen. Da jeg installerede mit Nilan anlæg måtte jeg dobbelt checke dette, da mine kanaler oprindeligt var planlagt til et comfort anlæg, og der skal byttes om på nogen af dem hvis man installer et compact anlæg. Det burde dog være temmeligt nemt at se i displayet på Nilan anlægget. På en vinterdag eller forårs dag skal udsugnings temperaturen være væsentlig højre end indsugnings temperaturen. Kun på meget varme sommerdage vil indsugnings temperaturen være højre end udsugnings temperaturen. På mit anlæg er indsugning på displayet markeret med en blå pil som peger ind i anlægget og udsugning med en rød pil som peger ind i anlægget.

@AsgerH Jeg undrede mig meget over hvordan du kan have et temperatur fald på 10 grader i en isoleret ventilations kanal, så jeg tog et nærmere kig på mit anlæg. Jeg har ca. 10M indsugnings kanal, som pt. løber uisoleret på min første sal som jeg er ved at renover. Da jeg checkede anlægget for 10 min. siden kørte den med ventilations trin 2, ude temperatur på 8 grader (udendørs IHC temp. sensor) og rum temperatur på 20 grader (IHC temp. sensor) er indsugnings temperaturen i mit ventilations anlæg 16 grader (Nilan temp. sensor i anlægget). Min udsugnings kanal er ca. 12M. Hovedparten løber uisoleret i første salen, som i vinters ikke var opvarmet. Rum temperatur var derfor ned til omkring 5 grader når det var koldest og sjældent over 10 grader. Selv under de forhold kom udsugnings temperaturen ved ventilations anlægget aldrig under 18 grader. Alt i alt tvivler jeg derfor stærkt på at et temperatur fald på 10 grader i en isoleret ventilations kanal skyldes isolerings tykkelsen. Selv ved -20 grader omkring isoleringen tvivler jeg på at du vi få et temperatur fald på 10 grader, med mindre der er tale om en MEGET lang ventilations kanal og en start temperatur væsentlig over 20 grader.

De ligger på "mitlk" https://www.lk.dk/mitlk/download-ihc-software/ Det kræver login, men alle kan oprette sig som bruger. Du finder "mitlk" ved på lk.dk at vælge support -> download software.

Der kan være mange årsager til temperatur faldet. 10 grader lyder dog voldsomt medmindre det er et langt stræk. Jeg vil derfor først og fremmest sikre mig at temperatur sensorne er kalibreret korrekt. Derefter check placering af temperatur sensoren i dit Nilan anlæg. Jeg har et Nilan compact S anlæg og i forbindelse med et filter skifte blev den ene temperatur sensor skuppet så den ikke længere sad ind i varmeveksleren, hvilket gav en forskel på 2-5 grader alt efter hvor kraftigt anlæget kørte. Hvis det er et isolerings issue, så bør faldet være forskellig alt efter hvor varmt det er uden for eller på dit loft.

Jeg er på INGEN måde expert på området. Men jeg synes at Cerius's argumentation lyder meget tynd. Eftersom de har flyttet måleren ud af skabet for at kunne aflæse den tyde det på at den er radio aflæst, og så vil jeg begynde at mistænke antennen på dit IHC anlæg hvis du har en visual 2 eller 3 controller. Jeg synes det lyder mærkeligt at din IHC strømforsyning skulle kunne forstyre radio aflæste måler uden for dit hus. IHC antennen kan tilgengæld række op til 300M under særligt gode forhold. Den bør dog ikke sende hele tiden. Har du checket på eloverblik.dk om din el-måler bliver aflæst hver time? Hvis din el måler bliver aflæst hver time har jeg svært ved at se hvorfor din IHC strømforsyning skulle være årsag til at andre el måle på vejen ikke kan aflæses. Omkring EU direktivet, så fastsætter det ganske rigtigt grænser for EMC eller elektromagnetisk støj. Eftersom dine LK IHC produkter er CE mærket er de jo designet til at overholde dette, så hvis de ikke længere overholder direktivet kan de være defekte. Jeg er dog ikke godt nok inde i EMC direktivet til at afgøre om de måle resulater der fremgår af dine billeder er inden for EMC direktivets grænser eller ej. Du kan evt. prøvet at høre LK hvad de mener om sagen. De må om nogen være interesseret i at vide hvis deres produkter ikke overholder EMC direktivet, da det kan medføre STORE udgifter for dem hvis de skal til at tilbagekalde massevis af produkter. Desværre har jeg ikke nogen kontakt informationer til dem. Sidst men ikke mindst. Støjmålingerne er lavet i området 0-500KHz. Hvis din elmåler er radio aflæst sker det typisk i området 433-444MHz eller via mobil nettet på 700MHz, 800MHz, 900MHz, 1,8GHz, 2,1GHz, 2,6GHz, 3,5GHz eller 26GHz. LK IHC wireless ligger på 868-870MHz. 800MHz båndet bruges også til 4G

Alle strømforsyninger lave elektrisk støj, men at LK IHC strømforsyninger skulle være specielt støjende har jeg aldrig hørt om før. Alt el materiel skal være CE godkendt for at du må tilsluttet det til el-nettet i DK. CE godkendelsen indeholder regler for elektrisk støj. Du kan derfor blive stillet overfor et krav om at få repareret eller udskiftet et evt. defekt CE godkendt produkt, men så vil jeg mene at der skal være dokumentation for at det er det specifike produkt som støjer. Hvorvidt at det er op til dig at finde ud af hvilket produkt som støjer er jeg MEGET usikker på. Det er jo ikke skills som man kan købe sig til hos en tilfældig elektriker. Jeg har ikke hørt om noget fortilfælde som ligner dette. Jeg har hørt om produktions virksomheder som er blevet pålagt at installer støjfiltre m.m. men aldrig at privat personer er blevet pålagt at skifte specifike komponenter fordi man mistænker at de støjer. Jeg har heller aldrig hørt om at der er regler for elektrisk støj i leverings betingelserne fra elselskaberne overfor privat personer. Jeg har et par spørgsmål. Har Cerius været inde hos dig og konstateret at det er strømforsyningen som støjer, eller gætter de bare? Hvad er det for en el-måler du har? Hvis det er en Kamstrup el-måler, så fjernaflæses de via mobil telefoni nettet og her har Cerius ingen beføjelser. Det er kun Telestyrelse, eller hvad de nu hedder i dag, som kan påtale radio støj. De andre e-måler som Cerius bruger kender jeg ikke, så de kan evt. godt fjernaflæses via el-nettet. Hvilken paragraf i deres leverings betingelser henviser de til når de forlanger at du udskifter din LK IHC strømforsyning?

Jeg havde nogen udfordringer med mine LED Dimmer indtil jeg opdagede at de skal være tilsluttet BÅDE 24V OG 230V for at man kan kommuniker med dem. Der behøver ikke være lamper tilsluttet, men BÅDE 24V OG 230V forsyning SKAL være tilsluttet for at man kan kommuniker med dem. Ikke specielt logisk og det stå ikke i specielt tydeligt i villedningen.

Din problem beskrivelse er lidt uklar, så jeg er ikke sikker på hvad der virker og hvad der ikke virker. Hvis du henter firmwaren her https://www.lk.dk/mitlk/download-ihc-software/ihc-controller-visual-3/ er det en ZIP fil, som alle moderne OS kan åbne og pakke ud. Det har ikke noget med browseren at gøre. Du henter bare filen ned, gemmer den på din computer og pakker den ud. Hvis problemet er når du forsøger at starte firmware loaderen, så er den Java baseret i HW 7/Visual 3 controller udgaven. Det kan derfor være Java problemer. LK har frigivet Visual 03.04.72 for 1 mdr. tid siden. Den skulle jvf. deres release notes fixe nogle Java issues. De skriver samtidig at Java starter SKAL bruges. @Mikkel Skovgaardhar lavet en alternativ Java starter. Jeg er dog ikke helt klar over om den også understøtter firmware loader. Den gjorde ikke i starten såvidt jeg husker.

Problem: Løsning: Hvis du får ovenstående fejl, og ikke har problemer med at logge ind via Visual skyldes problemet sandsynligvis at din Java version er for ny i forhold til din LK IHC firmware version. Problemet kan løses på 3 måder som alle har deres fordele og ulemper. Mikkel's Java starter - https://jemi.dk/ihc/starter/ - virker og der er bedre support end hos LK. Reenable de forældede krypterings protokoller i Java. Guidelines til dette findes i tråden "Java problemer igen igen igen" (se link længere nede) - Virker og kan også bruges hvis man har andre forældede Java applikationer som f.eks. ældre Cisco ASA firewalls etc. LK's Java starter - https://www.lk.dk/mitlk/download-ihc-software/ - Virker ikke altid. Visual 3.4.72 skulle fixer nogle Java issues som gør den mere stabil. Man skal med andre ord installer Visual 3.4.72 for at få LK's Java starter til at virke stabilt med Visual 2 controller. Baggrunds information og forklaring på problemet: Den sidste firmware til Visual 2 controller er fra 23 Juni 2017. Siden da er indtil flere krypterings protokoller m.m. blevet udfaset i Java, OS'er, Browser m.m. Dette rammer selvfølgelig ServiceView og AdminView da disse er Java programmer som er afhængig af understøttelsen af de forældede krypterings protokoller i Java. Udfasningen af de forældede krypterings protokoller rammer ikke Visual da det er et Windows program som LK selv har skrevet og derfor selv styre hvilket krypterings protokoller de vil understøtte. I Visual 2 er firmware uploader et Windows program og er derfor ikke ramt af udfasning af krypterings protokoller. I Visual 3 er firmware uploaderen et Java program som er ramt af udfasningen af krypterings protokollerne.

Brug Mikkel's Java starter eller følg guidelinen i nedenstående tråd for at reenable de forældede krypterings protokoller som Java ikke længere understøtter.

Så fik jeg tid til at rode med problemet igen og fik det løst. Problemet var at der ikke var 230V på dimmerne. Uden 230V funger de slet ikke. Med andre ord et typisk LK produkt, som både kræver 230V og 24V for at man kan kommuniker med det og programer det.

Your problem is most like encryption protocols which Java no longer supports. Use Mikkel's java starter or read the below tread for guidelines on how to reenable the unsupported encryption protocols in Java.

Hvis det er en Visual 2 controller er et kendt problem at den nemt bliver overbelastet på netværks interfacet. Jeg har ofte problemer med at forbinde med Visual til min Visual 2 controller hvis IHC Captain og ServiceView køre samtidig. Nedenstående 2 tips kan måske hjælpe på dit problem. Prøv at stoppe Home Assistant før du uploader programmet og vent et par min. før du igen starter Home Assistant efter program upload. Et andet trik som også virker for mig er at genstarte min Visual 2 controller før jeg henter programmet ned i Visual for at rette i det.

@Thomasi Den lave hastighed skyldes næppe dårlig terminering. Du skal nærmest have snoet parne op over 10CM før end at det kan halver din througput p.gr.af støj. Enten køre man 1Gbit eller også køre man med 100Mbit. Årsagen til de 100Mbit er måden som Gbit Ethernet er strikket sammen. Et af parne er altid sende par. Et andet er altid modtage par. De 2 sidste par bruges på skift til sende eller modtage alt efter om der er mest behov for at sende eller modtage data, og de skifter altid retning samtidig. Er et af de sidste 2 par dårligt termineret vil du falde tilbage til 100Mbit Ethernet. Er et af de første 2 par dårligt termineret er der enten ingen forbindelse eller du køre 100Mbit half duplex. Det afhænger dog af dit IT udstyr om 100Mbit half duplex overhovedet er understøttet. Det er mere sandsynligt at din switch, router, firewall eller computer ikke kan klare de 1Gbit. Der skal faktisk en hel del computer kraft til for at kunne håndter 1Gbit. Bare fordi at noget IT udstyr har et 1Gbit interface er det langt fra en garanti for at det også kan håndter 1Gbit trafik. Derudover køre de fleste ISP'er med abonnement typer hvor de levere op til 1Gbit, men kan levere mindre når der er peak perioder. For at teste dine kabler, bør du sætte din computer direkte til din router/switch/firewall ved at tage computer kablet ud af patch boxen og sætte det direkte i din computer. Herefter udføre du din test, sætter kablet tilbage i patch boxen, sætter din computer tilbage på sin plads og gentager testen. Jeg er ret sikker på at du vil have 2 test resultater som er meget tæt på hinanden hvilket udelukker fejl på dine kabler.

Jeg har set ovenstående problem på min Visual 2 controller (HW6.1). I Visual 3 har jeg pt. ingen wireless enheder, så der har jeg naturligvis ikke set problemet. I Visual 2 er der kun den hårde vej og genlinke alle wireless enheder manuelt. Det havde jeg ikke lige tid til da jeg løb ind i problemet, så jeg kørte med fejlen i flere mdr. uden at det gav nogen problemer. I Visual 3 burde man, som Mikkel skriver, kunne genskabe links ved at følge den medfølgende villedning til hvordan man gør dette. Jeg skriver med vilje burde, for fejlen lyder for mig mere som en korrupt wireless "database" hvor der godt nok er forbindelse til wireless enhederne, men hvor IHC controlleren ikke har det korrekte produkt nr. registreret.

Du kan installer visual 2 og kopier FB'en over i Visual 3 derfra, men har du checket at du ikke kan bruge persienne styrings FB'erne? Gardin styring lyder for mig lidt af persienne styring. Alternativt kan du også lave FB'en selv. Der er dog en del fald grupper i programering af LK IHC da det er event styret hvilket er væsentlig anderledes at programer end PLC'e som er status styret.

Mikkel's Javastarter burde kunne løse problemet, men ellers check nedenstående tråd. Der er nogle gamle krypterings protokoller som skal enables for at det virker. Detsværre er det lidt komplext da løsningen afhænger af kombinationen af din firmware version og Java version.

I agree with EjvindHald. Downgrade to 2.7.199. It's much more stabil than 2.7.220. Specially regarding the network interface. Your controller is most likely not defekt. By design it's just very sensitive to network traffic, like if you have IHC Captain installed or given access to the controller from the internet. Either could flood the controller with data, which gets the network interface to stall while everything else works fine. Both HW 6.2 and 7.x are less sensitive to network traffic. HW 7.x the least, but even that one I once had to reboot due to lack of network access.

Lige for at suppler Hennings svar. Modulerne er ikke problemet. LK IHC er temmelig gammeldag på nogle punkter. Der er bl.a. ikke noget auto discovery, så du skal manuelt definer hvilke moduler der sidder på hvilke controller ind/udgange. Det er dog ikke noget stort problem da det altsammen normalt sidder i den samme tavle/rum og reelt kun er nødvendig for dokumentation. Man kan sagtens program LK IHC uden at have fortalt controlleren hvilke moduler der er tilkoblet hvilke controller ind/udgange. Udfordringen er at finde ud af hvilke ind og udgange på de enkelte moduler (ikke controlleren) som er forbundet til hvad. Selvom at der ikke er noget dokumentation af det gamle program, så vil man alligevel får en del hjælp hvis man har adgang til det gamle program da meget af det er selv dokumenterende. Jeg vil anbefale at du installer LK IHC Visual og bruger 1/2 time på at læse den medfølgende villedning. Det giver et RIGTIGT godt overblik over hvordan LK IHC er bygget op og det bliver nemmer at forstå når vi taler controller, moduler, controller ind/udgange, modul ind/udgange m.m.

Bortset fra at der ikke er Wireless i de gamle DOS og Visual 1 controller, hvad er det så for wireless komponenter som ikke understøttes i de nyer controller? Såvidt jeg husker er det kun de logiske touch produkter som er fjernet fra Visual. Selve wireless komponenterne understøttes fortsat, men skal programers anderledes i Visual 3 end Visual 2.

Som Henning skriver skal du lave en galvanisk adskildelse af de 2 systemer. Grunden til dette er at LK IHC input modulerne ikke trækker strøm. De levere strøm og fungerer ved at en indgang bliver kortsluttet til 0V. Dette gør det nemt at tilslutte svagstrøms afbryder m.m. men besværligt når du vil detekter om en udgang på et andet produkt er ON. I dit tilfælde kan du sætte et lille svagstrøms relæ parallelt med akturatoren. Det skal være en meget speciel gulvvarme styring hvis den ikke kan trække et svagstrøms relæ sammen med en akturator. LK IHC indgangen forbinde du til kontakt sættet på relæet.