Lars1

En af fordelene ved IHC er at det er nemt at lave om på. Hvis man samtidig har sørget for at alle forbindelser fra tavlerne og til forbrugs/aktiverings stedet er trukket i rør, har man en virkelig fremtidssikret løsning. Hvis vi taler et alm. parcelhus, så overstiger bøvlet med installation, ombygning og fejlfinding klart fordelene ved decentrale tavler, så jeg stemmer helt klart for den løsning som Bjarne har valg. I/O moduler på loftet vil jeg klar fraråde. Det er elektronik og elektronik kan ikke lide temperatur svingninger. Du kan nemt reducer levetiden på et I/O modul med op til 25% ved at placer det på loftet fremfor i et bryggers hvor der er en rimelig konstant temperatur.

Jeg tror det er dig som ikke fatter pointen, som ellers er ganske simpel logik. Vi er mennesker og vi løser gerne dagens udfordringer forskelligt. For mig er det f.eks. underligt at nogen gider sætte livet på spil for at nå toppen af et bjerg. Jeg kan ganske simpelt ikke se noget formål med det, ligesom du ikke kan se noget formål med at skulle styre Philips Hue via en app. For dem som forsøger at nå toppen af et bjerg er begrundelsen ofte fordi de kan. Anden begrundelse behøver man egentlig ikke, og samme begrundelse er valid når det kommer til Philips Hue og styring via en app. Jeg synes nu nok at jeg svare, men jeg gider altså ikke gentage mit svar bare fordi du ikke er enig eller forstår hvad jeg skriver.

Det afhænger lidt af hvad dit problem er. Hvis det er USB driver relateret, så følg guide download workaround som du bl.a. finder her. http://www.lk.dk/support/professionel/ihc-software Hvis det er Java relateret, så søg efter tråden Java problemer igen igen igen. Den indeholder løsninger på alle kendte Java og krypterings problemer.

Du behøver ikke spilde tid på at psyko analyser min morfar. Du rammer alligevel bare forkert, eftersom du ikke kender andet til ham en de 2 linier jeg har skrevet i denne tråd. Hvorfor han synes fjernbetjeningen var noget pjat er heller ikke vigtig. Pointen er at vi mennesker er forskellige og lægger vægt på forskellige ting i et bruger interfacet. Nogle synes at det er vigtigt at alt kan styres med en app, bare fordi de kan, og så er det egentlig ligegylidigt at det tager 4 gange så lang tid, som at lette røven og gå over og trykke på knappen ved døren.

Hvis ellers dem som udvikler produkter til Java, sørgede for at opdater deres produkter og brugte de rigtige udviklings metoder, så er Java faktisk et rigtigt godt cross platform OS. Hvis sikkerheden i windos var ligeså høj som i Java, så ville du have stort set lige så mange problemer med stortset alle programmer på din windos PC som du har med LK IHC og Java. Edit: Glemte lige at skrive at MD5 og udløbne certifikater ikke er et Java specifikt problem, men derimod et HW problem. Controlleren har ganske simpelt ikke CPU krafter nok til at håndter mere moderne krypterings algorithmer og certifikater med mere end 256bit nøgler.

Dette indlæg bliver det sidste fra mig i denne diskution. Vi ser grundlæggende forskelliget på verden og kommer med en meget forskellig baggrund. Vi bliver aldrig enig om vi så fortsætter diskutionen i 100 år. Prøv at læse mit forrige indlæg igen, Der er flere eksempler på hvad smart-house kan, som LK IHC ikke kan. Tja. Vindmåler bruges allerede idag til automatisk at indrulle markiser med. Regnmåler kunne f.eks. sammen med solsensoren bruges til at afgøre hvornår dit automatiske have vandings anlæg skal køre. Det er kun fantasien som sætter grænser, men jeg begynder at forstå at du er meget fokuseret på hvad man kan idag, og ikke rigtigt kan forstille dig at det kan gøres anderledes eller at der er nogen som har andre behov end dig. Nilan har faktisk dokumenteret deres modbus kommunikation, og der findes et modbus interface til en rasberry PI såvidt jeg husker, så det er bare at gå igang. Jeg kan ikke huske om det var her eller på et rasberry fora jeg så en tråd om modbus kommunikation via en Rasberry. Sålænge der er forskellige producenter af home automation, ligeså længe vil der være forskellige kommunikations standard og API'er. Sålænge de bare ligesom Nilan dokumenter hvordan man kommuniker med deres produkter, ser jeg det faktisk som en fordel, da det er med til at drive udviklingen fremad, at producenterne ikke er låst til en oldnordisk kommunikations protokol som f.eks. den LK benytter i LK IHC. Da den blev udviklet var den state of the art. Men det var også før 100Mbit Ethernet overhovedet var på tegnebrædtet. I dag findes der datacenter som bruger bundlede 100GBit forbinderlser i deres backbone. Herunder er min definition på home automation. Der står intet herunder som jeg ikke har skrevet mange gange før. Noget af teksten er faktisk kopieret fra tidligere indlæg jeg har lavet. Mit syn på home automation er meget lig at lege med lego. Du har en masse byggeklodser, hvor nogle passer samme og andre ikke gør og sommetider skal du bruge en bestemt type klods for at få 2 andre klodser til at passe samme. Men sat rigtigt samme kan de danne imponerende konstruktioner. Home automation er alt som kan automatiser en process i dit hjem. Disse produkter kan i større og mindre grad integreres så de kan udnytte hinandens funktioner og dermed til sammen øge graden af automation i dit hjem. Hvorvidt denne integration sker via en cloud løsning, en central enhed i dit hjem, eller autonomt mellem de enkelte produkter er ligegyldig. Hvor avanceret din home automation i dit hjem er, er bestemt af hvilke home automation produkter du har valgt og hvor godt du har integreret dem. Et hjem hvor der ingen home automation er, hvilket vil sige ingen kaffe maskine eller vaske maskine og hvor lyset tændes ved at trykke på en 230V afbryder er 0% automatisert. Et hjem hvor der ikke er brug for mennesker overhovet, er 100% automatiseret, men hvad er formålet med det hjem? Hvorvidt en process er semi eller fuldt automatiseret er en akademisk diskution. IMHO så er en process hvor alt forgår manuelt som f.eks. at skære brød med en manuel brød kniv 0% automatisert, mens at hvis du bruger en el kniv, er det x% automatiseret. Om du sætter x til 1 eller 99 vil jeg lade være om til dig. 100% automatiseret opnåes igen først når vi mennesker kan undværes 100%, hvilket meget ofte er det samme tidspunkt hvor processen bliver ligegyldig, for der vil ikke længere være noget menneske til at få glæde af den. Bare tag eksemplet med en selvkørende bil, som køre rundt uden passager. Vi har opnået 100% automatisering, men samtidig har vi overflødig gjort processen. Bruger interfaces et det som vi mennesker bruger til at aktiver og styre vores home automation med. Det kan være en app på din telefon, et web interface, en funktion i alexa, en knap på vægge etc. Fælles for dem alle er at vi bruger dem til at styre vore home automation med. Hvorvidt vores handling medføre en enkelt handlig i et enkelt home automation produkt, eller det resulter i en lang række handliger i en lang række home automation produkter, afhænger af graden af integrationen af home automation i dit hjem. App'en til at styre Philips Hue med, er bare første generations bruger interface til det produkt. Jeg er 100% overbevist om at i løbet af nogle år vil vi se mange andre måder at styre Philips Hue på. En rejse tages bedste 1 skridt af gangen. Sensore som f.eks. temp. sensor, PIR eller lux måler er som udgangs punkt ikke bruger interfaces. Edit: I forbindelse med at styre Philips Hue via en app, kom jeg lige til at tænke på dengang min morfar fik hans første fjernsyn med fjernbetjening. Han synes det var noget pjat med sådan en dims, så de næste mange år rejste sig troligt for at skifte program eller tænde/slukke for fjernsynet. Hvad der er noget pjat for den ene, er smart for den anden.

Jeg stiller ikke spørgsmål ved din defination. Den giver bare ikke mening for mig, og derfor stiller jeg spørgsmål til hvordan den skal forståes i en række meget realistiske hverdags senarier, hvor nogle af dem måske først er aktuelle om 5-10 år, men fortsat fuldt realistiske. Hvis din defination skal holde vand, skal den kunne holde denne slags krydsforhør. Hvis jeg forstår dig ret, så mener du at automatisering som f.eks. tøj vask, kaffe brygning etc. er automation som sker i hjemmet men ikke home automation, mens lysstyring, varme styring etc. er home automation? Hvis dette er korrekt, hvad er det så når du integrer på tværs af det skel, som f.eks. at kaffe brygningen automatisk starter når en sensor registrer at du er på vej op, eller at dit vægge ur er integreret med din brødbagnings maskine og din lysstyring, således at brødbagningen starter 1 time før vægge uret ringer og lyset i huset tænder når vægge uret ringer? Google, Amazone etc. definer netop home automation, som alt der kan automatiseres i dit hjem. I den forbindelse definer de kaffe maskiner, vaske maskiner etc. som produkter på linie med produkter som Philips hue, LK IHC, KNX, EIB, etc. Produkter som de kan integrer via deres Alexa etc. Hvis du spørger 100 personer om deres defination vil du sikkert få 200 definationer. Jeg har flere gange skrevet at jeg betragter alt hvad der automatiser en eller anden process i mit hjem som komponenter i home automation, herunder kaffe maskiner, vaske maskiner, lys styring, varme styring, LK IHC, IHC Captain etc. Til sammen danner de min home automation, hvad enten de alle er integreret med hinanden, eller integreret i mindre uafhængige grupper. Siger du hermed at i lande som f.eks. Kina, hvor en vaske maskine IKKE er en selvfølge i alle hjem, der er en vaske maskine at betragte som home automation, mens at den i den vestlige verden hvor den er en selvfølge, ikke er home automation. Hvis dette er sandt, så har vi et stort problem, for så vil vi aldrig kunne få en international defination på home automation, hvilket er ret problematisk i den globaliserede verden vi lever i. Hvornår vil en bil være fuldautomatisk i.flg. din defination? Når den kan køre selv uden passager? Skal den også selv kunne tanke sig, vaske sig etc? Hvad med lyset. Hvordan kan det være fuld automatisk, når det ikke selv kan skifte en defekt pære? Hvorfor skal varmestyringen ikke selv tage højde for udefrakommende årsager for at være fuldautomatisk. Vi har big data teknologier, som baseret på historiske data om dine vaner og aktuelle vejr data vil kunne forudsige ret præcist hvornår du vil ændre på temperaturen. Alle vejrudsigter er bygget på modeller som er baseret på enorme mængder historiske vejr data. Vi mennesker er (desværre) meget mere forudsigelig end vejret. Prøv at sætte dig lidt mere ind i Smart-house, så vil du finde en lang række funktioner, som LK IHC ikke har, som f.eks. et tidssvarende slutbruger interface, fungerende tavle dimmer, som kan styres på %, energi forbrug overvågning og muligheden for at bruge disse data i programmet, vejr sensore, til regn, vind og sol. Jeg ved godt at LK langt om længe er kommet med en LUX måler, men de mangler fortsat regn og vind målerne. Det var bare nogle af de ting som LK IHC mangeler i forhold til SmartHouse. Nu du nævner Nilan. Her er det faktisk LK IHC, som er problemet. Nilan har en standard modbus på deres system print. Det er denne, som den eksterne PLC i LK's integration kommuniker med, men fordi at kommunikationen mellem LK IHC og PLC'en sker via on/off signaler på standard I/O moduler, så kan man ikke overføre temperatur, fugt niveau etc. som ellers alle er tilrådighed via Nilan Modbus'en. Om Velux har en Modbus ved jeg ikke. Jeg har aldrig rodet med deres systemer. I steddet for den tumbede PLC integration, kunne LK jo bare have lavet et IHC modbus modul, som kunne tilsluttes IHC controlleren ligesom SMS modem'et eller via Ethernet API'et. Dermed havde de også åbnet LK IHC for integration med andre modbus produkter. Bare se på Visility board'et PLC integrationen blev valgt fordi den ikke kostede noget i HW udvikling, og var relativt simpel at lave. At den ikke løser opgaven, er lige gyldigt for LK, for LK IHC er et dødt produkt som LK ikke har satset på i mange år.

Kan du komme med eksempler på noget i dit hjem som kan lave automatisering, men som ikke er home automation? Selvfølgelig er alt i dit hjem hvor et produkt overtager en funktion som du ellers skulle udføre manuelt home automation. Selv en kaffe maskine er et home automation produkt i en eller anden grad. Den varmer vandet og brygger kaffen for dig mens du laver noget andet. Men jeg giver dig fuldstændig ret. Det er første når de kan integreres med andre home automation produkter at de bliver rigtig interessante. Det er jeg lodret uenig i. Begge produkter er home automation under den samme defination. Der er bare MEGET stor forskel på hvad de kan bruges til og hvilke funktionalitet de kommer med, men de er begge home automation produkter, og de kan i den grad sammenlignes, når man sammenligner funktionaliteten lystyring. Hvis du sammenligner på andre funktionaliteter vil Philips Hue tabe med et brag da den ikke har disse funktionaliteter, præcis som LK IHC taber med et brag på flere områder hvis du sammenligner det med f.eks. smarthouse og Loxone, simpelthen fordi LK IHC ikke har de funktionaliteter. Men Smarthouse og Loxone er måske mere korrekt home automation end LK IHC? Hvis man følger din defination, så er KNX og EIB systemer ikke home automation systemer, da de baser sig på at logikken ligger i de enkelte komponenter, og virker selvom den centrale styreenhed er slukket. Begge systemer kan langt mere end LK IHC når det gælder home automation, men de er også en pæn del dyre, selvom det burde være umuligt. Bare fordi det er helt i tråd med LK IHC betyder jo ikke at LK IHC har patent på at define home automation. Det svare lidt til at sige græs er grønt, ergo er alt grønt græs. Jeg har aldrig påstået at LK IHC ikke er home automation. Det er det i allerehøjest grad, men der er også MANGE andre produkter som er home automation, men eftersom begrebet er relativt nyt, så har de ikke været benævnt som home automations produkter før. Det betyder dog ikke at de ikke er home automation produkter. Nu begynder du at blande integration af home automation produkter sammen med home automation produkter. Vaskemaskinen er et home automation produkt. Fryseren er også omend en primitiv form for home automation. At vaskemaskinen kan sende en besked til konen om at lette måsen og få hængt tøjet op ændre ikke noget. Tidligere blev dette gjort ved en hyle tone. Hvis det nu sker via Alexa eller noget andet som overvåger vaskemaskinen og sender beskeden til konens smartphone er bare en anden brugergrænseflade til den samme funktion. Her blander du bruger grænseflader sammen med home automation. En Smartphone/table er ikke home automation. Den app. som ligger på dem kan godt være det, men Smartphonen er værdiløs some home automation uden en app. Hvis man skal følge din logik, så er LK IHC ikke home automation uden windows PC, da det er umuligt at programer controlleren uden den, men controlleren køre fint uden PC'en når først den er programeret. En Smartphone og en PC er ikke home automation. De programmer der ligger på dem kan godt være det. Hvad er din defination på forkert automatisk styring? Alting udvikler sig. Det som idag sker semi-automatisk som du beskriver det, kan meget vel ske fuldautomatisk i morgen. I min gamle bil skal jeg selv huske at tænde og slukke lyset. I min nye bil sker det automatisk. Jeg kan også få en automatisk gearkasse til den, fartpilot som selv kan tage farten af og bremse hvis jeg kommer fortæt på de foran kørende, sidespejle som selv klapper ind når jeg stopper motoren, men jeg skal fortsat selv styre den. Er min nye bil rigtig eller semi automatiseret? Det eneste som ikke udvikler sig er LK IHC, og der er MANGE mangler. Det er muligt at du ikke synes det mangler nogen, men der er mange indlæg her på boardet fra personer som mener noget andet. Dertil kommer at du ofte selv brokker dig over den måde som tingene gøres på i LK IHC. Problemet er bare at det var state of det art for 10-20 år siden da LK IHC blev udviklet, men eftersom LK IHC stortset ikke er blevet videre udviklet de sidste 10 år så er det selvfølgelig håbløst forældet idag og mange funktioner etc. virker tumpet.

Jeg ved ikke lige hvad du mener med " (det er ikke IHC +10 år gammel, siger du)" Jeg har aldrig påstået LK IHC ikke er home automation. Det er det helt klart, og det mener jeg også burde være tydeligt med denne sætning "For +10 år siden var det at sammenkoble 2 forskellige home automation systemer via API'er bane brydende. LK gjordet dette sammen med B&O, så man kunne styre sit B&O anlæg fra LK IHC og omvendt". Her står der jo netop at både LK IHC og B&O BeoLink er homeautomation og at de var frontløber på integration via API'er. Home automation er alt hvad der automatiser dit hjem. B&O har lavet home automation via deres BeoLink. Velux har lave home automation via deres automatiserede vindues styringer. Smarthome, loxone o.s.v. er mere komplet avancerede home automation systemer. LK IHC er home automation, selvom det er forældet og dødt. IHC Captain er home automation, som kan bruges til at integrer forskellige typer home automation. OpenHab er et andet exempel. Amazones Alexa og googles pendant er andre eksempler. Det er muligt at de ikke lige kan integrer med dit home automation system, men de kan integrer med andre. En smartphone eller tablet er ikke home automation. Det er et bruger interface lige som en afbryder er. ZWave, Blutooth og Wifi er ikke home automation. Det er kommunikations protokoller som bruges til at integrer forskellige former for home automation.

Firmware upgrade er rimelig sikre. Der er nogle få controller, som har en hardware fejl, som gør at firmware upgrade ikke kan lade sig gøre, og nogle controller hvor IO og radio modulet ikke kan opgraderes. De køre fint alligevel, og LK bytter dem ikke længere såvidt jeg ved. Du går bare direkte til 2.7.199. Det er kun hvis du skal over 2.7.199 at der er en afhængighed af at gå på 2.7.199 først. 2.7.199 er en fuld funktionsdygtig firmware, så du kan rolig blive på den selvom om LK og andre skriver den kun skal bruges til klargøring til 2.7.220.

Jeg køre selv kun med windos 7, så jeg ved ikke lige hvordan det ser ud på windos 10. På min computer er JAVA_HOME=C:\Program Files (x86)\Java\jre1.8.0_131\ Hvis du prøver at starte Java control panel på din computer, kan du i Java faneblade trykke på view. Herefter får du en oversigt som fortæller hvor dine forskellige Java versioner ligger på din computer.

Prøv nu at læse hvad jeg skriver. Jeg påstår på intet tidspunkt at produket er dødt bare fordi det er +10 år gammelt. Jeg påstår at det er dødt fordi der ikke er sket nogen videre udvikling, og at produktet på ingen måde er tidssvarende. Du har selv brokket dig højlydt over den tumpet måde som LK IHC funger på set med dagens øjne. For +10 år siden var det state of the art. Resten du skriver herover dokumenter jo også bare at produktet er håbløst forældet. For +10 år siden var det at sammenkoble 2 forskellige home automation systemer via API'er bane brydende. LK gjordet dette sammen med B&O, så man kunne styre sit B&O anlæg fra LK IHC og omvendt. I dag er det fortsat den eneste reelle home automation integration der eksister fra LK's side på LK IHC. Andre produkter er langt foran på det punkt nu, og integrer til højre og venstre over internettet, med og uden cloud løsninger o.s.v. Der er ikke noget nyt i at når der opstår nye markeder, så kommer der i starten mange forskellige standarder, som ikke umiddelbart kan arbejde samme. Det skete med video båndne. Der var den gamle standard, som DR brugte (kan ikke huske navnet), Video2000 som teknisk set var det bedste, betamax og VHS. VHS var teknisk set det ringeste, men Sony kunne spytte VHS afspiller ud i 1000 vis til næsten ingen penge, så de vandt. Hvis du kigger på bruger administation i IT verden, så havde hvert produkt i 2004 sin egen user DB, og der eksisterede ikke tools som kunne synkroniser disse på tværs af produkterne. m$ havde deres AD, men det fungerede kun med m$ produkter, og ville slet ikke snakke sammen med LDAP, som ellers var ved at blive en open standard. IBM havde lige frigivet første generation af Tivoli User Admin, som kunne synkroniser bruger samme på tværs af Mainframe, Unix og officielt Lotus Notes. Lotus Notes plugin'et viste sig dog at være skrevet af nogen som ikke kendte Notes, og var så smækfyldt med fejl at det blev trukket tilbage fra marked 2 mdr. efter jeg havde rapporteret den første fejl. Kerberos protokollen var i sin vorden, men den fungerede kun på web løsninger, og kun hvis de kørte på en m$ IIS server. I 2004 skrev jeg et automatisert bruger admin system for en kunde. Det kunne baseret på ændrigner i en HR database oprette, nedlægge og skrifte password på bruger på tværs af 4 forskellige specifike software produkter fra 4 forskellige leverandør. Opdateringen tog 1 time for ca. 3000 bruger og blev køret 1 gang dagligt, men det var et kæmpe skrift fra at ændringer blev skrevet ud og faxet til de forskellige sys admins for derefter manuelt at blive opdateret i de 4 target systemer. I 2008 kom IBM med Tivoli Identity Manager. Et produkt som meget lignede det system jeg byggede i 2004, men det kunne klare jobbet på 10 min. og det kunne scheduleres til at køre 1 gang i timen døgnet rundt. Det kom out of the box med connector til 50 forskellige software produkter, og havde en script engine så man selv kunne lave yderlige connector. Idag har du over 50 produkter, som kan federer dine user directories på tværs af alverdens platforme. De gør det i real time og kan uden problemer håndter +100.000 aktive bruger. LK er tilsammenligning på +10 år kommet med support for fugt/temp og lux/temp. sensor. Hvis ikke det er et dødt produkt, så ved jeg ikke hvad der skal til for at kalde et produkt dødt. Inden for Home automation findes der i dag et hav af forskellige produkter som kan integrer forskellige home automation løsninger med hinanden. Dertil kommer at flere af de store spiller gør meget for at integrer med andre produkter. LK er tilsammenligning på +10 år kommet med support for deres egne fugt/temp og lux/temp. sensor. Hvis ikke det er et dødt produkt, så ved jeg ikke hvad der skal til for at kalde et produkt dødt.

Prøv at dobbelt checke om det er den rigtige linie i java.security du har fjernet md5 fra. Det skal være jdk.jar.disabledAlgorithms. Der er mindst en anden linie som hedder nogenlunde det samme, men den ændre ikke noget. Der udover bør du checke at det er den rigtige java.security du retter i og at du rent faktisk får gemt ændringerne. Nogle Java opdateringer får f.eks. ikke slettet de gamle biblioteker, og hvis du køre windows 7 skal du sikkert køre din tekst editor via run as admin.. for at få lov til at gemme dine config ændringer.

Skriv http://usb i URL'en i din browser, så kan du komme på admin view og rette password etc. Når den spørger efter password og du er på via USB trykker du bare enter. Der er ikke noget password når du er på via USB. Hvis du får problemer med Java, eller får fejl som forkert password etc. via USB, så check tråden "Java problemer igen igen igen" Den indeholder workarounds til alle kendte problemer med Java. Hvis det er HW6.1 vil jeg anbefale 2.7.199. Du bør under alle omstændigheder lægge 2.7.199 i før du evt. går til 2.7.220, men 2.7.220 løser ingen problemer længere, og synes at være mere ustabil end 2.7.199.

Hvorvidt et produkt er dødt eller ej, har intet at gøre med hvad vi hver især savner. Det har ene og alene noget at gøre med om der sker en videre udvikling. Verden omkring os tager mega skridt hvert år. For 10 år siden var en internet forbindelse med 2Mbit download noget af det ypperste man kunne få. Jeg er ikke engang sikker på du kan få en internet forbindelse med mindre end 3Mbit upload idag. Biler er gået fra at små personbiler med 75HK motor kunne køre over 20KM/L til at en Audi A3 med en 150HK motor kan køre over 21KM/L. LK IHC er på de samme 10 år kommet med et par firmwares, som retter nogle fejl, og fornyer nogle certifiketer 6 mdr. før de udløber igen samt support for temp/Lux måler og temp/fugt måler. LK IHC er jvf. normal terminologi dødt, og så er det egentlig ligegyldigt om du savner noget eller ej. Der sker INGEN nyudvikling i LK IHC. Produktet er på final livsforlængende support.

Føleren bør ligge lige mellem 2 varme slanger, og så højt oppe som muligt. Det er der du får det mest præcise målepunkt for temperaturen i din gulvvarme. Bare værd opmærksom på at jo højre føleren ligger, jo laver skal du sætte max temperaturen, da der er en vis forsinkelse fra varmen fra varme slangerne når føleren.

Hvis ellers du ikke har nogle problemer med din IHC installation, så betyder de 2 fejl ikke noget. Vi andre lever fint med dem.

Det er en fejl som sometider optræder. LK vil ikke rigtig ud med hvad det er, men når jeg har set den, passer det med tidspunktet for hvornår min controller er genstartet af sig selv. Det er dog langt fra ved hver genstart at jeg kan se fejlen. Som du kan se er datoen på fejlen nogle dage gammel (17/5-2017), så fejlen er ikke opstået i forbindelse med firmware upgraden. Det lader til at du har en controller, hvor IO og RF ikke kan opdateres.

Den gamle firmware han køre med pt viser desværre ikke RF og IO version. Det kom først med i en senere firmware. Præcis hvilken kan jeg ikke huske, men det var kort før 2.7.199

Ikke andet end at det højst sandsynligt er en HW6.1 controller, og du derfor ikke bør gå højre end FW 2.7.199. Når du har lagt denne FW i, vil du se yderlig info der hvor dit screenshot er taget.

Sorry. Det var lidt sent i går. 2.3.586 er selvfølgelig ældre end end 2.7.199. Du bør løfte den til 2.7.199, og ikke længere. Hvilken Java fejl får du. Der er jo desværre mange forskellige. Der er en fejl som ikke er beskrevet, og som gælder for ældre firmware. Det er TLS kryptering. Ældre firmware supporter kun TLS 1.0. Man skal derfor fjerne support for TLS 1.1 og 1.2 i Java for at disse fungere. Der er ikke rigtig nogen fare i firmware update. Enkelte controller har en fysisk fejl, så firmware update ikke kan lade sig gøre, og jeg er ikke sikker på at LK længere ombytter disse. Jeg har heller ikke nogle informationer om hvilke serie der er tale om som er i fare zonen.

Prøv med http://usb i en browser og åben så adminview. Her kan du rette password, se firmware og HW versioner etc. Hvis din controller er 8 år gammel, er det sandsynligvis en HW6.1, og så kan du ikke lægge firmware 2.3.586 i den. HW 6.1 supporter max 2.7.220, og hvis du har en meget gammel FW i den, skal du starte med at lægge FW 2.7.199 i den. Personligt vil jeg forblive på 2.7.199, da den synes at være mere stabil end 2.7.220. Skulle du få Java fejl m.m., så følg rådene i tråden "Java problemer igen igen".

LK IHC HW 6.1 er +10 år gammelt. Det er længe før USB 2.0 blev defineret. LK IHC controllerens USB port fungere som et netværks interface med en fast defineret IP adr. og som Martin skriver er LK IHC USB driveren bare en netværks driver til en USB port. Præcis som jeg har en netværks adapter til en parallel printer port liggende. Den var meget praktisk for 15 år siden hvor netværk interfaces i en PC ikke var standard, mens parallel printer porte var. Forbind adaptoren og installer driveren og du kunne komme på det lokale LAN.

??? Hvis den ikke skal opfattes som en netforbindelse hvordan kan det så være at man kan pinge controlleren når den er forbundet til computeren med USB kablet. Prøv selv at skrive ping USB når du har tilsluttet din controller til din computer via USB.

Takker. Har nok brugt over 1 time på at søge efter den. :-(