Lars1

Jeg kender ikke certifikat datoerne på FW 2.7.163, men Java certifikatet i 2.7.220 er udsted i 2007 og løber til 2027. TLS certifikatet er allerede udløbet. Det gjorde det såvidt jeg husker mindre end 3 mdr. efter firmwaren blev releaset.

1. Personligt har jeg fortrudt at jeg ikke placerede alle mine wireless lampeudtag ved tavlen. Det er simpelthen for bøvlet med wireless lampeudtag i loftet, når der er problemer med dem, og alt der skal bruges for at placer dem ved tavlen er måske et ekstra kabel. En anden fordel ved dette, er at det er nemt at skifte et wireless lampested til et alm. eller den anden vej, hvis alle aktive komponenter er samlet ved tavlen. 2. Det er ganske få stikkontakter jeg har som jeg vil styre via IHC, og de få jeg har, har jeg valgt at bruge wireless IHC stikkontakter, som er godkendt til 13A modsat LK's IHC moduler som kun er godkendt til 10A. Men til lys bruger jeg 230V IHC moduler. Her er der heller ikke noget problem med de max 10A. 3. Jeg vil ligesom Lars Jacobsen overhovedet ikke overveje coax antenne kabler, medmindre du har en parabol og satelit modtager. Cat6a er dog ofte nok, men ikke altid. Det vigtige er at kabler og stik er godkendt til 1000MHz. Det er langt de fleste cat 6a kabler og stik, men du skal op i cat7a for at være sikker på at de alle er. Personligt kan jeg rigtig godt lide LK's IHC net tavler, da de giver en simpel og struktureret patchning. Men bruger man ikke LK's switch og antenne moduler forsvinder værdien hurtigt. LK's IHC net basis vil jeg aldrig bruge. Tiden er løbet fra 100Mbit netvæk i hjemmene og man kan nemt finde en pæn patch terminerings box, som er langt billigere end IHC net basis.

For at få "almindelige" folk til at adopter IHC/Home automation, så skal det være simpelt at bruge. For at det bliver simpelt at bruge, kræver det at funktionaliteten er reducert til få standard funktioner, som man så kan "mappe" mellem de forskellige enheder. Funktioner, som f.eks. sluk alt er nemme at lave og vil dække 90% af hvad "alm." folk gerne vil have når de køber produktet. Men når man begynder at tilføje betingelser, bliver det pludseligt komplext, og det tror jeg ikke nogensiden "almindelige" folk vil kunne overskue. Med betingelser, tænker jeg på f.eks. at lyset ikke må kunne tændes hvis indbruds alarmen er aktiveret, eller slukkes hvis brand alarmen er aktiveret. Men bortset fra det, så er jeg 100% enig. En ny controller skal have mulighed for at integrer med andre produkter, og dette bør ske via funktions API'er, så hr og fru danmark kan selv kan lave simple integrationer og os nørder får adgang til mere komplexe integrationer.

Glem fælles standarder. De høre 80'erne til og er forældet når de endeligt er vedtaget. I dag integrer man mod API'er og her er fælles standarder ikke nødvendige, sålænge at API'et er veldokumenteret. LK bruger selv denne metode til at integrer med B&O. Open Hab, Domoticz og Visility boardet benytter denne metode til at integrer mellem forskellige produkter, som på papiret ikke kan arbejde sammen, og det med stor success. Der er ingen grund til at en ny IHC controller (tror stadig ikke på den kommer) ikke skulle kunne det samme. Jo flere trejdeparts produkter dit produkt er integreret med, jo større er dit marked. Men det kræver selvfølgelig at arkitekturen i din controller er designet til at supporter 3 parts integration, hvilket LK's IHC controller egentlig er. Den er bare blevet overhalet af manglende dokumentation af API'et, manglende udnyttelse af arkitekturen, for lidt processor kraft, og satsning på en teknologi (Java), som desværre ikke viste sig at være langtids holdbar.

Siden du ved der bliver kørt test på den, burde du også kunne skaffe spec samt andre info om hvad den kan, og om den fortsat er bagud kompatibel med deres I/O moduler som bygger på en +40 år gammel kommunikations protokol. Kald mig bare negativ. men jeg har flere gange de sidste 10 år hørt rygter om en ny controller, men indtil videre har de alle været falske. Indtil jeg ser den nye controller eller noget dokumentaiton på at der rent faktisk er en ny controller på vej, betragter jeg også dette rygte som falsk. Skulle der virkelig være en ny controller på vej, så husk lige at tidsplaner normalt skal ganges med 2. LK tidsplaner skal normalt ganges med mindst 10, og det er ikke fordi deres test er særligt grundinge. Se bare på den seneste firmware og Visual version til HW6.2 FW2.8.1 blev released i september. Ikke engang 3 mdr. senere bliver der released en fejlrettet version.

Java certifikatet i 2.8.1 er udstedt i 2015 og gyldigt til 2035 såvidt jeg kan se. TLS certifikatet i 2.8.1 udstedt 3 Marts 2016 og er gyldigt til 3 Marts 2019. Begge certifikater har derfor en pæn rest levetid og det ligner ikke LK at være på forkant med certifikat opdateringer. Jeg har ikke haft problemer med Java siden jeg opgraderede til 2.8.1 Android kan jeg ikke udtale mig om. Jeg bruger ikke deres app. Problemet med 2 versioner af Visual på samme PC er blevet lidt bedre, men de deler fortsat en masse informationer, som gør at man ofter er nød til at reboote hvis man går fra en HW6.2 til en HW6.1 contoller eller omvendt. Ikke videre smart hvis man har både en HW6.1 og en HW6.2 controller i sin installation og man skal rette på controller link sammen koblingen.

Hvad er det for 2 fejl du referer til? Alle de 4 ting du nævner er jo "rettet" med FW 2.8.1/Visual 2.8.4

Well. HW 6.2 med nyeste firmware har pt. ikke problemer med Java. Men bortset fra det er jeg fuldstændig enig. Vi trænger RIGTIG MEGET til en ny og TIDSSVARENDE controller.

Taler du om LK IHC Wireless Standalone eller LK IHC Controller? LK IHC Controller er alt for komplex til at Hr og Fru Danmark nogensinde vil kunne forstå det. Præcis som med SmartHouse, Loxone, KNX etc. Men her er LK også faldet af vognen. Bare tag deres måde at koble 2 controller sammen på. Det er samme måde som blev defineret med den første IHC controller LK sendte på marked. Da de kom med deres Visual controller med net adgang, burde de også have gjort det muligt at sammenkoble 2 controller via nettet. De kom jo samtidig med et API for trejdeparts integration, så hvorfor ikke bruge det samme API til at sammenkoble 2 controller? Men det er jo egentlig et ret godt eksemple på at LK ikke har satset på deres IHC produkt i efterhånden mange år.

En af grundene til at du ser Philips Hue omtalt meget, er at hr. og fru danmark selv må lave hele installationen af Philips Hue. Det må de ikke med LK IHC, hvad enten det er Wireless Standalone eller controller udgaven.

Du kan ikke sammenligne den fulde IHC controller installation med Philips Hue og tilsvarende. Philips Hue kan du sammenligned med LK IHC wireless standalone uden controller, og selv denne teknologi er 10 år gammel, og ikke ændre siden, så heller ikke her er de fulgt med tiden. Det er ikke længere nok at du kan tænde/slukke/skrue op/ned via en kontakt hvis du vil have dit produkt i et byggemarked. LK IHC med controller kan du sammenligne med SmartHouse, Loxone etc. Finder du nogle af disse produkter i et byggemarked?

Alle 1Gbit porte er autosense, så her er et krydset kabel ikke nødvendigt, men bortset fra det har de fleste router LAN porte, som er switch porte. Jeg kan ikke mindes hvornår jeg sidst har set en hjemme router med en router port som kræver et krydset kabel.

LK's intentioner er snart 40 år gamle, og det er hele problemet med LK IHC. Det er ikke fulgt med tiden.

Har du prøvet at højre klikke og sætte logmærke i Visual? Når man gøre det, så bliver der logget i controller loggen såvidt jeg husker.

Der er ingen ISP'er som laver deres egne router. De bruger alle en standard router, som de så får sat deres navn og logo på.

Når du mapper en data linie til et produkt, tager du stilling til hvilken port på hvilket I/O modul produktet skal sidde. Når du ser f.eks. ser input datalinie 1.03, så er det input modul 1 indgang 3. Output datalinierne er nummeret på samme måde. Hvis ikke der er sat nummer på I/O modulerne, så følger du bare de parsnoede data og 0 ledninger fra I/O modulet til controlleren. Det nr. som står på den terminal på controlleren hvor lednigerne ender, er nummeret på dit I/O modul. Om det er et input eller output modul kan du se på modulet, men du kan også se det på controlleren. Input modulerne er mærket med en pil ind, og output modulerne er mærket med en pil ud. Alt dette står tydeligt i LK's dokumentation. Igen det er en snart 40 år gammel teknologi LK benytter, så man skal glemme alt hvad man ved om bus teknologier. Det hotte dengang var 10Mbit Ethernet på et tykt gult kable, hvor man anborede drops.

Din controller skal ganske rigtigt forbindes til en LAN port på din router eller netværks switch. Kablet som kommer ud af din IHC nettavle, er sandsyligvis det kable, som skal skaber forbindelse med switchen i din IHC net tavle og din router. Uplink porten på switchen sidder bag tavle afdækningen. Derfor kommer kablet ud på bagsiden.

Det er ikke en router, som jeg kender, så jeg kan desværre ikke hjælpe dig der.

Igen. LK's IHC er udviklet i 80'er og stortset ikke ændret siden. Der er kommet lidt wireless, basal netværks adgang og en mere visuel programering end den oprindelige term-ihc. men det er stortset det som er ændret siden den første version af LK IHC. Til dagligt bruger jeg aldrig dokumentations rapporterne fra Visual, men hvis jeg skal finde ud af om der rent faktisk er noget fysisk monteret på data linierne på I/O modulerne er datalinie oversigten guld, da den giver dig en oversigt sorteret på data linier, så du hurtigt kan sammen holde det med om der sidder noget på de fysiske porte på I/O modulerne. Vedr. dit skumrings relæ. Hvis produket er i Visual programmet, men der ikke er mappet en datalinie, så er der ingen forbindelse mellem produktet og et evt. fysisk skumringsrelæ. Det er længe siden jeg selv rodede med skumringsrelæet, så jeg kan ikke huske om det default er ON hvis produktet i visual ikke har forbindelse til det fysiske relæ.

Den findes i stortset alle router og FW's, men den har mange forskellige navne, og ikke alle er lige sigende.

LK IHC bygger stadigvæk på det grund design, som blev lavet tilbage i 80'erne. Rent faktisk kan du bruge det allerførste I/O modul LK lavede sammen med den seneste controller de har lavet. Men der er faktisk noget automatisk dokumentation, og det er den du skal sammenligne med hvad der rent fysisk er monteret i dine I/O moduler. Hver gang du tilføjer et produkt, og mapper det til en dataline, så bliver det registreret i dokumentationen, Den del kan selv den mest genstridige elektriker ikke komme uden om. Nederst i den dokumentations rapport som du kan få via Visual, er der en oversigt over alle dine dataliner, og hvilke produkter der er registreret på dem. Denne dataline oversigt skal du bruge til at finde de dataliner, hvor der er monteret noget, som ikke er registreret i IHC programmet. Du vil ikke kunne se hvad der er monteret, men du vil kunne se om der datalinier, som fysisk er i brug, men aldrig mappet til noget produkt. Omvendt vil du også kunne se om der er tilføjet produkter i programmet, som aldrig er blevet tilføjet fysisk.

Her er endnu en grund til hvorfor det er en god ide at have IHC tavlerne siddende så man kan komme til dem. Via Visual kan du udskrive den eksisterende dokumentation. Herunder bl.a. en liste over alle ind/udgange samt hvad det er brugt til (hvis elektrikeren har noteret det). Denne liste sammenholder du så med alle de ledninger som fysisk er monteret på I/O modulerne. Det er ikke utænkeligt at du har en PIR siddende, og at den faktisk er forbundet til din IHC tavle, men aldrig programeret, eller fjernet fordi den ikke virkede. Men hvis ikke der er et produkt på den indgang hvor den er monteret, vil du aldrig se noget i loggen, ligegyldigt om den virker eller ej. Sagt på en anden måde. Du har sandsynligvis indgange og udgange, hvor der fysisk er monteret noget, men hvor der ikke er noget produkt konfigureret i Visual. Disse ind/udgange vil du aldrig se i din log, selvom der var ændringer på dem.

Når du kigger i adgangskontrol via admin view, vil du se at under lokal netværk, har du mulighed for at vælge alt. Under internet kan du vælge alt, bortset fra admin view. I LK's verden er internettet alt hvad der ikke har samme IP subnet som IHC controlleren. I din router kan du nomalt lave en NAT regl, som konverter din public IP som du har når du sidder på internettet, til en privat IP på det samme subnet som IHC controlleren, og så tror den pludselig at du sidder på lokal nettet og så må du gerne få adgang til admin view. Hvad den NAT regl hedder i din router, afhænger af routeren. Sommetider er det hide NAT, sommetider source NAT, sommetider er det PAT, og andre gange er det noget helt trejde. Men fælles for dem alle er at de erstatter din source IP med en lokal IP, før de sender datapakken til IHC controlleren, og derved tror IHC controlleren at du sidder på lokal nettet, selvom du sidder og hygger dig på sol kysten.

Hvis du laver en NAT regl i din router, som skjuler alt trafik til IHC controlleren, bag routerens IP på dit IHC LAN interface, så tror IHC controlleren at du er lokal, ligegyldigt hvor du befinder dig. LK's IP implementering er fra før ruder konges tid. I admin view kan du sætte hvem der må hvad, afhængig af hvor de befinder sig. Eneste problem er at jvf. LK's definition, så er internettet alt som ikke er på samme IP subnet som din IHC controller, og det kan man ikke ændre på i IHC controleren.

I serviceview mener jeg også at man kan aktiver log på specifike ind/udgange, så man ikke skal være 2 for at teste om noget virker. Eller også aktiver man log via Visual, hvorefter det bliver man kan loggen i serviceview. Det er længe siden jeg har brugt den funktion.