Lars1

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.

Såvidt jeg husker var det alle controller som var omfattet, incl. IHC term. og tilbudet kom da de droppede supporten af Visual 1, hvilket først skete et par år efter HW 6.1 controlleren var frigivet. Måske er vi så heldig at se en kampange når Visual 2 supporten bliver droppet om 1 års tid, men næppe før.

Men det gør de jo ikke. IHCremote/tablet poller jo kun for de parameter som du har konfigureret dem til at polle for (såvidt jeg ved, har dem ikke selv), mens IHC Captain etc. poller for samtlige parameter hvergang. Hvert parameter req. skal krypteres, og så har du jo pludselig et pænt stort load på en HW 6.2 controller med de nye krypterings algorithmer, or det load bliver expotentionelt større jo flere parameter du har. Dertil kommer at temp./lux og fugt sensor bruger floating points til at angive deres værdier. Disse er væsentlig tunger at krypter end en on/off værdi. Hvis du bruger mange tekst værdier i dit program, øger du krypterings loadet endnu mere.

Pas. Jeg har aldrig prøvet, men det kan du jo prøve når du får din 6.2 controller monteret. :-) Nu supporter LK jo ikke trejdeparts produkter som IHC Captain etc. så jeg tivler på at dette har spillet en rolle da LK droppede HW 6.1 supporten og kom med de nye algorithmer i HW6.2 Hvorvidt en HW 6.2 er lige til øllet, tror jeg afhænger af flere ting, som f.eks. antallet af temp/lux/fugt sensor, komplexiteten i IHC programmet samt dit brugs mønster.