Lars1

Udover at lave hele programmet offline, har du også mulighed for at lægge programmet op i controlleren, uden at der er nogen I/O moduler tilsluttet. Herefter kan du teste programmet via ServiceView, hvor du manuelt kan ændre tilstand på tryk m.m. som hvis de var fysisk monterede, hvilket er bedre end offline simulering. Det eneste som ikke virker i ServiceView uden fysiske enheder tilsluttet er wireless relæer, stikkontakter og dimmer, LED dimmer og modem's

Hvis dimmerne ikke kan ses via AdminView, så kan de ikke kommuniker med controlleren. Årsagen til dette kan være mange, men typisk at RS232 forbindelsen ikke er iorden (knækket ledning m.m.), at de mangler 24V eller 230V eller at de er defekte. Bemærk at dimmerne skal forsynes med BÅDE 230V OG 24V for at kunne kommuniker med controlleren. Det er ikke nok at de kun har 24V eller 230V. De SKAL have begge dele samtidig.

Som jeg skrev, er problemet sjældent den lampe hvor lyset er lang tid om at reager. Det er somregl en anden wireless enhed som bloker for kommunikationen. En lille spændings ændring kan være nok til at udløse problemet hvis det skyldes lav effekt forbrug. Men der kan også være andre årsager. For at finde dem skal du imidlertid identificer de wireless enheder som er skyld i problemerne. Du kan prøve om du kan finde den/de problematiske wireless enheder ved at lave en FB, som sætter alle wireless enheder samtidig. Kommunikatione vil ske i den rækkefølge de er linket til FB'en. Når du har prøvet at ændre status et par gange, kan du prøve at ændre rækkefølgende så de wireless enheder så de alle bliver linket i den modsatte rækkefølge. Gentag nu dine status ændringer. Nu skulle du gerne have en idee om hvilken wireless enhed som giver dig problemer. Den wireless enhed som er før den som er ramt af forsinkelse, er typisk den wireless enhed som er skyld i problemerne. Værd dog opmærksom på at du nemt kan have flere enheder som giver problemer, også bliver det straks mere kompliseret af finde de skyldige. Kommunikationen med wireless lampeudtag, dimmer, stikkontakter og tilsvarende sker i grove træk således. Controlleren sender besked til enheden om at ændre tilstand eller lys styrke. Enheden svare tilbage at ændringen er gennemført. Hvis controlleren ikke modtager step 2 inden udløb af timeout gentages step 1 og 2 nogle gange indtil controlleren modtager det ønskede svar eller giver op og går videre til næste wireless enhed. Sålænge at controlleren ikke har modtaget tilfredsstillende svar i step 2 eller den har givet op, vil den ikke kommuniker med andre wireless enheder. Kommunikationen med wireless tryk og wireless input moduler sker i grove træk således. Et wireless tryk sender en besked til controlleren. Controlleren sender beskeden retur for at bekræftige modtagelsen. Forstår controlleren ikke beskeden, vil den lave et ikke forstået broadcast og vente på at beskeden bliver genfremsendt eller timeout indtræder. I denne periode vil controlleren ikke kommuniker med andre wireless enheder. Hvis et wireless tryk ikke modtager bekræftigelsen på modtagelsen inden for timeout eller modtager et ikke forstået broadcast, vil det forsøge at genfremsende beskeden indtil det modtager den forventede bekræftigelse eller den giver op.

Der er forskellige forsinkelses problematikker med LK IHC wireless, og de har forskellige løsninger, så du må være mere specifik om hvad dit problem er. Flere af problemerne opstår imidlertid hvis man har for lav belastning på HW ver. 1 wireless enheder. De kræver alle mellem 5-20W som minimums belastning. Kommer man under dette begynder der at opstå problemer med kommunikationen mellem wireless enheder og controlleren, hvilket bl.a. medføre at der forsøges flere gange før der gives op. Eftersom kommunikationen er seriel, kan 1 wireless enhed bloker for kommunikationen med de andre og da det ofte er det afsluttende ok fra en wireless enhed som fejler, kommer man nemt til at fejlsøge på andre wireless enheder end der hvor problemet rent faktisk eksister.

Det er lykkes mig at få kommunikationen til at virke. Hvad jeg gjorde forkert ved jeg ikke. En dag hvor jeg for nok 10 gang prøvede at skille alt ad, samle det igen og lave konfigurationen fra grunden igen, virkede det pludseligt.

Jeg har en udfordring med data konvertering i OpenHAB. Min Siemens LOGO8 PLC sender temperature som heltal, hvilket betyder at jeg er nød til at divider med 10 i OpenHAB får at få den rette temperatur. F.eks. når PLC'en rapporter 305 grader, er temperaturen reelt 30,5 grader. Jeg kan imidlertid ikke få data konverteringen til at fungere. Item er konfigureret med følgende linie Number:Temperature Logo8_AM1 "Returløb bad [%.1]" { channel="plclogo:analog:LOGO8:LOGO8-Analog-Marker:AM1" [profile="transform:JS", function="LOGO8-0.1.js"] } men der sker absolut ingen konvertering. Item bliver bare opdateret med den rå værdi. Hvis jeg opretter item via GUI, virker konverteringen fint, men jeg fortrækker konfigurations filer. Nogen som kan fortælle mig hvad jeg gør forkert?

Hvis den ikke har kørt med seneste firmware er der desværre en vis sandsynlighed for at den er død og ikke kan bringes til live igen. Jeg kan dog ikke huske hvordan man præcist identificerede om controlleren kan bringes til live igen eller ej, så søg lidt her på boardet. Der var for et par år siden en del Visual 3 controller som døde.

Fik du løst dit problem?

PDS kabler er kortslutnings beskyttet, men de er ikke overbelastnings beskyttet. Der er en stor forskel på de 2 begreber. Ved en kortslutning har du en meget høj strømstyrke ganske kortvarigt, mens du ved ovebelastning har en forhøjet strømstyrke i længere tid. Til kortslutning beskyttelse af 1,5 kvadrat ledninger/kabler, kan du uden problemer benyttet 16 og 20A sikringer, mens du under normale varmeaflednings forhold max må bruge 13A sikringer til sikring af 1,5 kvadrat ledninger/kabler mod overbelastning. Der er ikke noget krav om at ledninger/kabler er overbelastnings sikret med sikringer, såfremt at du på anden måde har sikret dem mod overbelastning. Det kan f.eks. være en varmepumpe på 2KW som er fastmonteret til en afbryder med 1,5 kvadrat kable og sikret med sin egen 16 eller 20A sikrings gruppe grundet startstrøm. Dette vil være en fuld lovlig installation. Er varmepumpen tilsluttet en stikkontakt, vil dette ikke være en lovlig installation. Den er kun lovlig fordi du ikke kan sætte anden belastning på strømkredsen uden at arbejdet kræver autorization.

LK IHC er desværre ikke et produkt som Schneider satser på længere. De vil heller have os alle til at skifte til Wiser, hvilket dog IMHO ikke er noget reelt alternativ og næppe nogensinde bliver det med den teknologi de pt. bruger.

Der er nogle fejl i LED dimmernes firmware, som kan give de fejl du ser. Det spøjse er at fejlene kan løses midlertidigt ved at firmware opgrader dimmerne med seneste firmware. Problemet med unlink kan også løses med en firmware opgradering af dimmerne. Jeg måtte firmware opgrader mine dimmer 3 gange med samme firmware før mine dimmer blev stabile og jeg igen kunne unlinke dem. De har nu kørt i snart 6 mdr. uden problemer. Når du firmware opgrader dine dimmer, så vælg firmware opgrader ALLE dimmer. Af en eller anden grund bliver problemerne ikke løst hvis man vælger at firmware opgrader dimmerne en af gangen.

Hvis du kan linke og firmware opdater LED dimmerne er det ikke slutmodstanden som er problemet. Den bør være der, men er ikke 100% nødvendigt hvis dit bus kabel er under 1M fra controller til fjerneste dimmer. Simmulering sker offline. Jeg har aldrig rigtig brugt det, men jeg ved at der er problemer med tilbagemeldingen på andre produkter i simulerings mode. Om det også er tilfældet med LED dimmer ved jeg ikke, men vil ikke undre mig. Med serviceview kan du se status på ind og udgange, samt sætte begge manuelt. Her sker det live direkte på det kørende program i controlleren. Serviceview kræver Java, så hent en Javastarter, så du slipper for at rode med div. Java problemer. Check tråden "Login mislykkedes" i FAQ sektionen. Der er link til 2 forskellige Java starter.

8 leder er nok til et tryk med 4 afbryder og 2 dioder, hvilket der som regl er flest af. Et 8 leder kabel til hvert tryk gør det nemt at skifte tryk hvis man får andre ideer til sin installation, hvilket jeg gør forbavsende ofte. Sammen med klemmerække krydsfeltet, gør det fysiske ændringer nemme uden at det samtidig kommer til at se rodet ud. Og ja det er en ekstra fejl kilde, men det er samtidig også en ekstra mulighed for at skilde instalationen ad og teste de enkelte dele uafhængig af hinanden.

Jeg bliver helt misundelig. Gid min tavle så sådan ud. Vedr. klemmer. Det er ikke overkill. Det gør fejlsøgning MEGET nemmer. Skulle jeg selv lave min IHC installation fra grunden igen, ville jeg sætte tavler af til klemmer, så jeg kan lave et krydsfelt af stærk og svagstrøms klemmer, samt andre tavler hvor jeg har alle IHC modulerne. Jeg har for mange stedder hvor jeg bruger ledninger fra både input og output moduler, hvilket giver en meget rodet installation i min tavle. Specielt fordi jeg har 2 controller grundet mængden af I/O moduler. Med krydsfelt metoden kan jeg nememr ændre på den fysiske installation rundt i huset, hvilket jeg gør forbavsende ofte. Vedr. link-10 kabel. Hvis din installation ligger i rør, så du kan skifte kablet, vil jeg give dig ret, men på den anden side. Det billigste svagstrøms kabel man kan får idag er ofte PDS netværks kabel med 8 leder. Det funger fint til LK IHC.

Er der nogen som kan hjælpe mig med OpenHab konfigurations linier som jeg kan bruge tlf f.eks. at læse udsugnings temperaturen fra mit Nilan ventilations anlæg? Jeg har haft lånt en Nilan gateway boks og derigennem verificeret at modbus virker på det kabel jeg har tilsluttet anlægget, men jeg kan simpelthen ikke gennemskue hvordan jeg læser f.eks. udsugnings temperaturen via min USR-DR302 gateway eller USR-TCP232-410s gateway (kun en er tilsluttet af gangen). Håber nogen kan hjælpe med nogle konfigurations eksempler.

Som jeg skrev tidligere. Enhver røgsensor på marked som har et galvanisk adskilt relæ eller tilsvarende kan bruges. Det eneste krav til røgsensoren er at den kan afbryde forbindelsen mellem 0V og en LK IHC indgang når alarmen går. Hvis den også har en sabotage kreds er det perfekt, men ellers kan man bare samle de 2 sabotage ledninger i røgsensoren hvis de overhovedet er i brug. Men LK har faktisk sendt en erstatning på marked. https://www.lk.dk/produkter?iid=11272 Om den passer ind i de eksisterende sokler ved jeg ikke.

Har du et link til en reset firmware for Visual 3 controller?

Det er relativt nemt at afgøre om det er et Java krypterings problem eller ej. Brug en af følgende 2 metoder. 1. Hvis man får login fejl ved brug af ServiceView eller AdminView via USB er det et Java krypterings problem, da der ikke skal bruges bruger ID og password ved login via USB. Dette gælder også for Visual. 2. Hvis man kan logge på via Visual, men ikke ServiceView eller AdminView er det et Java krypterings problem. Dette gælder både for login via USB og netværk. Løsninger og workarounds til Java krypterings problemet findes i Login problem tråden i FAQ foraet. Der findes også links til et par IHC stater i den tråd. Bemærk iøvrigt at LK's IHC stater ikke altid virker medmindre man har installeret nyeste Visual 3. Der ligger nogle IHC stater rettelser i denne pakke som LK ikke har frigivet af andre kanaler. Mikkel's IHC starter har jeg også selv haft problemer med. Jeg havde dog ikke tid til at undersøge det nærmer dengang, så problemet kan have haft andre årsager.

Jeg har ikke HUE, men umiddelbart vil jeg gætte på at HUE app'en ikke kommuniker med hverken LK IHC eller IHC Captain når du bruger den til at styre dit lys med. Derfor er det mere tænkeligt at det er kommunikationen mellem LK IHC og IHC Captain som svigter. Når IHC Captain ikke kan læse programmet fra LK IHC controlleren, kan jeg somregl godt bruge ServiceView eller AdminView, men ikke LK IHC Visual. Eftersom problemet kan løses ved at genstarte IHC controlleren, skyldes problemet højst sandsynligt en overbelastet eller tilsandet LK IHC controller.

Jeg oplever fra tid til anden at min IHC Captain installation ikke kan hente programmet på min IHC controller før end jeg har genstartet controlleren. Jeg tænker derfor på om det kan være kommunikationen mellem IHC Captain og IHC controlleren, som svigter hos dig.

Sporadisk genstart er desværre et kendt problem med LK IHC. Nogle firmware versioner er værre end andre, men problemet eksister på samtlige controller versioner hvad enten det er TermIHC, Visual 1, 2 eller 3. En sporadisk genstart slå dog ikke alarmen fra hvis programmet er lavet rigtigt.

1) Korrekt. Såfremt at IHC app og home assist er på det samme logiske netværk, bør du kunne bruge netværks informationerne fra din IHC app, til at tilgå IHC controlleren fra home assist. 2) Hvis Java er blevet opdateret på din PC siden du brugte den sidst kan det meget vel være årsag til at det ikke længere virker. Hvergang Java bliver opdateret overskriver den alle konfigurations ændringer du måtte have lavet.

Hvis du fjerner linket før du fysisk fjerner sabotage kredsen, så bør indgangen i FB'en forblive ON, også efter genstart og uden at du gør noget. Hvis FB'en er lavet korrekt, vil default på FB indgangen allerede være ON, men det er værd at checke via ServiceView om default kan ændres eller ej og hvis den kan, sæt den til ON bare for at være sikker. Hvis FB indgangen af en eller anden grund går OFF, så bør alarmen gå i igang, men hvis default er ON, og indgangen er ON når du sletter linket, bør dette ikke kunne ske.

Hvis jeg forstår dig ret, så vil du ændre i FB'en. Det bør ikke være nødvendigt. Det bør være nok at slette linket mellem sabotage indgangen i FB'en og den fysiske sabotage indgang. Alt efter hvordan FB'en er bygget op, kan det være nødvendigt manuelt at sætte FB indgang ON første gang controlleren genstartes efter at linket er slettet.

Det grundlæggende problem er sandsynligvis de gamle udløbne certifikater som LK bruger i deres software. De giver så forskellige fejl alt efter hvordan du forsøger at tilgå controlleren. Hvis du kan forbinde med IHC app, så er der netværks forbindelse til din IHC controller, og du skal lede efter den manglende forbindelse mellem din home assist installation og IHC controlleren. Jeg har ikke selv home assist, men andre har fået det til at virke ved at bruge HTTP i steddet for HTTPS i home assist konfiguration. Dermed omgår man de udløbne certifikater. Alt efter hvordan dit lokal net er strikket samme, kan det også være et netværks problem mellem din IHC controller og home assist installation. Prøv evt. at bruge WAN addresse både med og uden WAN port nr'et. Husk også her at bruge HTTP i steddet for HTTPS. Din problem med IHC administrator kan dels skyldes at du har en controller uden viewer. HW 6.1 fandtes i 2 udgaver. En med viewer og en uden. Man kan kende forskel da der på den med viewer står IHC Visual controller / Viewer, mens der på den uden kun står IHC Visual controller. Hvis den er med viewer, så er det sandsynligvis et java krypterings problem. Hvordan du løser det kan du læse mere om i tråden "Login mislykkes (Java problemer)" i FAQ fora'et. Admin view og service view er ikke noget man installer på sin computer. Det er Java programmer som downloades hvergang og afvikles direkte uden at blive installeret. Det er imidlertid de færreste browser som idag understøtter afviklingen af Java direkte. Man er derfor nød til at gemme Java programmet og starte det manuelt bagefter. Her kommer java starter til hjælp da man så ikke skal bruge en browser for at download og starte Java programmerne. Men der står også mere om Java starter i den tråd jeg henviste til tidligere.