Lars1

MD5 er som sådan ikke et Java problem. MD5 er en HASH algorithme, som bruges til at verificer om der er blevet ændret i data under transporten mellem klienten og serveren eller omvendt. Protokollen er imidlertid tilbage fra 80'erne, og derfor er den for let at knække med de computer vi har idag, hvilket kan resulter i at en ondsindet person, kan opsnappe data pakken, ændre indholdet og sende den afsted igen med en ny MD5 HASH værdi. Modtageren vil da ikke være i stand til at se at indholdet i data pakken er blevet ændret. MD5 bruges også i forbindelse med FTP overførsel af filer etc. Hvis du følger de guides jeg har lagt på ovenover, så burde det ikke være nødvendigt at skulle ændre Java version afhængig af hvilken FW version din kunde bruger. Men bortset fra det, så vil jeg nok som det første opgrader til FW 2.7.199 på en HW 6.1 controller og FW 2.8.4 på en HW6.2 controller. FW uploaderen kræver ikke Java, så det burde være relativt simpelt at gøre, også slipper du for mange af problemerne.

Visual2 2.8.6 kom da sammen med FW 2.8.3, så det er da kun FW'en som er ny eller er det mig som er helt galt på den?

Ja det er ganske rigtigt simpelt at gøre, men det har LK valgt ikke at gøre, ligesom de har valgt ikke at opdater resten af deres SW til moderne standarder. Derfor som jeg har skrevet efterhånden mange gange. Når man arbejder med LK IHC, skal man glemme alt hvad man ved om moderne IT systemer og SW, og tænke som man gjorde i det forrige århundrede. Det er den måde LK IHC fortsat funger på.

Jeg mindes ikke at jeg nogensiden har skrevet at LK har sagt at det er muligt at bruge en gammel FW loader. Det er alm. kendt at FW versions checket først kom med i firmware loaderen i forbindelse med at LK stoppede supporten af HW6.1. Før da var der ingen grund til at checke FW versionen. Det er muligt at det er flere årtier siden at du har set sådanne problemer med firmwares. Du glemmer bare igen at LK IHC bygger på et design, teknologier og metoder, som alle stammer tilbage fra 80'erne. Alt udvikling siden da har været fokuseret omkring lidt web/app adgang og lidt HW opgradering når det ikke længere var muligt at skaffe mere af det forældet HW de bruger. Det grundlæggende design, teknologier og metoder er fortsat dem som blev fastlagt i forbindelse med TermIHC tilbage i 80'erne.

Helt ok. Det er muligt at uploade FW 2.8.3 i en HW 6.1 controller hvis du bruger en firmware loader fra Visual 2.6 eller tidligere. De supporter jeg har talt med hos LK siger dog at det vil få controlleren til at crashe på en måde så det ikke vil være muligt at loade en ny firmware igen. Men med alt det løgn vi bliver fyldt med fra LK tvivler jeg dog på at dette er korrekt, men det er meget sandsynligt at HW 6.1 controller ikke kan køre med en FW 2.8.3.

Det er korrekt at FW 2.8.3 kræver HW6.2 men da du ikke tidligere har nævnt hvilket HW du har og jeg ikke er tanke læser, så var det lidt svært for mig at tage din HW i betragtning. Men bortset fra det, var mit indlæg også skrevet med en smiley.

Jo hvis du opgrader til firmware 2.8.3. :-)

Søg på "Java problemer igen igen" og følg vejledningen i tråden.

Der er flere tilsvarende produkter, men problemet med de fleste er at de er propriotær, og ikke kan tale med andet end deres egne komponenter. KNX og EIB er undtagelser, men de er pænt dyre i forhold til IHC, og mere beregnet til store kontor bygninger eller industri anlæg. Jeg ved ikke hvor du har fra at der overhovedet skulle komme en ny controller. De gange jeg har hørt om en ny controller, har det været dybt upålidelige trejde hånds rygter fra en som kender en, som kender en, der tidligere har arbejder hos LK og har rygtet fra en som vistnok stadigvæk arbejder der, men i en afdeling langt fra nogen som kan andet end stave til LK IHC.

Jeg er bange for at du snart ikke har noget valg hvis du vil fortsætte med home control fra LK/Schneider.

Jeg tvivler meget. KNX er en bus teknologi målrettet industrien og store kontor bygninger, hvor man gerne kan tage 25-50% mere end hos private. Der er helle ikke meget at bruge div. apps. etc. til i de installationer. Deres house control er målrettet private hvor apps. og kommunikation via IP tæller langt mere end det gør i industrien og store kontor bygninger.

Rådgiver informations aften bliver holdt med ujævne mellemrum. Hvis der kommer noget godt nyt vedr. IHC i forbindelse med det informations møde, så vil det være første gang det er sket.

Jeg kender ingen dato, og jeg kender ingen som har andet end rygter fra en som vistnok arbejder hos Schneider. Med andre ord. upålidelige rygter som indtil videre alle har vist sig at være falske.

Et eller andet sted i en af trådene om ny LK IHC controller, ligger der et link til en reklame video om Schneider's House Control. Ud over det har de KNX, som dog mere er beregnet på industri, men som også funger fint i boliger, specielt hvis det er større boligere, da KNX ikke har samme begrænsning i antal enheder som LK IHC.

Der har været flere rygter de senest 3-4 år, men hvergang er vi endt med en lang næse. Jeg tvivler stærkt på at der nogensinde kommer en ny controller.

Jeg tvivler stærkt på at der overhovedet kommer nogen ny controller. Schneider har idag andre produkter, som dækker marked, og LK IHC er trukket ud af alle markeder, bortset fra DK, såvidt jeg er orienteret.

Jeg tvivler stærkt på at der overhovedet kommer nogen ny controller. Schneider har idag andre produkter, som dækker marked, og LK IHC er trukket ud af alle markeder, bortset fra DK, såvidt jeg er orienteret.

Og i hvilken forbindelse er det interessant for udstyr, som gerne skulle leve +30 år?

Nu er den forventede levetid for LK's IHC moduler +30 år, så at dine har overlevet +10år kan ikke rigtig bruges til at vurder om jeg har ret eller ej.

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.