Lars1

Nu ved jeg ikke lige hvilken fejl du får, men firmware 2.7.220 kan bringes til at køre med alle Java versioner. Har selv 2.7.220 på den ene af mine controller. Det er stadigvæk en gangbar løsning at gå tilbage til update 66, men prøv at fortællle hvilken fejl du får, så kan det være at vi kan hjælpe dig med at finde den korrekte rettelse. Omkring MD5. Har du så fjernet den fra jdk.jar.... eller jdk.certpath....? Det er den første som er den korrekte.

At fjerne MD5 fra jdk.certpath... løser ingen ting. ServiceView etc. er .jar filer så du skal fjerne MD5 fra jdk.jar.disabledAlgorithms

Du søger her på boardet efter tråden "Java problemer igen igen". Den indeholder beskrivelse af hvordan du løser problemerne med de forskellige Java versioner.

Nope. Den ændring der skete i update 131 kræver at du går i fil systemt og manuelt retter i en config fil. Det vil være dejligt hvis den kunne løses via GUI, men det kan den desvære ikke. Det problem Lucifer beskriver stammer fra update 71 og 101. Check selv Java tråden.

Det er en alm. tekst fil, så alle tekst editor kan åbne filen, men hvis du køre windows 7 eller højre kan det være nødvendigt at starte tekst editoren med admin rettigheder for at kunne få lov til at gemme filen efter du har rettet den.

Det problem som Lucifer løser er ikke det samme som det der er opstået med update 131. Men de er begge beskrive i Java tråden.

Java 8 update 131 kan også bringes til at fungere. Bare kig i Java tråden hvordan det gøres.

Jeg er interessert i dine 230V og 24V output moduler, samt div. fortråede tryk. Hvad skal du have for det? Afhentning i KBH er ikke noget problem.

Afhængig af dit IHC program sættes rampetider og min. lysstyrke enten i programmet eller i dimmeren selv. Jeg har dog ikke meget erfaring med LED's på LK dimmer, så jeg tør ikke love at dit problem kan fikses 100%.

Det står alt sammen i tråden "Java problemer igen igen igen". Jeg opdater den løbende når der kommer nye FW eller Java versioner. Der er forskellige problemer alt efter hvilken kombination af Java og FW du har. Men kig i tråden. Alle kombinationer kan bringes til at virke pt. Den seneste Java version er dog den mest besværlige, men i tråden er der også et link til hvor du kan finde ældre Java versioner (Såvidt jeg husker)

Well. LK IHC bygger på HW og teknologier fra før 2006. Dengang var kravene til home automation noget lavere. En af grundene til at vi ser flere autorestart med de nyer firmware er at krypterings algorithmerne m.m. lægger mere load på processorerne end de gjorde for 10 år siden. Dertil kommer at der er MEGET mere støj i form af broadcasts på netværket idag. LK IHC TCP/IP stacket er fra det forrige år hundrede og ikke opdateret siden. Den er LANGT mere følsom over for netværks støj end moderne IP stacks.

Lidt afhængig af hvordan dit program er skrevet, og hvordan genstarten sker kan det godt lade sig gøre i nogle tilfælde. Når min controller genstarter, er det ikke hvergang lyset blinker. Specielt udgange hvor som man har programeret til at huske instillingen ved genstart synes at være gode til at holde lyset uden blink.

Det er egentlig ligegyldigt hvad vi mener. Schneider har flere gange officelt udtalt at en daglig uplanlagt genstart ikke er et problem. Indtil nogen får en højre myndigheds ord for at dette ikke er korrekt, er det det som gælder.

Hvorvidt et produkt virker, afhænger jo af hvordan man definer virker. I.flg. Schneider er en auto genstart med 3-14 dages mellemrum ikke noget problem. Så jvf. dem virker deres produkt.

Vær opmærksom på at nyeste firmware er 2.7.220 for en controller fra 2006, og at du skal opgrader til 2.7.199 før du går på 2.7.220. Personligt vil jeg kun opgrader til 2.7.119, da denne firmware synes at være mere stabil end 2.7.220. Eneste forskel på 2.7.199 og 2.7.220 er support for fugt og lux sensor, men dem har du næppe i en installation fra 2006.

Den fejl du har i dit screenshot tyder meget på problemer med den nyeste Java version. Der ligger en beskrivelse af hvordan problemet løses i tråden "Java problemer igen igen igen"

Jeg tror dit unable to launch application problem, skyldes Java problemer. Prøv at søg efter "Java problemer igen igen" eller noget i den stil. Så vil du finde en tråd hvor alle kendte Java workarounds er beskrevet i første indlæg. Jeg har opdateret det for mindre end 1 uge siden. Alternativt kan du tage strømmen til controlleren i 10 sek. Hvis du har batteri backup, skal du lige huske at tage den fra også.

Oracle har released Java 8 update 131, og i den forbindelse disablet support for MD5 certifikater. Dette er ikke godt nyt, da hverken HW6.1 eller HW6.2 contollerne har nok processor kraft til andet end MD5 certificater. Workarounden til problement er beskrevet her

Der er flere grunde. Hvis du har 230V indbygnings spots, kan dimmeren ikke sidde i loftet. De er nemmer at komme til når der er problemer med dem. Det er nemmer at lave om på når fruen ændre møbleringen.

Eller læse villedningen. Mener der står hvilken ramme LK anbefaler man bruger. :-)

Strømforsyningen kan have betydning, for din teori har et problem når man kobler 2 master tastatur sammen. Hvilket af de 2 master bliver master når du tænder for strømmen. Jeg tvilver på at de har noget lokations kenskab, så om Mads's tastatur bliver sat på din installation hos dig, eller dit tastatur bliver sat på Mads's installation hos ham er ligegyldigt, hvis det gøres mens strømmen er slukket. Da emnet var oppe og vende sidst, mener jeg der var en som skrev at det LK gør er at koble tastaturet sammen med et nyt, og dermed overskrive koderne. Jeg har ikke ledt tilbage. Vi taler igen om teknologi, som er +10 år gammel, så jeg tvivler stærkt på at der er forskel på om admin koden er default eller ændret, i forhold til om koderne kan overskrives når man tilkobler et tastatur mere til sin installation.

Alt hvad jeg skrev er ud fra hukommelsen, og jeg har ikke selv haft brug for at nulstille et tastatur så jeg har aldrig efterprøvet teorien. Umiddelbart vil mit bedste gæt være at det er når man taster admin koden at der sker en ændring, og at det tastatur man taster den på vil funger som master. Men jeg har ingen dokumentation for dette. Det burde imidlertid være simpelt at efterprøve, hvis der er en som har en installation med 2 sammen koblede kode tastatur og kender admin koden. Alt vedkommende skal gøre at ændre en af koder på hvert tastatur. Hvis det andet tastatur modtager ændringen er der en god chance for at master/slave forholdet afgøres hvergang man taster admin koden. Hvis vi følger din teori. Hvad vil der så ske hvis du tager strømmen til din installation, tilføjer Mads's master kode tastatur og sætter størm på igen? Kommunikationen mellem controleren og kode tastaturne er jo ens for alle tastaturne, så controlleren kan ikke se forskel på dem. Master/Slave forholdet skal derfor afgøres mellem tastaturne selv.

Såvidt jeg husker behøver man ikke sende tastaturet til LK. Man skal bare låne et tastatur hvor man kender admin koden, og sætte dette i serie med de andre tastatur. Man skal følge vejledning for tastaturne nøje, da masteren vil overskrive koderne i de andre tastatur, så hvis man ikke får sat det nye tastatur på som master vil det nye tastatur få de koder man ikke kender, fremfor at de eksisterende tastatur får en masterkode man kender.