Lars1

Java bruges ikke i Visual, så jeg tvivler stærkt på at det er det som er årsagen til at det virker. Hvis du har rebootet din PC i forbindelse med at du opdaterede Java, kan det være rebooten som har løst problemet, eller det kan være at der er gået langt nok tid efter du har stoppet IHC Captain m.m. til at IHC controlleren har fået rydet sin backlog af IHC Captain req.

Jeg tror mere dit problem har været at din controller har skiftet til en anden krypterings algorithme, og det har dine klienter ikke opdaget før du har refreshet deres konfiguration.

Visual bruger ikke Java, så det hjælper ikke at læse Java tråden, og trådstarter skriver netop at admin og service view virker som de skal. Jeg gætter på at du bruger trejde parts integration ala IHC Captain eller tilsvarende. Prøv at stoppe de og se om du ikke får adgang igen.

The issue with upgrading the radio interface and the stop at 80% is 2 different issues. I would try downgrading to 2.7.199, remove the power to the controller for at least 10 sec. and then try to upgrade to 2.8.4. For some reason it looks like the controller doesn't boot correctly. There should not be N/A in RF version and RF serial when you look at the admin view.

På serversiden kan du kun understøtte en version af algorithmerne, så her skal man vælge. Firmware version. 2.7.x og ældre understøtter kun de gamle algorithmer. Firmware 2.8.x og nyer understøtter kun de nye algorithmer. På klient siden kan man sagtens understøtte flere algorithmer. IOS, Java, IHC Captain, OpenHab etc. har i flere år understøttet både de gamle og nye algorithmer samtidig. Det er først inden for de sidste par år de er begyndt at droppe de gamle algorithmer.

Prøv at søg der hvor reset firmware ligger. Jeg mener de firmware loader som kan uploade reset firmware er uden versions check.

Det er jeg ikke enig. Det eneste IOS11 har gjort er at disable support for forældet krypterings standard som ikke burde have været i brug i flere år. Deruover gør IOS11 ikke andet end hvad Java gjorde for et par år siden da de droppede supporten af MD5, men i Java kan du reenable MD5. Jeg ved ikke om IOS11 har samme mulighed med det som er blevet disablet i den. TLS 1.0 er bare et trejde eksempel på en forældet krypterings algorithme, som ikke længere supporteres, og som LK også var længe om at skifte væk fra.

Så må du prøve at finde en endnu ældre firmware loader. Jeg kan ikke huske hvornår det var LK begyndte med versions check.

Det er nok nærmest ligegyldig hvilken firmware være du vælger. Problemet er at de stærke krypterings nøgler/certifikater som IOS11 kræver lægger meget load på CPU'en og dermed gør controlleren ustabil, især når den bruges med 3 parts integration via API'et i controlleren. Jeg tror ikke der er anden vej. Der er for mange variabler som har indflydelse på resultatet, men du burde kunne få en idee om det vil virke eller ej hvis du vurder din installation på nedenstående parameter. Stærk eller svag kryptering. (før eller efter firmware 2.8.x) Stærk kryptering giver mere load på CPU'en. 3 parts integration via LK IHC api'et. 3 parts produkter læser typisk samtlige parameter i programmet hvergang de poller. Dette giver selvfølgelig ekstra arbejde for CPU'en da hver parameter skal polle individuelt, og der skal svare på hvert poll individuelt. Mange parameter i dit program, incl. flag, interne parameter etc. Specielt hvis du har 3 parts integration via API'et giver dette ekstra load på CPU'en. Temp sensor hvad enten disse er med gulv føler, lux måler eller fugt måler. Disse sender en bit strøm gennem en on/off indgang. Dette belaster CPU'en. Benyttes Zigza senso sendes der informationer til controlleren 10 gange så ofte som med LK's sensor. Der er ikke en af ovenstående som giver problemer alene, men når de bruges i kombination, så er det problemerne opstår.

Læs tråden Java problemer igen igen igen. Der står svar på dine Java udfordringer, og hvad du skal gøre for at kunne bruge den seneste Java version sammen med LK IHC.

Det stik som skal skiftes, kan ligeså vel være i fordeleren ved vejen, men kan også være noget filter som skal monteres for at give routeren et mere rent signal at arbejde med. Desværre får vi dødelige mindre og mindre adgang til de tekniske detaljer, og first line supporterne ved INTET udover hvordan man opretter en sag. Jeg har gennem længere tid skændtes med TDC. Jeg vil vide hvorfor de ikke kan bundle mine 2 tlf. linier, så jeg kan få 50mbit på min internet forbindelse. Deres hoved fordeler for området står for enden af min grund, og alligevel påstår de at mine 2 linier ikke ligger parallelt, men vil ikke fortælle hvor de terminer eller hvordan linie føringen er fra mit hus og til første fordeler punkt. Somme tider påstår de at der kun er 1 linie til mit hus, og det på trods af at begge linier har været i brug samtidig på et tidspunkt.

IOS11 krypterings understøttelse kom med i 2.8.1 såvidt jeg ved. Det står der ikke direkte, men det var såvidt jeg ved, den ændring, som gjorde at LK ikke længere ville supporter HW 6.1. I 2.8.4 røg brugen af MD5 certifikater, hvilket løste problemer med manglende support for MD5 i Java. Jeg har dog ikke nærstuderet IOS11 ændringen, så jeg ved ikke præcist hvad det er de har droppet at supporter. Men LK henviser altid til deres seneste firmware, også selvom problemet reelt vil være løst med en tidligere firmware. Kryptering er en jungle. Der findes mange forskellige algorithmer, men de har alle det fælles træk at de baser sig på krypterings nøgler eller certifikater. Når man for 20 år siden talte om stærk kryptering var disse nøgler eller certifikater ofte på 256 bit. I dag supporteres 256bit nøgler eller certifikater stortset ikke. Når man idag taler om stærk kryptering er disse nøgler eller certifikater på 1024 bit eller mere. Jeg har fornylig set et req. på et 2048 bit certifikat. Hvergang du tilføjer en bit, fordobler du antallet af mulige kombinationer, så du kan selv gætte på hvad det gør ved en CPU når den skal krypter eller dekrypter, selvom den kender nøglene eller certifikaterne.

Primært udløbne certifikater. Prøv at kigge i tråden Java problemer igen igen igen. Der plejre jeg at beskrive hvad der er nyt i de enkelte firmware versioner.

Igen. Bare fordi det virker på 1 controller, er der ingen garanti for at det virker på alle andre controller i alle situationer som LK supporter. Og LK har jo 3 parts integration med bl.a. B&O (eller har i hvert fald haft).

USB driveren bliver installeret samtidig med at du installer Visual, men den kan også installeres alene. Jeg ved dog ikke hvor du lige hvor du finder driveren uden Visual og alt det andet.

Nu melder historien jo ikke noget om hvor stabil controlleren er, om han har 3 parts produkter etc. Så det er svært at sige om det vil virker for andre, bare fordi det ser ud til at virke for ham. Præcis som med en HW 6.2 controller. For nogen er den stabil for andre er den ikke, selvom de køre samme firmware og controllerne er fra samme serie. Jeg har ikke selv lagt 2.8.4 på min HW6.1 controller, og har ingen planer om at gøre det, og har ingen idee om den vil overleve. Men du kan jo prøve på din. Uden viewer, burde der være større chance for at det virker end med viewer, bortset fra at det jo selvfølgelig kan være den manglende viewer i nogle HW 6.1 controller, som er den relle årsag til at LK ikke længere kommer med ny firmware til HW 6.1. Jeg tvivler dog stærkt på dette.

Hvor mange A lever den nye strømforsyning?

Hvis det kun er firmware loaderen du har problemer med, så er det ikke Java som driller, men derimod USB driveren.

RF versionen bliver opgraderet med firmware 2.7.199, men der er en serie HW 6.1 controller hvor dette ikke kan lade sig gøre, og jeg er bange for at din er blandt dem. LK ombyttede dem en overgang, men er stoppet med dette igen såvidt jeg ved.

Det er såmænd ikke så svært. Du skal bare have fat i en af de gamle firmware loader, som ikke laver versions check før de uploader firmwaren. Det er den samme du skal bruge hvis du vil uploade en reset firmware. Disse bliver også blokeret af de nye firmware loader Jeg kan ikke huske hvilken firmware loader der skal bruges, men den som følger med 2.7.199 mener jeg er nok.

Jeg forstår stadig ikke din pointe. Bortset fra enkelte detaljer er den eneste forskel på en HW 6.1, HW 6.2 og HW 7 controller mængden af RAM og CPU. Hvornår du ramme loftet i de enkelte controller afhænger mange faktore. Firmware er en af dem. Dit program er en anden. Typen af enheder du har tilkoblet samt dit brugs mønster er en trejde. Integration med trejde parts produkter er en fjerde. Du kan sikkert selv finde på flere. Hvornår du rammer loftet på en HW 6.2 afhænger af din kombination af bl.a. ovenstående faktorer. Jeg tror ikke der er nogen som kan forudsige hvornår man rammer loftet.

Jeg forstår ikke din pointe, så jeg tror vi stopper den diskution her.

Jeg kan ikke huske om der er versions check i 2.7.110, så med firmware 2.8.4 skal du sandsynligvis på Visual 2.8.6. Der vil ikke være nogle problemer med dansk/svensk. Jeg har selv flere gange skiftet mellem den danske og engelske visual udgave.

Nedgrader til 2.7.199. Den synes at være stabil, og kan hentes på LK's website. Du vil dog miste supporten for temp/lux og temp/fugt sensor. Hvis du ikke har nogen af dem, er der kun Java som kan give dig problemer, men der kan du finde workarounds i tråden Java problemer igen igen igen.

Med HW 6.1 har du jo kun de gamle kryptering algorithmer, som kan knækkes af en alm. standard hjemme PC på under 1 time. Det er begrænset hvor meget load de lægger på en CPU sammenlignet med de algorithmer som er standard idag, og som det tager år for en alm. standard hjemme PC at knække.