Astronaut

Traditionelle el-installationer har været lavet ved at sløjfe stærkstrømskabler rundt i bygningen i mere end 100 år. Selve kabelinstallationen fejler meget sjældent. Med et fornuftigt bus-design vil enkelt nodes også have meget svært ved at fejle hele bussen og under alle omstændigheder kan man isolere et eller flere segmenter. Man kan fint komme uden om afstandsproblemer hvis arkitekturen er en kombination af stjerne og bus. Sådan at man har mulighed for at forgrene bussen. På den måde kan man vælge den installationsform der giver det nemmeste kabeltræk. Ideen er at undgå at alle kabler skal ende samme sted (i el-tavlen) og lange afstande med mange parallelle stærkstrømskabler. Begrænsning i antal indgange er ikke noget seriøst problem. Med en bus arkitektur, hvor et tryk sender en besked hver gang der sker noget, er der ingen forskel på et tryk med 1 eller 200 tangenter. I en veldesignet controller er det heller ikke noget problem fordi den blot kan ignorere ikke-konfigurerede indgange. Er der nogen dokumentation på RS485 porten? Under alle omstændigheder vil jeg på sigt gerne undgå LK's controller fordi den netop er et af de svage punkter i IHC. Som sagt burde det være relativt nemt at lave en gateway til datalinje produkterne - protokollen er meget simpel og kendt. LK eller andre kunne lave en gateway. LK har lavet en stor investering i IHC Wireless. Med en wireless gateway kan LK fortsætte med at sælge de relativt dyre wireless komponenter uden at skulle videreudvikle controlleren. Og controlleren er i min analyse det svage led i produktserien (fx. er det fuldstændigt vanvittigt at LK fra tid til anden efterlader kunderne med usupporterede controllere der kører en gammel og upatchet version af Java samtidigt med at controlleren er på nettet). Controlleren er også det dyreste produkt at løfte rent udviklingsmæssigt. LK kan lave en wireless gateway relativt billigt. Det burde også være muligt for andre at lave en wireless gateway hvis man reverse engineerer koden i enten LK's controller eller et eller flere wireless produkter. Som tidligere skrevet er komponenterne i LK's wireless produkter standard komponenter. Dvs. hele den proprietære protokol er implementeret i software.

Jeg sagde ikke at kabeltræk ikke har en fremtid. Jeg er faktisk ganske enig i wireless bør holdes på et minimum. Min pointe var at IHC's kabeltræk er håbløst fordi det er en stor stjerne med mange mange lange stærkstrømsledninger (i min gamle installation havde jeg 7 input moduler og 12 output moduler med tilhørende kabeltræk ... i en lejlighed på ca. 100 m2). Hvis man i højere grad havde en bus-lignende arkitektur så ville kabeltrækket blive mindre. Man kunne også sende kontrolsignaler over stærkstrøms ledninger (i retning af Powerline Communication).

Jeg har haft en IHC installation siden 2003. For nyligt er jeg flyttet og nu har vi en IHC Wireless installation. For mig at se kan IHC deles op i en række elementer: IHC Controlleren – Giver mulighed for programmering, interconnectivity til resten af verden. Controlleren er outdated og der er ikke volumen nok til at lave en helt ny controller med udviklings IDE og nødvendig connectivity IHC Datalinje moduler – Modulerne benytter en outdated protokol og kræver enorme kabeltræk. Disse har ingen fremtid i nye installationer. IHC wired inputs – I forhold til hvad man ser i resten af verden er LK’s FUGA og Opus serier lækre. Men fordi inputs kræver enkeltledere til hver eneste input kræver disse enorme kabeltræk. Disse har ingen fremtid i nuværende form. IHC Wireless – Jeg er glad for min wireless installation, men jeg kan forstå at folk har problemer med forbindelsen over lange afstande, kapacitet og at de fleste dimmere reducerer udvalget af lyskilder. IHC App – Appen virker ufærdig og som et produkt der ikke er investeret nok i. At udvikle ordentlige apps er dyrt og umiddelbart virker det som om volumen i IHC er for lille til at lave noget ordentligt. Fremtiden bør være en form for IHC – KNX gateway. Så er danskerne med på samme tog som alle andre. Dette kommer enten når nogen finder ud af IHC wireless protocollen (som er baseret på wavenis som er dødt) eller når LK vælger at introducere en gateway (når det er for dyrt at holde IHC i live). Som jeg forstår det er der ingen IHC specifik hardware i wireless komponenter – det hele er software. Det burde således være muligt at lave en gateway. Fremtiden for dataline modulerne er mere problematisk. Hvorvidt nogen vælger at lave noget der kan snakke med datalinje produkterne skal jeg ikke kunne sige. En moderne microcontroller har tilstrækkeligt kapacitet til at styre mange datalinje produkter så det burde være en smal sag hvis man ser på komponenter. Det burde også være en smal sag for LK at lave KNX versioner af datalinje modulerne til renovering af eksisterende installationer. Så er det ikke længere IHC men så bevares den investering folk har lavet i IHC ledningsnet. IHC wireless kunne bruge en række opdaterede dimmere (i stedet ser det ud til at LK har ladet en række produkter udgå selvom de siger noget andet). Løsningen på kapacitet og rækkevidde kunne være en række slave controllere som kunne placeres rundt i huset, lidt i stil med at have multiple WiFi accesspoints. Umiddelbart burde det ikke være noget der væltede LKs udviklingsbudget. Grundlæggende er IHC dødt på langt sigt. Opgaven for LK er at sikre at de stadigvæk har en bunke dyre produkter de kan bruge til at malke danskerne med. Både dem der skal lave en ny el-installation og dem der skal renovere. De har ikke råd til at lave kernekomponenterne (controller med connectivity) men nok ting som tryk, dimmere, stikkontakter, etc.

Jeg er ny når det gælder IHC Controller Visual 3. Jeg har tidligere rodet rigtigt meget med en IHC Visual Controller version 1 (den med RS-232) og er ved at lære hvordan man programmerer den nye. Jeg har en række spørgsmål og håber nogen kan hjælpe med svar: Hurtige Klik - Til den gamle controller lavede jeg en funktionsblok der kunne se forskel på et enkelt hurtigt klik, et langt klik og tre hurtige klik. Det har virket fint i 15 år. Den nye synes at ignorere dobbelt og triple kliks hvis der er kort tid imellem. Er der nogen der har oplevet det samme? Hvad laver: Scenarie gem Scenarie stop Scenarie reguler op/ned (hvor meget reguleres op/ned?) Protocol Temperatur/Fugtighed – Der er nogle nye sensorer der rapporterer talværdier. De synes at rapportere værdier serielt over et data linje input. Er der nogen der kender protocollen? Kunne man sende andre ting til controlleren serielt? Funktionsblokke i funktionsblokke – Er der nogen mulighed for at putte funktionsblokke ind i andre funktionsblokke? View datalinier – Den gamle controller havde et ”service view” program der viste alle datalinjer i et view. Det var fantastisk til at få overblik over hvad der skete. Det nye ”service view” synes kun at kunne vise konfigurerede indgange. Er der nogen mulighed for at få samme overblik som med den gamle controller? Logging - Kan man skrive til loggen fra en funktionsblok? ”Missing Holidays File” – Er der nogen mulighed for at slippe for denne besked i loggen? Jeg kan se jeg ikke er den eneste der har det problem. Jeg har prøvet at ændre time setup men intet synes at virke.