Lars1

Kan du juster lysstyrken op/ned efter at have taget strømmen til lampeudtaget i 10 sek. og genstartet IHC controlleren? Prøv også at tage strømmen (incl. evt. batteri backup) til controllerne i 10 sek. Det sker at IHC controlleren og de wireless enheder mister forbindelse. Den kan ofte genskabes ved ovenstående process. Alternativet er at unlinke lampe udtaget og relinke det.

Den gamle version af IHC Captain har nogle funktioner til at logge data. Dem benytter jeg. Jeg logger til lokal disk, men man kan også logge til en cloud service. Jeg mener der er en kort villedning til det på IHC Captain websitet. Desværre kan IHC Captain kun logge data når der sker ændringer. Man kan ikke få den til at logge f.eks. hver time. Jeg har derfor lavet en FB, som hver time opdater en counter, som IHC Captain lytter efter. Min plan er at lave grafer etc, men mangler pt. ca. 24 timer i døgnet for at få tid til at kigge på den del.

Nu bruger jeg ikke LK's FB, så jeg ved ikke hvad de skriver, men det er ikke så vigtigt om ventilerne bliver motioneret en gang om ugen, eller hver 14 dag. Det vigtige er bare at de bliver motioneret i sommer perioden. Mit umiddelbare gæt er dog at LK har timer på hver telestat udgang, og at denne timer bliver sat til initial værdi hvergang en telestat slukker. Men som sagt bruger jeg ikke LK's varme FB, så jeg ved ikke hvordan de styre tiden mellem hver motionering. De er bare et gæt.

Telestaterne skal passe til din fordeler unit. Min er fra Danfoss, og jeg har 8 24V Danfoss telestater, som nu køre på 12 år, uden fejl overhovedet. Husker du at motioner dem mindst hver 14 dag i sommer halvåret?

Grunden til at jeg forslår ServiceView, er fordi jeg har set flere som har problemer med at connected med Visual hvis enten ServiceView eller IHC Captain køre. Hvis problemet også eksister med ServiceView åben, så ligger fejlen højst sandsynligt i programmet, og de fejl som du referer til her kan nemt være nogle af dem. Det kan godt være man er nød til at åbne alle produkter og funktions blokke i serviceview for at se problemet ligeså slemt som i IHC Captain. Dertil kender jeg IHC Captain kommunikationen med IHC Controlleren for dårligt.

Inden hele skylden bliver lagt på IHC Captain, så prøv at stoppe IHC Captain, og åben serviceview isteddet, og gerne åben et par produket eller funktions blokke, og prøv så at se om tryk etc. også hænger når serviceview er åbent.

Hvis det er fordi du du ikke bruger standard porte, så skal du selvfølgelig ændre port nr'et i telnet kommandoen til den port du bruger, men det gik jeg egentlig ud fra at alle selv kunne tænke sig til. Hvis det er fordi at der ikke er adgang til din controller fra internettet, så ændre det ikke noget. Telnet komandoen var for at dokumenter at webserver etc. er temmelige glade for at fortælle hvem de er og hvilke muligheder de tilbyder. Det har intet at gøre med om din controller er tilgængelig fra internettet eller ej.

Jeg negligere ingen ting. Der findes i dag hacker tools på nettet, som kan hacke en server med kendte exploites som dem Kim Carlsen referer til. De kræver intet andet end at du angiver hvilken IP range du ønsker at skanne, så klare toolet resten, og outputtet er en liste med server, med præcis angivelse af hvordan man kommer ind på de usikre server. Hvis du har prøvet den telnet jeg skrev om, så vil du nu også vide hvilke web server incl. patch level der ligger i din IHC controller, og dermed er det bare at slå op på nettet hvilke exploits der findes på den, samt hvordan man bruger dem.

@Kandersen. Du er tydeligvis ikke opdateret på hvordan hacking forgår idag, samt hvor avancerede portscanner tools m.m. er idag. Prøv "telnet <IHC controller IP> 80" og tryk på enter når du får forbindelse. LK's IHC controller er temmelig glad for at fortælle hvordan man kan hacke den.

Hackeren bruger den portforwarding du har lavet i din router til din IHC controller. Din router og IHC controler kan ikke se forskel på om det er en webbrowser, en LK IHC app, eller en hacker, som forsøger at nå din controller. Der findes masser af hacker værktøjer på nettet til at lave network scanning med. Flere af disse værktøjer kan på under 5 min. scanne 100 IP addresser for åbne porte og fortælle dig rimeligt præcist hvilke applikationer der svare på hvilke porte på de addresser. Jeg har et par kollegaer som arbejder med IT sikkerhed. Fra tid til anden sætter de en honeypot server op. Den bliver somregl hacket inden for 1 døgn.

Tager 5 min. men en standard network scanning, også selvom du bruger none standard ports. Det er desværre de færreste ISP'er som bloker for port scanning på private ADSL forbindelser.

Eftersom LK IHC baser sig på simpelt bruger ID og PW, vil det tage en gennemsnit hacker under 1 time at skaffe sig adgang. Sandsynligvis vil controlleren crashe et par gange undervejs, grundet det elendige design af netværks interfacet, så det tager måske 3 timer, men at knække bruger ID og PW via brutforce er ikke særligt svært på LK IHC.

De personfølsomme data er i min optik i dette tilfælde det mindste problem. Langt større er problemet at med adgang til programmet er det relativt nemt at se hvordan man f.eks. kan slå alarmen fra. Specielt fordi at såvidt jeg husker, så har Mikkel også fundet en metode til at sende beskeder til controlleren uden at logge ind. Men LK og sikker systemer har aldrig været noget man kunne sige i samme sætning.

Det kan også være at strømforsyningen er overbelastet. Når det sker, vil spændingen dykke.

Du kan roligt købe en noname PS til dine telestater. Output24 modulerne er jo designet til at både AC og DC load, samt op til 48V spænding.

Præcis det samme som hvis du havde valgt en LK IHC strømforsyning. sålænge du kan dokumenter at strømforsyningen lever 24V DC, så kan de ikke stille krav om at du skal bruge deres strømforsyning for at de vil hjælpe. Den lave spænding behøver ikke skyldes en defekt strømforsyning. Det kan ligeså nemt være at din strømforsyningen er overbelastet.

Hvilken firmware ligger der på controlleren? Har du prøvet at hente projektet lokalt? Har du prøvet at genstarte controlleren før du connecter via Visual?

Hvis din controller køre med firmware 2.7.220 eller tidligere vil div. apps næppe virke på Android 8.x og nyer eller IOS 10.x eller nyer. Det skyldes at firmware 2.7.220 og tidligere bruger krypterings protokoller som ikke er understøttet af de nyer Android og IOS versioner. Opgrader til IHC firmware 2.8.4 eller nyer for at få det til at virke. Selvom LK påstår det modsatte, kan det godt lade sig gøre at opgrader en HW 6.1 contoller til firmware 2.8.4 via firmware loader 1.3 eller ældre. Den findes på download siden her. Bemærk LK fraråder at man opgrader HW 6.1 til firmware, men tildato er vi mange som har gjort det og fået en mere stabil controller. De eneste problemer jeg har hørt om er en enkelt hvor opgraderingen fejler, men efter nedgradering til 2.7.199 køre hans controller igen fint.

Hvorvidt noget understøttes af LK og om det virker har langtfra altid noget med hinanden at gøre. Som Lars Jacobsen skriver er der MANGE tråde om emnet, og i flere af dem er der beskrevet hvordan trådstarter fik det til at virker. Men inden du kaster dig over en større søgning/læse opgave, kunne du jo prøve at se om du kan nå serviceview og adminview via din webbrowser. Kan du ikke det vil du heller ikke få Visual til at virke, da serviceview, adminview etc. alle bruger den samme port som Visual.

Nej. en firmware opdatering bør ikke introducer nye problemer. Det er Java opdatering + manglende firmware opdatering som introducer problemer. Firmware loaderen og Visual bruger ikke Java. Derfor virker de begge fint selvom du ikke kan logge på ServiceView, AdminView etc.

Det giver mening. Problemet med adgang nægtet via USB kan bl.a. skyldes certifikat/krypterings protokol problemer, og hvis java starter er konfigureret til 2.7.220 er der sikkert nogle parameter i den, som ikke er sat til at understøtte problemerne før 2.7.220 Hvis man ikke ønsker at opgrader til 2.7.220, så prøv at følg Java workaroundsne beskrevet i Java problemer igen igen igen tråden.

Jeg går udfra at du vil ønsker at alle 3 pære skal tænde samtidigt. Hvis dette er korrekt, sætter du det niveau pærene skal lyse på når du linker dem til scenariet. Man kan sagtens linke 3 pære til 1 scenarie

Jeg kender ikke Uni400 dimmeren, men det problem du beskriver er et kendt problem for LK's wireless relæer og dimmer hvis belastningen er under minimums belastningen.

Du er klar over at du svare i en tråd som ingen aktivitet har haft i næste 1 år?

Og den diskution må du tage med LK. Den er pænt offtopic i denne tråd.