Lars1

Når du har adgang til controlleren er det selvfølgelig muligt at fejlsøge og ændre programmet, men Visual 1 er en gammel controller og det kan kræve lidt arbejde at få den gamle software til at køre på windos 10. Dertil kommer at du skal bruge et nul modem kabel. Dem fik du smidt i nakken for 10 år siden, men idag kræver det lidt arbejde at finde et, samt en serial til USB adaptor da moderne PC'er sjældent har RS232 porte. Sidst men ikke mindst er der en serie af Visual 1 controller som har en HW fejl som gør at RS232 porten holder op med at virke efter en årrække. Hvis det er tilfældet kan man selvfølgelig ikke komme i kontakt med controlleren, men for mig lyder det som om at din elektriker ikke engang har forsøgt. For mig lyder det mere som en dårlig undskyldning for at din elektriker ikke har erfaring med de gamle controller og gerne vil sælge dig en ny. Medmindre du har planer om at udvide med varmestyring eller IHC wireless, er der absolut ingen grund til at udskifte controlleren. Der findes flere IHC elektriker rundt om i landet som har erfaring med Visual 1 controller. Den gode nyhed er dog at hvis du ikke kan får adgang til controlleren, er det kun controlleren som skal skiftes. Alt andet kan genbruges, men det er fortsat en udgift som nemt løber op i 10-20K afhægig af om det er muligt at hente programmet i den gamle controller og kvaliteten af dokumentationen af programmet.

LK's forklaring lyder noget søgt. For mig lyder det mest som at de ikke har nogen idee om hvad der sker. At fejlen opstår når du du gør noget som skal ændre på wireless skyldes IMHO mere at wireless og netværks adgangen er de 2 dele af IHC firmwaren som har API'er, og dermed den største exponering til memory leaks og extern påvirkning. Hvis du brugte netværks adgangen ligeså ofte som du påvirker en wireless enhed, vil du sandsynligvis se et 50-50 split mellem hvad der trigger en genstart. Hvis du har mulighed for at sætte netværks sniffing op, kunne det være interessant at se om der bliver send data til app'en hvis du ændre lys styrke på en wireless dimmer via et fortrået tryk. Hvis dette er tilfældet, tror jeg mere at det er netværks API'et end wireless som er skyld i dine genstarts.

Jeg køre fortsat på den gamle 0.996 version. I den er det faktisk ganske simpelt at sætte logging op. Start IHC Captain. Find den FB og parameter du ønsker at logge Klik på +opret Under regl fane bladet vælger du "forskellig fra", "den sidst aflæste værdi" og "gem til disk" Under gem til disk fane bladet vælger du hvor du vil gemme dine data. Jeg mener default er "/var/www/html/captain/data/". Du kan godt gemme data fra flere parameter i den samme fil, men jeg vil forslå at du laver en fil for hver parameter. IHC Captain opretter selv filerne hvis de ikke allerede eksister. Derudover skal du vælge det format data skal gemmes i. Jeg bruger "[date],[time],[newval]" Tryk på gem, og du er kørende.

Nope. Alle wireless enheder som har et minimums belastnings krav, kræver også belastning når du skal linke dem etc. Belastnings kravet er faktisk lidt problematisk når der går en pære. Hvis den går mens dimmeren er på 100% så kan du ikke slukke dimmeren for at skifte pæren. Grunden til belastnings kravet er at det wireless kommunikations modul sidder i serie med belastningen på de gamle wireless enheder. På HW ver. 2 sidder det parallelt. Hvorfor det sidder i serie på de gamle modeller må du spørge LK om. Men tilbage i 00'erne hvor systemet blev designet var det normal praktis at gøre det sådan.

Eftersom du har IHC Captain, kan du sætte den til at logge data. Jeg kan ikke huske hvor jeg har min måler FB fra, men engang i døgnet gemmer den måler standen. Jeg har sat IHC Captain op til at logge data hvergang dette sker. Hvis du vil have data logget ofter, kan du f.eks lave en time tæller som bliver opdateret hver time, og sætte IHC Captain til at logge denne. Men bortset fra det, så lyder dit problem for mig mest som at din controller er kommet i et loop, hvor den ikke får genstartet rigtigt hvergang. En program ændring kan måske være nok til at bringe den ud af dette loop. Alternativt er den store tur med reset software, tomt program etc. men så bør du have sat IHC Captain op til at logge data først.

Det er kun HW ver. 2 som ikke behøver belastning. De gamle gør. Dersværre. :-(

Fik du løst problemet?

Alt som virker i 2.7.199 virker på samme måde i 2.8.4. Det der er ændret ved wireless dæmp, er metoden som man dæmper på (onetouch versus 2 tast), men denne ændring skete reelt tilbage omkring 2.6.x såvidt jeg husker, og begge metoder er supporteret i alle 2.x.x firmware versioner. Det er først i Visual 3 at support for onetouch er fjernet fra firmwaren, men du kan ikke lægge en Visual 3 firmware på en HW 6.1 controller, så det bør ikke give dig problemer.

Du har selvfølgelig prøvet trikket med at tage strømmen incl. batteri backup's i 10 sek? Hvis du har trejdeparts produkter som IHC Captain, open hab etc. så stop dem. Firmware 2.7.220 er ikke en særlig god firmware. Den giver flere problemer end den løser. Opgrader til 2.8.4. Det kan offecielt ikke lade sig gøre, men vi er flere som har gjort det med success, og der er flere tråde her på boardet som beskriver hvordan det gøres.

Jeg nægter at tror på at en extern wireless enhed kan bloker controlleren i flere timer. For mig lyder det meget mere som memory leaks i softwaren, som ikke er blevet opfanget korrekt af garbage collectoren. Det kan meget nemt ramme webserver delen, som meget tænkelig også bruges til wireless kommunikation eftersom de begge har API definitioner. Det har den fortråede kommunikation ikke.

Hvis du slet ikke kan få kontakt til nogle af dine wireless enheder, bør du checke at antennen er ordentligt tilsluttet den nye controller, og så selvfølgelig følge guiden for linkning slavisk. Den dukker op i visual når påbegynder linkningen.

Hvis det er den, så burde den blå wireless diode blinke næsten konstant. Derudover så er timeout på kommunikations fejl 1 min. eller derunder hvorefter controlleren går videre til næste wireless event, og wireless kommunikations fejl plejer ikke at ramme ethernet også. Du burde kunne se det på tæller resultaterne. En genstart bør ikke bringe tællerne mere end 10-20 pulser ud af sync afhængig af belastningen under genstart, men hvis controlleren har været unresonsive på wireless og ethernet i 1 time bør tællerne være langt mere bagefter. Det er sjovt nok start af Visual eller serviceview, som ofte er skyld i at min HW 6.1 controller genstarter af sig selv. :-)

Næppe. Jeg har også sådan en (den gamle model), og den har vist low battery on/off i over 1 år, men virker fortsat perfekt, og jeg har ikke haft wireless problemer siden jeg opgraderede til 2.8.4/6 Som du kan se i en anden tråd rodede jeg for et par mdr. siden med en wireless dimmer som havde for lav belastning. Den kan i visse tilfælde bloker for wireless kommunikation, men det ramte aldrig netværks interfacet, og der var en timeout på omkring 1 min. såvidt jeg husker, hvorefter controlleren fortsatte sin program afvikling. Hvad med dine el-måler tæller. Tæller de mens du ikke kan komme i kontakt med controlleren? For mig lyder det mest som at det er et software problem i controlleren, hvor den burde genstarte, men af en eller anden ikke gør det. Din bedste chance for at sikre at det ikke sker igen, er nok at gå gennem hele reset proceduren med reset software, tomt program etc. etc. etc.

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.