Lars1

Med den ringe processor kraft der er i LK IHC controllerne incl. den seneste HW7 version er jeg ret sikker på at du hurtigt vil opdage hvis din controller er blevet inficeret til fremtidig brug. Det samme gælder for rigtig mange af de IOT devices som findes idag. Oven i det er de ikke så lette at inficer og modificer til fremtidig brug. Deres OS er somregl et OS med kraftigt reduceret funktionalitet som gør dem temmelig svære at inficer eller bruge som jumpstone. Mig bekendt ligger der ikke Java på controllerne. Det er en embed linux kerne som køre på dem såvidt jeg ved. Java bruges kun til klient programmerne på din PC. Der behøver ikke ligge Java på controllerne for at det vil virke. Linux kernen er dog også gammel og bliver sjældent opdateret så her har man nøjagtig de samme udfordringer med sikkerhedshuller. Jeg er dog ikke så bekymret for det netop fordi det er et OS med stærkt reducereret funktionalitet som gør det svært at udnytte for en hacker.

Vindchill effekt eller fejl i måle metoden, for så stort et varmetab er ikke teknisk muligt. Jvf. energihåndbogen fra 2019 fra evu.dk er dit varmetab i en uisoleret ventilantions kanal på 160W/kvadratmeter ved 22 grader luft temperatur i kanalen. Det betyder at for en uisoleret kanal på Ø160 har du et varmetab på ca. 80W/m. Ved 40mm. isolering er varmetabet 16W/kvadratmeter ved 22 grader, eller ca. 8W/m for en Ø160 kanal. Ved 80mm isolering er tallene 8W/kvadratmeter eller 4W/m for en Ø160 kanal. Hele den del hvor der sker luft cirkulation er nød til at være lydisoleret for at have effekt. Bare at lydisoler frontlågerne har ingen effekt. Dit anlæg er derfor MEGET specielt hvis ikke hele den del hvor der sker luft cirkulation er lyd/varme isoleret. Bortset fra det skrev jeg jo netop at anlægget primært er isoleret afhensyn til lyd, men at denne isolering også virker varme isolerende. Jeg mindes heller aldrig at have set at Nilan påstår andet. Tallene fra beregning af varmetab i ventilations kanaler kan iøvrigt også bruges til at beregne varmetabet i et uisoleret kontra isoleret ventilations anlæg. Igen understøtter tallene at dit varmetab i anlægget (bortset fra modstrøms veksleren) er stortset ikke eksisterende og man primært isoler af hensyn til lyd og kondens vand.

Vi bliver nok heller ikke enig om dette, men lad mig komme med nogle sidste indspark. Der er et varme tab i ventilations kanaler, også selvom de er issolerede. Men selv ved isolerede rør er det fysisk umuligt at tabe 2-5 grader på korte afstande (<10M) eller 8 grader på lidt længere afstande (<30M). De første par m.m. isolering er de mest effektive. Bare 10mm isolering reducer dit varmetab med 50%. Herefter falder reduktionen som ved alt andet isolering. Nilan's anbefaling om 100mm isolering er ikke af hensyn til varmetab, men for at undgå kondensvand i rørne. Jvf. rockwool anbefales der mindst 80mm isolering omkring ventilationsrør ved en omgivelses temperatur på -10 grader, en luft temperatur i rørne på 25 grader, 90% luftfugtighed og et luft flow på 5m/sek. Ved en rum temperatur på 10 grader anbefaler de kun 30mm. isolering. Rockwool har varmetabs tabeller for varmtvands rør, så man nemt kan beregne hvor meget energi man spare ved at isoler sine varme rør. De har ikke tilsvarende tabeller for ventilations rør, hvilket for mig er endnu et tegn på at der ikke er noget nævneværdigt varmetab i ventilations rør hvad enten de er isolerede eller ej. Derfor er jeg ret sikker på at dine målinger enten er forkerte eller at måle metoderne er forkerte. Som jeg tidligere har skrevet ændre temperaturen sig nogle grader på den sensor som sidder ind i modstrømsveksleren hvis man tager den ud så den sidder uden fysisk kontakt med modstrøms veksleren. Derudover har du en vindchill factor som du skal tage højde for. Nogle temp sensor er designet til at måle temperatur hvor luften står stille, mens andre er designet til at måle temperature på luft som flytter sig. Rum sensor er normalt designet til stillestående luft, hvilket er årsagen til at de ikke må sidde for tæt på døre og vinduer m.m. Sensorne i et ventilations anlæg er designet til at måle temperatur på luft som flytter sig, bortset fra den sensor som sidder ind i modstrøms veksleren. Kommer en sensor som er designet til at måle temperature i luft som flytter sig til at sidde ind i et filter vil den ikke længere måle korrekt temperatur. Selvfølgelig har ændret luft hastighed indflydelse på slut temperaturen, men ikke mere end max 0,1-0,2 grader. At den målte temperatur ændre sig ved højre luft hastighed, kan ligeså meget skyldes vindchill factoren fremfor ændret varmetab. Ligegyldigt hvor mange data du logger hjælper det dig ikke hvis du bruger de forkerte sensor til at generer datane, eller at sensorene ikke er placert korrekt. Det varmetab du har målt dig frem til er ganske simpelt ikke fysisk muligt. Selv ikke hvis både anlæg og rør var totalt uisolerede. Sidst men ikke mindst. Medmindre dit Nilan anlæg er et MEGET specielt anlæg, så er det isoleret. Den skum som er brugt til at lydisoler anlægget har samtidig en høj varmeisolerende effekt. I mit anlæg er der ikke en eneste flade i ventilations delen som ikke er dækket af mindst 20mm lyd/varmeisolerende skum. Kunne det være bedre. Sikkert, men igen. De første par m.m. er de mest effektive og luften opholder sig i ventilationsanlægget i MEGET kort tid. Selv hvis du fordoblede tykkelsen vil du ved -20 grader uden for anlægget ikke se en temp. forskel på mere end 0,1-0,2 grader ved indblæsning. Det største varmetab du har i et ventilations anlæg med 30M fra udsugning og til indblæsning er modstrøms veksleren. Dette gælder også ved en udetemperatur på -5 grader og dine ventilations kanaler kun er isoleret med 50mm. isolering. Hvis dine målinger var korrekt tvivler jeg på at ventilations anlæg vil være lovlige i DK, med det fokus der er på energieffektivitet.

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.