Lars1

Eller opgrader til nyeste FW. Den gør dog en del controller ustabile, men tilsyneladen ikke alle.

Dine problemer lyder en del anderledes end dem som de fleste af os her oplever. Jeg vil nok prøve med reset firmwaren først. Der er flere tråde her på boardet om den, og hvordan den bruges.

Der er en anden tråd om controller med FW 2.7.220, som genstarter med jævne mellemrum. Det ser desværre ud til at være en gammel fejl, som er kommet tilbage.

Som det fremgår af det link, som Anders har vedlagt er det ikke alle IHC controller, hvor RF modulet kan opdateres med firmware. Jeg har samme problem, og LK tilbød i forbindelse med frigivelsen af firmware 2.7.199 at ombytte min controller med en anden HW 6.1, af ca. samme alder. Betingelsen var dog at ombytningen skulle ske via en installatør. Dette sammenholdt med at jeg har 10 wireless dimmer/relæer siddende enten i +2,5M højde, eller bag en tung reol eller tilsvarene, gjorde at jeg takkede nej til det tilbud.

Hvilket nr. skal man ringe til? Det nr. jeg fandt på LK's website kan kun bruges af installatør fik jeg at vide da jeg prøvede.

Vil du løfte sløret lidt for hvad problemet var?

Det lidt pest eller kolera. Vil man helst have en ustabil controller, eller en controller, hvor man er nød til at gøre sin JAVA installation på sin PC usikker for at kunne logge på admin eller serviceview. Jeg håber virkelig at det er lykkes nogen af jer at trænge igennem til LK, så vi kan få en FW som er stabil, og hvor vi ikke er nød til at gå på kompromis med sikkerheden på vores computer for at kunne se hvad der sker i serviceview'et.

TLS fejlen er rettet i den seneste firmware fra LK. Den gør tilgengæl controllerne rimeligt ustabile, så det er lidt som at vælge mellem pest eller kolera.

Hvis i vil finde jeres internet IP, så gå på http://myip.dk/

Det er ikke uden grund at den generelle anbefaling er ikke at pakke sin tavle ind i et skab. Min sidder frit, men jeg bliver alligevel sommetider overrasket over hvor varmt der kan være inde i en tavle. På et tidspunkt prøvede jeg at bruge LK's tavle dimensionerings program, for at se hvor varmt der teoretisk bliver i tavlen, og selvom min tavle ikke er fuldt bestykket, kom jeg tæt på max temperaturen. Så hvis man pakker sin tavle ind i et skab, bliver problemet bare større.

Jeg kender ikke NetGear boksen, men umiddelbart ser din port forward rigtig ud. Har du været inde i IHC controlleren, og give adgang fra internettet? Jeg mener dette er disablet som default. Bemærk at i LK's terminologi er internettet ALT som ikke er på samme IP subnet som IHC controlleren. Hvis man gerne vil have samme adgang fra internettet (LK's defination) som lokal nettet, laver man bare en hide NAT i sin FW, således at alt trafik, som gå gennem FW'en for at komme til IHC controlleren får FW's IP adr. på IHC controlleren net som source. Herved kan IHC controleren ikke længere se forskel på om trafikken kommer fra lokal nettet, eller et andet netværk. Hvordan man laver hide NAT afhænger af den enkelte FW.

Med 43 grader i skabet, tør jeg slet ikke tænke på hvor varmt der er inde i tavlen hvor controllerens udluftning sidder.

Men det er jo netop det som portforward af 80 til 443 sikre i din FW. Derved kan du bruge port 80 i din app, samtidig med at din IHC controller svare på port 443. Din FW sørger for at indgående trafik på port 80 ender op på port 443 i din IHC controller.

Nu har jeg ikke selv app'en, så jeg ved ikke hvordan den er konfigureret, men hvis den ellers er kodet ordentligt, bør du kunne sætte port nr'et også. Normalt kan du skrive <IP/hostnavn>:<port nr>, men det kræver selvfølgelig at app'en er kodet ordentligt.

Er det lykkes nogen af jer at rapporter problemet il LK?

LK har nogle standard IHC pakker, og det er typisk dem der bliver installeret idag i nyinstallationer såvidt jeg ved. Disse indeholder også kun det mest nødvendige. Men det er ikke meget anderledes end en alarm pakke fra G4S eller hvad de nu hedder i denne uge. Deres standard pakker indeholder også kun lige det mest nødvendige. Pakkerne er små for at holde prisen nede, og få lokket kunder i butikken/abonnements fælden, så man efterfølgende kan flå dem.

Nu begyner vi at diskuter detaljer, men hvis du sidder på internettet, og har lavet en forward af port 80 til 443 i din FW, så svare din controller vel med HTTPS, også må det også være rigtigt at du spørger med https protokollen, men via port 80, hvilket er præcist det jeg har skrevet.

Det kan godt virke, men det kræver browseren understøtter at man skriver https://<IP/hostnavn>:80/ Det er ikke alle browser som understøtter dette. Nogle browser kan selv genkende at de får krypteret trafik på port 80.

Jeg gik lige og håbet at problemet med de evige genstart var gået i sig selv igen, men lang næse. I går omkring middagstid, mens alle var ude af huset besluttede controlleren sig for at genstarte af sig selv igen. Den har dog sat rekord. Den havde på det tispunkt kørt i næste 8 dage med den nye FW uden genstart. Hvordan ser det ud hos jer andre. Nogen ændringer i hvor ofte controlleren genstarter etc.? Nogen løsninger?

Det giver en billigere installation, da du ikke skal bruge så mange I/O moduler, og sålænge funktionen skal være den samme på alle afbryderne/kontakterne, er der ikke noget teknisk i vejen med at gøre det på den måde. Du får faktisk også et mere simpelt program ud af det, og dermed højst sandsynligt en mere stabil IHC controller, som ikke genstarter af sig selv i tide og utide.

Firmware før 2.7.199 supporter ikke TLS 1.1 og 1.2. Efter JAVA 1.7.0_71 (såvidt jeg husker) er TLS 1.1 og 1.2 default, og skal slåes fra manuelt for at IHC admin, service view etc. virker.

Er det stadig samme fejl vi skal lede efter? Efter næsten 7 mdr. vil jeg næsten forventen at du havde opdaget hvilken funktion der ikke virker. Men en never ending loop, må der jo næsten være noget som permanent står op blinker eller tilsvarende, når du får aktiveret loopet.

Bliv ikke overrasket hvis det pludselig holder op med at virke igen. Jeg har selv oplevet problemet et par gange, og der er virkelig INGEN logik i hvornår de wireless relæer tænder udgangen af sig selv, og hvornår de ikke gør det, når man har sparepære etc. siddende på dem, og belastningen når de er slukket ligger mellem 0VA og 5VA.

Der sidder afbryder på IHC wireless stikkontakterne, men du kan ikke bruge dem i dit program desværre. Wireless stikkontakter er kun modtager. Dog plejre tilbagemeldingen på udgangen at virke så man kan bruge denne til at afgøre om en wireless stikkontakt er tændt eller slukket. Det er dog ikke noget LK supporter, og der er ingen garanti for at det virker med alle fw versioner. Du kan evt. anskaffe dig en mobil wireless stikkontakt, og øve dig på den. Den virker præcis som de fastmonterede, men du skal ikke have fat i en elektriker for at udskifte dine eksisterende stikkontakter til wireless. De mobile fåes også som dimmer, og med eller uden jord. De faste fåes kun som relæ med jord. Tilgengæld fås de i flere farver end de mobile. Wireless mobil stikkontakt. http://billigihc.dk/lk/lk-ihc-wireless/stikkontakt/ihc-wireless-mobil-stikk-relae-m-j-1-stk Wireless fast stikkontakt http://billigihc.dk/lk/lk-ihc-wireless/stikkontakt/ihc-wireless-stikkontakt-13a-hvid-1-stk

Forskellen er face forskydninge i det du sætter på. Jeg har en 15W arbejdslampe med lysstof rør. Hvis jeg bruger den på en wireless stikkontakt, så går der ca. 5 sek. efter jeg har slukket den, før den tænder igen af sig selv. Og jeg har checket med en støvsuger at det ikke er programmet som der er noget galt med. Og det er det store problem ved minimums belastningen. Den gælder også for standby forbrug. Dit standby forbrug på en wireless stikkontakt skal være 0VA eller +5VA. Det værste af det hele er at LK har kendt til problemet siden 2007 eller tidligere, og har fortsat INTET gjort. :angry: :angry: