Lars1

Der er jeg ganske uenig. Bus forbindelser har været kendt længe før LK IHC kom på banen, og mange andre IHC systemer baser sig også på en stjerne arkitektur. IMHO vil der altid være et marked for begge, men produkter som ikke understøtter begge metoder vil få det svært. Dem som har behov for en elektriker til at sætte et svagstrøms tryk op i en stjerne arkitektur vil også have behov for det i en bus arkitektur. I forhold til hvad de brugte tilbage i 80'erne da de designede IHC er deres investering i IHC wireless begrænset. Bortset fra det ligger den investering over 10 år tilbage. Deres eneste investering i IHC wireless siden det blev lanceret er en ændring, så kommunikations modulerne i de wireless enheder har deres egen 0 i steddet for at a sidde i serie med belastningen. Noget som de burde have lavet fra dag 1. At lave et simple programerings sprog som Visual er ikke særligt svært. Det er faktisk meget tæt på at være en semester opgave på datalogi studiet. Bortset fra det, så er det lavet og stortset ikke udviklet i over 15 år. De opdateringer LK laver til deres controller er ikke anderledes end dem som du beskriver for en gateway. Udstillingen af produkter som KNX inputs og outputs ikke så simplet som det lyder til. Hver enkelt udstilling skal gennemtestes præcis lige så grundigt som at tilføje et nyt produkt i LK IHC firmwaren. Jeg kender ikke KNX særligt godt, men hvis det kan kommuniker via Ethernet, kunne man nemt udstille IHC produkterne via API'et på LK IHC controlleren. Det vil faktisk være nemmer end at lave en selvstændig KNX gateway som erstatter controlleren. På den måde burde man også kunne udstille funktions blokke som KNX inputs/outputs. Jeg tror mere og mere kommer til at køre over netværk. Jeg har arbejdet med IT i over 20 år nu, og mængde af lokale styrings systemer som bliver integreret på tværs af lokationer er stærkt stigende. Større firmaer har sågar oprettet lukkede netværks til disse systemer med begrænset adgang udefra. Dette skyldes at disse systemer idag kontroler fysisk adgang til bygninger, ventilation, lys o.s.v, o.s.v, o.s.v. Nogle af dem er baseret på KNX. Andre på mere propritære platforme lig LK IHC. Men fælles for dem alle er at sikkerheds opdateringer og generel hardning er en by i rusland. Da jeg arbejdede for IBM lavede vi en penetration test af adgangs kontrol systemet i forbindelse med at vi skulle forbinde 2 lokationer. Det tog omkring 15 min. at skaffe os kontrol over alarm sensorne, samt dør låsene. Nu skrev jeg jo også at LK IHC typisk er supporteret i mindst 10 år, præcis som stortset alle andre produkter til el-installationer. Siemens LOGO PLC'er er et klasse eksempel på dette. Jeg lavede svende prøve i 1999 på en LOGO ver. 1 (såvidt jeg husker). I dag har vi LOGO version 8. Hvergang der er kommet en ny version, er supporten på den gamle fortsat i nogle år for så at stoppe med kort varsel. Præcis som med LK IHC. Den største forskel at hvor LK IHC er bagudkompatible, er dette ikke tilfældet med Siemens LOGO. Hvis du kigger på KNX produkterne, er jeg ret sikker på at du vil se det samme. De enkelte produkter supporteres kun i 5-10 år. Fordelen her er dog at KNX er en integrations standard, så nye produkter vil kunne integreres med gamle, lige indtil der kommer en ny version af KNX, så kan du ende op i at der kun er delvis integration mellem nye og gamle KNX produkter hvis de overhovedet kan tale sammen. Amatør. Jeg har flere lukkede netværks hvor der er begrænset adgang ind og ud. Jeg stoler ganske simpelt ikke på IOT enheder, så jeg har et lukket net for mit IHC. Her befinder LK IHC controllerne sig, mit solvarme styring, data collectors etc. Et andet net er til mine multimedie server. Et trejde til mine multimedie klienter o.s.v. Ingen af disse net giver internet adgang for andet end NTP og DNS. Når enhederne skal firmware opdateres etc. åbner jeg for den adgang, mens jeg køre opdateringen. Herefter bliver der lukket igen.

Som jeg skriver. Stjerne og bus fobindelser har begge deres fordele og begrænsninger. De udelukker ikke hinanden. Men at skrotte den nuværende stjerne arkitektur til fordel for en bus arkitektur vil være hul i hovedet IMHO. Specielt fordi det er relativt nemt at tilføje moduler som understøtter en bus arkitektur. Når du skal loope mellem stik etc. kommer du hurtigt op på 100M. Mit hus er på 130kvm fordelt på 2 etager. Jeg har 2 controller da jeg har alarm, varmestyring etc. kørende i LK IHC. Jeg regnede på et tidspunkt på hvor mange dupline loops jeg skulle bruge hvis jeg skulle skifte til SmartHouse og jeg endte med 10 loops. Bortset fra det var det mere ment som et estetisk og kost indspark. Med de nuværende I/O moduler er der intet i vejen for at bruge en alm. fuga afb. til 80 kr. hvis du bare skal have et enkelt tryk ved en dør. SmartHouse og KNX tryk koster minimum 600 kr. og design mæssigt passer de ikke samme med resten af mine el-installationer. Jeg havde på et tidspunkt adgang til noget af LK's oprindelige dokumentation. Jeg tror faktisk det var en her på boardet som havde lagt det frem. Blandt det dokumentation var der en beskrivelse af hvordan man kommuniker med RS485 bussen, samt dokumentation for et analog 0-20mA output modul via RS485 bussen. Der var også et par andre moduler som aldrig blev til noget, men som vi savner meget idag. Jeg ved ikke hvor den dokumentation er idag, men måske er den blevet uploadet her på boardet. Jeg vil stille spørgsmåls tegn ved hvor stor LK's investering i deres LK IHC reelt er. Den var stor tilbage i 80'erne, men siden Visual 1 har den været begrænset til hvad der var nødvendigt for at holde produktet i live. Udviklings omkostningerne til en gateway er stortset de samme som til en fuld controller. Den basale SW er en standard embedded Linux platform. Event håndteringen skal du have i begge tilfælde, og der skal være et bruger interface i begge. I gatewayen for at man kan fejlsøge og i controleren for programering. Vedr. usupporterede controller så vil dette også ske med gateways. Produkterne bliver forældet med tiden. Bare se hvor hurtigt smartphones bliver udskiftet. Jeg er på min 3 firma telefon på 6 år, p.gr.af at tlf. producenten 2 år efter release ikke længere supporter deres telefoner eller frigiver sikkerheds patches til dem. LK supporter trods alt deres IHC controller i mindst 10 år efter relase. En gateway som erstatter LK IHC controlleren giver ikke rigtigt mening IMHO. I/O modulerne kan nemt erstattes med tilsvarende moduler fra KNX. Det vil kun være temp./fugt/lux sensor samt wireless som ikke vil være supporteret uden gateway, og jeg er lige ved at tror at det vil være billigere for mig at erstatte disse med KNX produkter end at invester i en gateway. Hvis der i steddet bliver lavet en gateway til LK IHC controlleren kan jeg tilføje de analoge output jeg mangler for at kunne flytte min solvarme styring over i LK IHC.

Der er fordele og ulemper ved begge metoder (stjerne kontra bus). En stjerne arktektur er simple, nem at vedligeholde, nem at ændre på, og hvis du får fejl på 1 komponent, så tager denne fejl ikke andre komponenter med i faldet. En bus arkitektur kræver ikke så mange kabler, men det kræver at man trækker et kabel rundt i huset som ofte max må være 100M. Den er ikke så nem at ændre. Specielt ikke hvis hvert loop er lavet næsten til grænsen. Har man en fejl på 1 komponent i et loop, vil det ofte betyde at hele loopet er nede, og det kan være en pain in the a.. at finde sådan en fejl. Rent teknisk har LK IHC faktisk en bus allerede. RS485 porten er en bus forbindelse, og der var intet i vejen for at lave et dupline modul eller tilsvarende, som kommunikerede med controlleren via RS485 bussen. Der er ingen grund til at skrotte de nuværende I/O moduler. Det er jo bare on/off signaler, og fordelen med de eksisterende I/O moduler er at hvis du kun skal bruge 1 afbryder ved en dør, så optager du kun 1 indgang, mens du med KNX, Dupline etc. ikke kan sætte andet end en afbr. med 4 tryk op. I mine øjne har LK IHC en stærk grund arkitektur, men produktet er reelt ikke blevet videre udviklet siden Visual 1 controlleren blev frigivet. Jeg synes det er stærkt at man i 2019 har et IHC produkt som er bagudkompatibel med produkter som stammer fra 80'erne. Det er bare sørgeligt at man ikke har videre udviklet det, og tilføjet dupline eller tilsvarende funktionalitet, tavle dimmer på bus, så de funktionelt ligner wireless dimmer. Personligt så jeg gerne følgende tilføjelser til LK IHC. Gateway modul så IHC installationen kan kommuniker med KNX. Det måtte gerne være en gateway, som gør at man kan bruge KNX moduler i sin LK IHC installation, og den anden vej rundt, hvor LK IHC optræder som en komponent i en KNX installation. Gateway modulet kan f.eks. kommuniker med LK IHC controlleren via RS485 bussen Tavle dimmer med samme funktionlitet som wireless. De kan f.eks. kommuniker med LK IHC controlleren via RS485 bussen. Dupline moduler, således at man kan bruge dupline komponenter i sin LK IHC installation. Modulerne kan f.eks. kommuniker med LK IHC controlleren via RS485 bussen. Det er denne metode SmartHouse bruger. Gateways til andre produkter efter samme model som ovenstående. Der er dog en væsentlig grund til at jeg tvivler på at vi nogensinde vil se en gateway til LK IHC. LK IHC overlever kun sålænge at LK kan sælge LK IHC HW komponenter. Hvis man laver en GW, åbner man for at marked for dimmer, temp. sensor etc. forsvinder, og så forsvinder økonominen i LK IHC for LK. Produktet kan ikke overleve på salg af controller alene.

Man kan kun være med i en kundegruppe. Du er i IHC kundegruppen, fordi du vil integrer hue, google home etc. med IHC. Dem der er i hue gruppe har generelt kun standalone produkter. Sommetider flere produkter som ikke kan tale sammen. Men lad nu den diskution ligge. Vi bliver ikke enig.

Kombi relæet findes i en anden udgave, som ligner den 99,9%, men hvor den kun er modtager. Er du 100% sikker på at det er et kombi relæ du har, og ikke en modtager 505D6505 eller allround modellen 505D6515 du har? Ingen af de 2 sidste har tangenter, men når man piller dækslet af, ligner det et kombi relæ 99,9% Jvf. LK er det en fejl at de står som udgået på deres hjemmeside, men den fejl har nu eksisteret i et par mdr. så jeg ved ikke helt hvad jeg skal tro på.

Tilgengæld kan du med IHC lave et fuldt inteligent hus. Med philips hue kan du lave et flot lysshow. Træerne vokser ikke ind i himlen.

Nej. Du misforstår. Hvis du har IHC høre du til gruppe 2 eller 3, ikke gruppe 1. Det er ikke medierne som skaber en hype om Philips hue etc. Det er facebook, twitter etc.

Igen skære du alle over en kam, og glemmer at der mange forskellige kunde grupper med hver deres IHC produkt preference. En gruppe er dem som smidder penge efter google home etc. De er typisk unge, og vil bare have noget som er in. De er i bund og grund ikke interesseret i andet end at kunne vise at de kan tænde og slukke lyset med en app. Goggle home er idag deres fortrukkende. Imorgen kan det være et helt andet produkt som er in. Denne gruppe er meget udadvendt og vil derfor ofte dukke op på facebook, twitter etc. og er RIGTIG dygtig til at skabe en masse hype om et relativt ubrugeligt produkt. Denne gruppe er stærkt stigende og er rigtig dygtig til at tiltrække sig opmærksomhed og fokus. En anden gruppe vil have et funktionelt IHC system, som integrer med husets primære produkter som varme styring, ventilations styring, alarm anlæg etc. En app. og et dashboard på væggen er et plus, men ikke et must. LK IHC, KNX, SmartHouse etc. kan stortset alle opfylde dette behov. Denne gruppe er svagt stigende, ikke særligt udadvendt og RIGTIG dårligt til at tiltrække sig opmærksomhed. Den sidste gruppe er nørder som du og jeg. Vi vil have et IHC systems som vi selv kan integrer med ALT. LK IHC er pt. det bedste IMHO, men det kræver mange trejdeparts at lave ordentlig integration. Denne gruppe er faldende, ikke særligt udadvendt og eller ikke særlig dygtig til at tiltrække sig opmærksomhed. Du kan helt sikkert finde på andre kunde grupper, men bare fordi en gruppe er gode til at tiltrække sig opmærksomhed og skabe hype om et produkt, er det ikke nødvendigvis ensbetydende med at det produkt har nogen somhelst værdi for andre kunde grupper.

Du tager igen udgangs punkt i at du er en normal kunde. Det tvivler jeg stærkt på at du er. Jeg vil påstå at 90% af IHC kunderne ikke har nogen somhelst idee om hvad man kan med IHC, og blindt stoler på hvad deres el installations pusher fortæller dem. For dem er det fuldstændigt ligegyldigt hvad der står på komponenterne i deres tavle eller hvor de sidder, bare de kan styre lyset m.m. via deres app. Disse kunder ser ikke alle de problemer du ser med IHC, og de bekymre sig slet ikke om hvorvidt LK IHC er en fremtids sikker investering. Jeg håber jeg tager fejl, men personligt tror jeg LK IHC er taget af marked om 10 år, og erstattet med Schneiders andre home automation produkter.

Jeg mener den er kompatible med de nye Actassi, men prøv at smide el nr'et på den, så skal jeg prøve at slå den op i de kataloger jeg har Hvis det er CAT5 er der ingen problemer i at have forskellige connector i hver ende af kablet. Hvis det er CAT6 eller højer vil du ikke overholde standarden, men det vil 99,999% sikkert virke og drop kablet vil kunne bestå en CAT6 test.

Visual bruger ikke Java, så nej. Problemet med at controlleren svare på ping, men ikke kan nåes via Visual ses ofte på en HW 6.1 eller HW 6.2 controller i forbindelse med at serviceview eller et trejdeparts produkt køre samtidig.

Ja til det hele, med den kommentar at du kun skal bruge 1 leder til 24V, ikke 2 par til 0V og 24V. 0V er den ene leder i data parret til I/O modulerne. Disse SKAL være parsnoet, og der er ingen grund til at bruge 2 leder til 24V, men der er heller ikke noget i vejen for at gøre det. Så du vil have 2 par eller 2,5 par i overskud alt efter om du køre med seperat eller fælles 24V.

Der kan være mange årsager. Men de 2 som lige springer i øjnene er Rettigheder på windos 10. windos 10 er noget rod vedr. rettigheder. Det kan være du skal køre installationen på den første PC med admin rettigheder for at få alt installeret korrekt. Den USB port du brugte på den første PC kan have en fejl

Det er forlænge siden jeg sidst arbejdede som elektriker, så jeg må blankt erkende at jeg kan ikke huske reglerne. Jeg er derfor ikke 100% sikker men jeg mener der er noget om at når der er tale om 2 forskellige bygninger, så skal man enten have lokal jord hvis man har en undertavle, eller jordledningen mellem de 2 tavler vil blive betragtet som en udlignings forbindelse. Dog er jeg 100% sikker på at jordledningen mellem de 2 tavler skal have mindst samme kvardrat som forsyningen til undertavlen. Men eftersom IHC ikke er jordet, er denne diskution ikke relevant for det som trådstarter vil lave. Her er det bare vigtigt at 0V potentialet på 24V siden at alle strømforsyningerne er det samme, hvilket man opnår ved at for forbinde 0V på alle strømforsyningerne med hinanden.

The login failed is a Java problem, which get fixed with firmware 2.8.4. There is a workaround described in the tread "java problemer igen igen igen" The error IHC controller not detected but <USB> responds to ping has been seen if the firmware version and Visual version is misaligned. Have you tried to use some of the older firmware uploader you can download here? If you want to upgrade a HW 6.1 controller to firmware 2.8.4 you need on of the older firmware loader without version check anyway. LK do not support HW 6.1 anymore and latest firmware version is 2.7.220, but this one has several Java issues, and is generally considered pretty unstable. 2.7.199 is more stable, but have even more Java issues. There are workaround for all the known Java issues in the tread "java problemer igen igen igen"