Leaderboard

Hej Kenneth Tillykke med det nye hus, og velkommen til IHC user. Det ligner at dem der i sin tid bygge huset, har taget nogle gode valg, og selv om anlægget er omkrig 20 år gammelt, kan det stadig give mange af de nye baghjul. Hvis alt virker, er der som udgangspunkt ikke noget der haster. Selv om det selvfølgelig ville være at foretrække med en backup til den dag uheldet er ude. Selv om anlægget stadigt er godt, er der dog sket en del i de 20 år. Mange ønsker i dag adgang til anlægget via telefon og iPad, hvilket de gamle kontrollerer ikke kan. Vi er også gået over til LED pærer, som virker helt anderledes end de gamle pærer, hvilket ofte giver nogle udfordringer for de lysdæmpere der sider i tavlen. Så på sigt skal I have opgraderet de 2 controllere og lysdæmperne, derudover bør I også opgradere strømforsyningen og mon ikke batteriet er langt mere end de anbefalede 5 år. Som Mikkel skriver, så kan det hurtigt blive en større opgave at dokumenterer det hele, det kan dog lade sig gøre at slide sig igennem hele huset, men det er typisk en 2 mands opgave som tager tid. Hvis du ikke kan finde programmet på PCen, så har jeg det værktøj som Lars1 henviser til, værktøjet gør det super nemt at finde alle ind- og udgange. Se evt. video her. https://drive.google.com/file/d/192tcypnBHOpL0HLy1aSetW9wDAmsATGe/view?usp=drive_link Ud fra dine billeder vil jeg gætte på at den ene kontroller køre lyset og den anden alarmen og gardinerne samt evt. jeres varme. Venligst Henning

Sorry for posting in english, I do not speak danish at all :-) I have integrated the old style IHC Controller (no ethernet, RS485 only) to Home Assistant. The code can be found at https://github.com/priiduonu/ihcclient. Comments and PR-s welcome!

Hvis du, som jeg, heller ikke helt har opgivet IHC endnu, så er her lige en lille opdatering på et af mine projekter: IHCEasy (https://jemi.dk/ihc/files/IHCEasy.exe ) Jeg søger lige nu folk der har lyst til at teste min løsning som er en måde at installere LK Visual software pakken uden en masse problemer - det er testet ret grundigt og kan med sikkerhed ikke ødelæge noget*. Der er Features pt. er: Mulighed for at have flere IHC Visual installationer samtidig - Visual 2 og 3 samtidig Automatisk fix af hvis LK visual installation er i stykker ved opstart - utcs, xml og mere Som standard kræver LK Visual ikke længere ikke altid admin rettigheder for at starte Inkludere det nødvendige java - så ingen java problemer eller generel java installation Automatisk check af manglende udvidelser og ødelagte filer Ingen krav om Java for at køre firmware opdatering program Problematisk måde at starte SceneDesigner på er fjernet Flytbar installation Lokal installation Fjernelse af ligegyldige ting som Adobe PDF IHC USB driver tjek og installer Lokale IHC funktionsblokke i bruger (Documents) mappen Løst java skaleringsfejl ved skærme med høj opløsning/DPI ...og meget mere mere jeg har glemt Nå ja nye ikoner også Hent og prøv her: https://jemi.dk/ihc/files/IHCEasy.exe Bemærk det er i beta og jeg mangler lige nu en licens fil og lidt andet. * men dere er ingen garantier

Fra min facebook side: Jeg har på det sidste hjulpet en del med at få installeret selve LK Visual og usb drivere med mere. Ville det give mening at lave noget der kan løse problemerne med primært de gamle men også visual 3 installationer. Det jeg pt har lavet er: - Fjerne automatisk Adobe pdf reader I gammel version og andet forældet software. - Fjerne automatisk installation af gammel og usikker java. - Fjernet krav om java installation til firmware upgrade- - Løst problemet med at bruger definerede funktions blokke ikke kan gemmes og kopieres ind. - Lavet hele lk visual programmet portable. Jeg kan naturligvis ikke distribuere LKs egen software men kan lave noget man kan køre efter man har downloadet deres software men inden man installerer det. Alternativt kunne jeg måske kontakte lk/Schneider og spørge om jeg må bygge en ny installer til dem. Bonus: har ihc-user nogenside hørt noget for de har en del af IHC softwaren til download?

Kommentarer er velkomne ;-) Egne noter: * Måske ikke arbejdet værd at køre klemmer til ALT. * Vil helt sikkert anvende klemmer igen til 0V/12V alarm backup (alarm PIR). * Placering af moduler, gruppeafb., kombirelæer osv. skal planlægges bedre, så der ikke er så lange kabeltræk i tavlen - både IHC og stærk. * Mega bøvlet at trække kabler ind i LK's tavler fra bagsiden. Forskalling bag tavle på 50mm skulle have været lavet dybere. * Tabula el. lign. overvejes til næste projekt * Link-10 kabel til alle tryk/inputs er overkill. Der bliver alt for meget i tavlen. Overvej alternativ kabel med færre ledere. Dog ultimativ mulighed for at ændre senere.

Hej Forum Projeket løst efter enestående hjælp og support fra #Martin Abildgaard. lidt observationer fra projektet. nr. 1 Korrekt forbindelse kræver kabel med DB9 Hun-stik til Controlleren, og enten Han/Hun til Computer afhængig af hvilken adapter der anvendes. nr. 2 Korrekt forbindelse opnås bedst ved at sætte kabel i Controlleren og DB9 adapter før start af IHC Firmware opgradering eller IHC Visual. nr. 3 På den gamle Firmware var det nødvendigt at slukke/tænde for controller et par gang før der var forbindelse., på den ny (0.1.5.0) opnås forbindelse uden genstart. nr. 4 Efter firmware opgradering blinkede controlleren 'normal drift' men alle tryk var 'døde'. Intet program kørende i Controller. Flere genstarter senere, og et skift af Switch-mode knappen på forsiden fra A til B, lykkedes det at få forbindelse. Efter at have kompileret programmet og sendt det til controller igen kørte Controlleren i normal drift med alle tryk aktive. Efterfølgende har jeg foretaget flere rettelser og forbindelse såvel som software fungerer upåklageligt. Bh. Claus

Nej egentlig ikke. Som mange indlæg i tråden også gør opmærksom på så er Wiser nok mest et alternativ til IHC wireless - som “add on” til eksisterende huse for at gøre belysningen “smart”. IHC wireless er mig bekendt ikke udgået af sortimentet (endnu). Det eneste er indtil nu kun V3 controlleren. Her har argumentet ikke været at der er/var et alternativ i Wiser. Men at der var nogle chips/komponenter der var udgået og det er derfor de har indstillet produktionen.

Man kan ikke bruge en Raspberry Pi men man kan bruge en Raspberry Pi Pico. Forskellen er at Arduino, ESP32 eller Raspberry Pi Pico er microcontrollere hvor der ikke kører noget operativsystem på dem. På den måde har man fuld kontrol over timing. En Raspberry Pi er en traditionel CPU med et operativsystem og der vil taskswitch m.m. i praksis gøre det umuligt at få timingen rigtig. De fleste microcontrollere vil kunne klare timingen med I/O moduler. Hvert I/O modul får deres egen I/O pin. Den konfigureres til enten at være input eller output. Problemet opstår hvis man gerne vil snakke med controlleren over et IP netværk. I praksis er der ingen microcontrollere der har ethernet men man kan få nogen med Wifi. Alternativt kan kan koble en microcontroller sammen med en Raspberry Pi. På den måde står microcontrolleren for kommunikationen med I/O moduler med den præcise timing der er nødvendig. Den kan så bruge en langsom protocol (fx. RS-232, SPI, I2C) til at kommunikere med Raspberry Pi som så snakker med resten af verden over TCP/IP, HTTP, MQTT, whatever. Lidt mere arbejde end med en microcontroller med Wifi. Under alle omstændighed vil man også skulle implementere protokollen til LK's sensorer. Jeg er ikke helt sikker på at koden fra "dingus" til temperatur virker.

Hej Jeg har købt nogle dele af ham, og de er - som vist på billederne - uåbnet i original emballage. Der er intet suspekt ved dette. mvh Ejvind

Lars er nu ikke helt alene med sin skepsis overfor wireless, jeg er også mest til tråd, men det er måske en gammel EL skade. Hvis dit problem med bussen er at nogle lamper ikke tænder/slukker, når de skal, men først når andet tænder/slukker, så kan det løses i Visual.

Logic Group kan forsvinde hver dag det skal være. Det er en relativt lille virksomhed. Men køber du deres løsning så har du valgt Z-wave standarden - ikke en Logic Group løsning. Dit eneste problem hvis Logic Group går ned er hvis du i fremtiden ønsker at købe mere fra dem og de er væk. De har ikke deres egen controller. De køber Fibaro's controller og sælger den videre til dig. Hvis du hellere vil have en anden controller så kan du bare købe en anden. Går Fibaro firmaet ned og du får problemer med din controller så kan du købe en anden Z-wave controller og køre videre. Hvad der bliver fremtidens standard er et godt spørgsmål. Personligt er jeg ret bekymret for hvorvidt Matter/Thread bare er endnu måde for Apple, Google, Amazon, Microsoft at stikke næsen i mit liv. For når enheder bruger IP til at kommunikere så er det ikke langt til at alle enheder kræver en internet forbindelse og en cloud konto. Men hvilken standard der vinder er lidt ligegyldigt fordi de i de fleste situationer kan co-eksistere. Undtagelsen er de situationer hvor du trykker på en tangent og så ønsker at lyset tænder uden nogen forsinkelse. Der er det pt. vigtigt at de er på samme standard. Men ellers kan Z-wave, Zigbee, etc. godt co-eksistere hvis blot man laver integration i controlleren. Din største bekymring bør således være om du kan købe Z-wave I/O moduler, stikkontakter, dimmere og betjeningstryk til dit fremtidige forbrug. For det er netop der hvor det er vigtigt at de er på samme standard. Resten mixer du bare sammen.

Jeg kan se at open source produktet Zigbee2Mqtt har support for Wiser. Alt det kode der skal skrives for at supportere Wiser er således kendt. Jeg kan godt se at du ingen interesse har i det og at Danmark er et ret lille marked hvis der skal laves mere end det mest basale, men det er åbenbart muligt blot med software og uden at kende hemmelige koder.

Problemet er alle os med primært wireless. LK efterlader os uden nogen vej fremad. Reelt skal alle wireless komponenter udskiftes. Hvis blot de offentliggjorde wireless protokollen så var der mulighed for at komme noget af vejen. Jeg har i øvrigt svært ved at tro at hardware til den underliggende Wavenis protocol udgår for den bruges vist til vandmålere o.lign. At lave en løsning for wired moduler burde være straight forward. Protocollen er noget med 16 pulser hvor længden afgør on eller off. Jeg tænker at en Raspeberry Pi Pico e.lign. nemt vil kunne styre ca. 24 input og output moduler (en Pico W har 24 GPIO pins). Der er lidt med at gå fra 5V til 24V men det burde være til at overkomme fx. med multi channel optocouplers. Man kan så lade den snakke med verden med MQTT og så er man videre på et open source produkt. Det burde ikke blive rigtigt mange linjer kode. Måske et par hundrede for der er allerede sample kode for hvordan man får netværk og MQTT op at køre. Læg en smule til at for at håndtere multi puls sensorer som fugt og temperatur. Desværre har jeg personligt kun 2 input moduler og resten er wireless så det rækker som en skrædder i helvedet. Derfor kommer jeg ikke til at arbejde på det. PS: Her er kommunikationen mellem controller og moduler. Synes ret nemt. Detaljer ligger på wikipedia og passer godt med min hukommelse.

Hej, Jeg har et IHC system i mit hus, incl. noget wireless. Det er selvfølgelig irriterende at IHC Controlleren ikke produceres mere, og i praksis betyder det et elektrisk "dødt hus", hvis den nuværende controller står af. Den irritation er jeg nok ikke ene om! Retfærdigvis har IHC eksisteret i mange år og det var ret nytænkende tilbage i tiden. I mellemtiden er næsten alt mit lys nu Philips HUE, som virker rigtigt fint og HUE har overtaget meget af funktionaliteten fra IHC. Med andre ord programmering af IHC i mit hus er noget mere simpel end for 15-20 år siden da IHC blev installeret. Tænkte derfor på om man kunne lave en controller, evt. blot som GateWay, altså så "dum" at den kun kan aflæse input og styre output, men uden logikken eller med meget simpel logik. Måske det kunne styres fra f.eks. IHC Captain? Som potentiel "dum" erstatning for contolleren byggede jeg en mindre prototype vha. et Raspberry Pico W modul og indsatte et IHC Input 24 - blot for test. Det virker helt fint. Næste step bliver output, men det er simplere. Flinke mennesker har jo dokumenteret "protocollen" imellem controlleren og de forskellige input og output moduler Pico W er en 32 bit arduino like dims, der ikke umiddelbart vil have problemer med at indlæse de 8 input (x 16) samt styre de 16 x output (x8), der er i IHC controlleren. Pico W har også wifi, dvs. den kunne nås via f.eks. et REST API eller blot en simpel RS-232. Samtidig er Pico W et ret billigt modul, i niveau 75 kr plus selvfølgelig print osv. Et gæt vil være totalt under 500 kr i materialer. Bemærk jeg har ikke kigget på wireless delen af IHC (endnu) Men før jeg går videre: Er der nogen her i forum der har kommentarer eller interesse? Ovenstående er der nok andre der har tænkt og jeg har søgt, uden at finde noget der direkte ligner, men sig endeligt til, hvis jeg har overset noget. Ingen grund til at opfinde den dybe tallerken igen igen... På forhånd tak for input! PS jeg har INGEN kommerciel interesse i det her, det er ren hobby / bekymring for et "dødt hus" :-)

Interessant viden. Jeg byggede ret hurtigt prototypen sammen med et IHC input og et IHC output 24V og en Pico W med styring af "protocollen" via brug af IRQ (flanke) for data fra på input modulet og en IRQ timer til styring af output modulet. Det virker fint nok og er nemt at styre og jeg er ret overbevist om det kan styre en del moduler. Ideen med PIO er ret interessant og ja burde give den helt rigtige timing øge antallet af moduler der kunne tilkobles. Det der stopper det for mit vedkommende er wireless delen, uden den er det hele jo formålsløst - helt som du skriver. Dog kunne en lille lokal installation måske bruge IHC input og Output moduler og det vil et Pico W setup jo nemt (og billigt!) kunne styre. Der kommer sikkert mange brugte IHC moduler på markedet, nu hvor controlleren udgår. Som eksempel: Vi har vel alle 117 ladere til alt muligt - her vil det være smart at kunne tænde / slukke for hver enkelt lader uden at skulle trække stik ind og ud. Nå måske en lidt tænkt use case og næppe specielt CO2 venlig, eftersom IHC modulerne bruger noget strøm. Derudover kræver det så installatør eller elektrikker for opsætning af 230V tingene.?

Når man leder efter fejl på netværk, er det ofte ganske banale fejl som er skyld i problemerne. Derfor er det vigtigt at gå systematisk til værks. Jeg tvivler på at det er fiberboksen som var problemet. Det har nok nærmer været en dårlig forbindelse i LK IHC controller porten eller kablet. Men godt at det kom til at virke.

LK IHC wireless enheder kan kun kommuniker med andre LK IHC wireless enheder, herunder også LK IHC controller såfremt denne er Visual 2 eller 3. Selvom Schneider sælger både LK IHC wireless og Wiser, kan de 2 produkter IKKE kommuniker med hinanden. De baser sig på 2 forskellige wireless standarder. Det der endnu ikke er udgået fra LK IHC wireless produkt kataloget finder du her https://www.lk.dk/produkter?iid=159 Alternativer til LK IHC incl. wireless kan du finde i denne tråd. https://www.ihc-user.dk/forum/forums/topic/10812-ihc-eol-hvad-er-alternativerne/

Ved wireless har række følgende af links betydning hvis der er problemer med kommunikationen med en wireless enhed. Så forløbig har jeg prøvet at ændre linksne, så udgangen er linket før indgange. Så må vi se om det ændre noget. Før var indgangen linket først.

En ting er fase, men når vi taler LK IHC wireless dimmer, så har du både fast fase, dimmer fase/mellem ledning, samt risikoen for fremmed spænding, hvis der er lavet en fejl et andet sted i installationen. Villedningen til programmeringen kan du finde her. https://www.lk.dk/produkter?iid=11372 Hvis din installation er lavet lidt smart, så har du max 2 dimmer, som hver trækker 3 lampeudtag, incl. dimmeren. 6 lampeudtag og 2 tryk er dog en overkommelig opgave at erstatte med et andet produkt. Undgå dog at købe de billige harald nyborg wireless dimmer. Gå efter noget professionelt baseret på Z-Wave eller Zigbee.

Som Henning skriver, så vil dit lampeudtag ikke virke hvis det er HW ver 1. og pæren er defekt. Årsagen er at min. effekt kravet ikke længere er opfyldt.

Hej Regamoks Velkommen til IHC user Den funktionsblok bliver du nok nødt til selv at lave. Det kan f.eks. gøres sådan. Hvor indgang linkes til "Totalalarm tilkoblet" og udgang til dioden God fornøjelse, Henning

Hej Jense Velkommen til IHC user Der kan være flere årsager. Vedr. dioder, så lyser de IKKE ved betjening af 1 og 2, kun hvis du holder A knappen nede i længere tid. Men det bør du kun gøre hvis du er ved at linke til controlleren. Tænker du har testet at pæren virker, hvis ikke, så er det første prioritet. Næste step er at sikre at der strøm på lampeudtaget. Der kunne jo være løse ledninger mm. Hvis begge er positive, så er lampeudtaget defekt.

Allan, du er en helt! Det virkede at indlæse den gamle firmware 2.3.587! Så fik controlleren en succesoplevelse - og så kunne den boote op i normal mode. Tusind, tusind tak! Hvis du sender mig din adresse i en direkte besked, så sender jeg en stor stak fastelavnsboller

@Lars1 Som det lille program viser, så er der ingen problemer i at bruge Lys Niveau under udgang som betingelse inde i selve programmet. I mit lille program spørger jeg først om lys niveauet er = 0, hvis ja - bliver det sat = 90%, hvis ikke, spørger jeg om lys niveauet er mindre end 50, hvis ja - så bliver lyset slukket ellers bliver det indstillet til 29%. Du kan også lave et nyt under program der aktiveres når Lys niveau ændres og her spørge om niveauet er over dine 75%, og starte eller stoppe din timer ved hhv. ja og nej.

Problemet startede allerede i windos 10, hvis ikke før. Jeg havde på et tidspunkt en løsning, men det er flere år siden jeg sidst har brugt den, og kan ikke finde mit notat om hvad jeg gjorde. Den var dog ret besværligt såvidt jeg husker. Alternativt kan du bruge https://jemi.dk/ihc/docs/ @Mikkel Skovgaardhar også lavet andre tools til LK IHC.

Det er jo muligt at sende kommandoer til LK IHC via API'et. Det er jo det som IHC Captain, OpenHAB, HA m.fl. benytter. Præcist hvordan det gøres ved jeg ikke, men mon ikke Mikkel kan hjælpe med det. Den store udfordring bliver nok at få computeren til at sende kip informationen inden den går i dvale, og så få IHC til at vente længe nok, så computeren når at gå i dvale inden strømmen ryger. Alternativt kunne du se om du ikke kunne finde en energimåler som kunne sættes på mellem computeren og stikkontakten. Når strømforbruget var lavt nok, skulle den så sende en sluk kommando til IHC, evt. via IHC captain, OpenHAB, HA eller tilsvarende. Men spørgsmålet er om du overhovedet har brug for det idag. Idag går mange skærme automatisk i standby når der ikke længere er signal fra computeren. Hvis dine højtaler har ekstern forstærker kan det sammen gøre sig gældende her. Hvis de ikke har eksterne forstærker, slukkes de jo automatisk sammen med computeren. Hvis de har ekstern forstærker kunne du også checke om de ikke alternativt kunne strømfødes via USB fra computeren. Det kan relativt mange eksterne computer højtaler idag. Idag findes der også computer skærme, som kan strømfødes via USB fra computeren. Bortset fra det, vil jeg nu ikke dømme alle el spare strømskinner ude, p.gr.af en produktions fejl i en enkelt strømskinne. Jeg medgiver gerne at at lodde ledninger på kobber skinnerne er en billig løsning som giver et stort potentiale for produktions fejl, men det er og bliver en produktions fejl. Det er IKKE en design fejl som vil gøre alle el-spare skinner af det mærke til brandfælder. Derudover er video'en 7 år gammel, så mon ikke de har fået styr på den fejl. Når det er sagt, så var der mange el-spare skinner, som havde et relativt højt standby forbrug. Da de kom frem, mindede det lidt om dengang alle skulle have bevægelses sensor på deres ude lys for at spare strøm. Problemet var bare at mange af de tidlige bevægelses sensor havde et egetforbrug på 25W. Så i steddet for en 60W pære som brændte i 8 timer havde man en 25W bevægelses sensor som brændte i 24 timer.

Der ser ud som om der er noget galt med dit IHC projekt. Hvis du henter det fra controlleren og gemmer det på din computer så kan du åbne det i Notepad. Hvis du ser de der mystiske lange tekster du er noget gået galt. Hvor meget det er ødelagt er ikke til at sige. Du kan evt. uploade det til @Mikkel Skovgaards dokumentationsservice og se hvad den siger.

Nu har jeg brugt de sidste par måneder til at kigge omkring efter en løsning til at efterfølge IHC. Min installation er nok anderledes end de fleste. Vi har stort set kun wireless bortset fra 4 stk. 2-kanal dimmere, 12 magnetsensorer, 10 PIR og 4 temperaturfølere. Derfor bliver min løsning nok også anderledes end de fleste andres. Et krav er at det der er wireless i dag også skal være det i fremtiden (ingen nye kabler). Et andet krav er at det ikke må ende i en proprietær løsning. Jeg gider ikke igen stå mod håret i postkassen. Et tredje krav er at en "controller" til lys og andet livsvigtigt kun må lave livsvigtige ting. Dvs. det er ikke acceptabelt med HA, OpenHAB, Homey, etc. til at styre de livsvigtige ting. Problemet med alle de løsninger er at de er designet til at man integrerer alt muligt i "controlleren". I praksis betyder det at der hele tiden er opdateringer til softwaren i controlleren og hver gang man opdaterer er der risiko for fejl og dermed udfald på det livsvigtige. I praksis ønsker jeg en controller jeg kun skal rode med når jeg kommer med nye komponenter. Min løsning bliver nok Zigbee wireless komponenter der snakker med en Raspberry Pi Server der kører Zigbee2MQTT (snakker med Zigbee devices), NodeRed ("Programmering") og Mosquitto (MQTT). Eneste måde at snakke med serveren vil være over MQTT. Der bliver ikke noget bruger interface eller automatiske opdateringer. Hvad der skal laves af UI bliver HA som snakker over MQTT. I en overgangsperiode vil jeg tage MQTT beskeder fra IHC captain og sende ind i NodeRed. På den måde kan overgangen fra IHC til Zigbee ske gradvist. Jeg har nu skidtet kørende med nogle tilfældige Zigbee komponenter jeg havde i skuffen. Når man ved hvad man gør så tager det under 20 min. at få det i luften. Det bliver lidt arbejde med at få bygget de funktionsblokke jeg har brug for. Fx. plejer jeg i IHC at have en hjemmelavet funktionsblok der styrer alt lys i et rum. Nu skal jeg til at lave en lignende i NodeRed. Det blev Zigbee fordi min oplevelse er at Z-Wave ikke sælger så godt (der er vist også issues hvis man får rigtigt mange devices koblet på). De andre løsninger jeg har kigget på er proprietære og det er som sagt no-go. Mine tavle komponenter har jeg pt. ingen løsning for; de kører videre i IHC controlleren. Ingen af dem er kritiske. Når IHC controlleren dør så er en mulighed at lave en løsning med en Arduino, Rasperry Pi Pico W, ESP32, e.lign. som er koblet direkte til magnetkontakter og publiserer resultatet på MQTT. Resten (PIR + Temperatur) klares med wireless sensorer. Dette er ikke en løsning for alle. Man skal kunne bruge Raspberry Pi, Docker og forstå noget Zigbee, MQTT. Ideelt kunne "nogen" lave en færdig løsning med de nødvendige funktionsblokke og et image lige til at installere. Alas, det bliver ikke mig men jeg deler gerne mine løsninger med andre. Nu følger et par måneders eksperimentering og så må vi se. Jeg har ikke travl. Men skulle min controller stå af (som den næsten gjorde for 2 uger siden) så har jeg nu en vej frem som kan sættes i værk hurtigt. PS: Til dem der ikke kender NodeRed så er her et generisk eksempel på NodeRed programmering. Det synes ret nemt når man først er kommet i gang.

Spændende. Jeg overvejer lidt samme retning, men en af mine anker er omkring salg af bolig. Er det noget en ny køber kan overtage uden at skulle være programmør. IHC var/er trods alt noget manbnemt kan finde en der kan hjælpe med. Hvad har du gjort af tanker i den retning?

Jeg har ikke nogen bedre bud end det du prøver. Når jeg er retur fra julen kan jeg kigge lidt mere

jeg har selv kæmpet et par dage med at finde en løsning. Dettet ser ud til at virke alias: TEST IHC 2 description: "" trigger: - platform: state entity_id: - climate.study attribute: temperature condition: [] action: - service: ihc.set_runtime_value_float data: controller_id: 0 value: "{{ float(state_attr('climate.study','temperature'))}}" ihc_id: 18573844 mode: single

Selvom der er lys, ville jeg prøve med en anden strømforsyning. De oprindelige 2 modeller til strømforsyning af IHC Net er ikke så gode. Især den første udgave var ikke optimalt designet.

Der er rigtig mange der har tilbagevendende problemer med at den aktuelle FW i LED dimmerne skal geninstalleres fra tid til anden. Problemet skyldes fejl i scenarie kommunikationen.

Der er andre som har samme synspunkt som mig. Både på dette board og udenfor. Men det er egentlig en ret ligegyldig diskution IMHO. Prøv at gå efter bolden i steddet for manden. De problemer man ofte ser, med wireless kommunikation, er periodiske og forsvinder af sig selv efter kort tid, så man ignorer dem ofte, eller tror de skyldes noget andet. Kan man leve med at ens smart house installation opføre sig underligt fra tid til anden, så skal man da endeligt vælge wireless. Jeg er bare for meget perfektionist til at aksepter dette.

Jeg tror ikke det specifikt er z-wave som der er berørings angst for. Vi er bare nogle som har en del erfaring med wireless kommunikation. Wireless kommunikation er bare ikke så stabilt som kablet kommunikation, ligegyldigt hvilket produkt du vælger. Problemerne bliver særligt tydeligt jo større din installation bliver.

He he he. Jeg har ikke brug for et nyt job. Når det er sagt så er min eneste interesse at gøre det klart hvad det er vi snakker om. Jeg har ikke selv truffet et valg om hvad jeg gør. Specielt er jeg i den situation at min installation primært er wireless. Det gør situationen lidt anderledes end mange andres. Min tavle har blot to input moduler (til PIR, magnet sensorer, temperatur/fugt sensorer) samt 3 stk. IHC DIN 2 kanal dimmere. Til gengæld har jeg 30 wireless stikkontakter og en del mere der skal skiftes på et tidspunkt. At ligge på gulvet og rode med for korte ledninger til stikkontaker er ikke lige noget jeg har lyst til. Men en ting er sikkert er at jeg ikke vælger en løsning hvor en enkelt producents beslutning efterlader mig i samme situation som nu.

Jeg spurte chatGPT. Svaret var som følger: Schneider sagde farvel, tog sit grej, IHC droppet, som var det leg. "Gider ej mer'" var hvad de tænkte, En ny sti i livet, tillid de sænkte. Wiser på væggen, ej "a wise choice," Den bruger strøm og har ingen voice. "Smarthome," de sagde, "det' fremtiden nær," Men prisen? Åh gud, det koster så kær. Så Schneider tænkte, "hvad gør vi nu?" Måske et system der er lidt mere snu. De forlod det gamle, og fandt noget nyt, En løsning, hvor kunderne er snydt! ... Personligt har jeg været glad for et to delt system. Noget der altid virker (fx IHC) og en flex løsning over på som altid kan pilles af (fx Home Assistant). Skriv gerne hvad du vælger ...

Ja, vi har haft nogle stykker, som gerne ville have tangenten i en farve. Vi laver den kun i hvid, da der er krystaller i, så farven fra LED'erne kan komme igennem. Det vil desværre ikke kunne lade sig gøre i en farvet tangent. Vi har haft kunder, hvor farven var vigtigere end funktionen, at den har baggrundsfarve. Vi lavede som en test, 10 stk som var autolakeret i sorte. De blev rigtig pæne, men også en meget kostbar løsning. En anden som ønskede sig dem i sorte, prøvede med autolakerede sine slim rammer (og håndtag) og vores tangent i hvid. Det blev han ret glad for, så han beholdte de hvide tangenter.

Vel ikke nødvendigvis. Hos mig er kabler også fræset i vægen da det er grund/fuldmuret, så de ligger alle i fugerne. Og når man har loft til kip, ja så er der heller ikke noget der bare er ført “til loft”. Men uanset hvad så har jeg alligevel valgt de ekstra dybe indmuringsdåser alle steder. De var jo et must til de 48 pds drop så der kunne overholde bøjningradius og blive testet og godkendt til 10Gbs, så hvorfor ikke også bare køre med de samme underlag til stikkontakterne, og tryk. Håber det også forholder sig sådan hos Bjarne og mange andre. Elllers må de jo frem med hammer og mejsel, hvis man vil skifte til noget der kræver mere fysisk plads. EDIT: nå fik ikke læst til bunden inden jeg svarede, og kan se Bjarne også selv har svaret. Der er jo ret stor aktivitet i denne tråd :-)

Jeg kan godt forstå din og andres frustration over Schneider ikke vil udvikle til IHC. Desværre er vores interesse heller ikke at starte på udvikling mod IHC. Det er ikke et marked der udvikler, men afvikler. Som jeg skrev tidligere, så er vores hensigt ikke at redde komponenter på IHC men at tilbyde et alternativ. Vi kommer ikke til at bruge tid på udvikling eller design af IHC løsninger. Det er der virkelig ikke en business case i for os, uanset hvad du siger. Vores fokus er Z-Wave og de produkter der skal bruges der.

At noget ikke findes er ikke ensbetydende med at det ikke kommer i fremtiden. Sålænge der var en LK IHC controller på marked, var der ikke rigtigt noget marked for alternative gateways da de det vil kræve MEGET reengineering at få dem til at kommuniker med LK IHC wireless og RS485 bussen. Nu er controlleren væk, så nu er der et hul i marked for en LK IHC gateway som kan kommuniker med LK IHC I/O moduler. Hvis vi tager et af Logic Group's I/O tavle moduler som udgangs punkt, så kan hovedparten genbruges. Det er kun selve ind og udgangs delen som skal redesignes, således at i steddet for en fysisk ind/udgang, så er det en data port med 16 indgange eller 8 udgange pr. port. En sådan gateway vil gøre en konvertering af 90% af alle LK IHC installationer til en økonomisk overkommelig opgave, og muliggøre en gradvis udskiftnign. Der er IMHO et stort marked for den som kommer først. For 10-15 år siden var der faktisk en LK IHC bridge på marked. Den var den del af produktet Elektronic Housekeeper. Produktet havde en kort levetid, da det var baseret på Z-Wave, men mange af hans komponenter var ikke kompatible med andre Z-Wave komponenter og så var det baseret på en abonnements ordning og krævede konstant internet adgang for at virke. Dertil kommer at supporten var ikke eksisterende, som det kan ses i denne tråd. https://www.ihc-user.dk/forum/forums/topic/1680-housekeeper/#comment-11339 Jeg kan ikke huske hvordan han kommunikerede med LK IHC, men jeg er ret sikker på at det ikke var via netværks interfacet. Hvis du søger på housekeeper her på boardet, vil du finde et par tråde om emnet, men ikke nogen reel brugbar information desværre. Jeg kender ikke Schneiders planer, og havde ikke mulighed for at deltage i deres Q&A møder. Men de har i flere år sagt at de arbejder på en gateway mellem LK IHC og Wiser samt KNX. Derudover sagde de allerede da Visual 3 controlleren blev frigivet at det vil være den sidste LK IHC controller. Jeg tror det eneste som er kommet bag på Schneider er hvor hurtigt Visual 3 controlleren blev udsolgt. Deres plader om godkendelser er noget ævl. Det er interne godkendelser som mangler. De eneste eksterne godkendelser de har brug for er til CE mærket. Markeds standarder er også noget ævl. De havde ikke noget problem med at frigive Visual 3 controlleren, selvom den LANGT fra levede op til datiden markeds standarder. At lave en Wiser/KNX gateway som også kan kommuniker med LK iHC wireless og RS485 bus er en større opgave end at finde erstantning for de komponenter som er udgået i den eksisterende controller.

https://en.wikipedia.org/wiki/Intelligent_Home_Control# I gamle dage var der et online LK kursus hvor de viste protokollen og hvordan man kunne se den på et oscilloscop. Jeg tror wikipedia artiklen passer godt med hvad jeg kan huske. I øvrigt har vi vist også et problem med de nye 2 kanal dimmere. Ud over at der aldrig er kommet en opdatering på de problemer folk oplever så har jeg ikke set noget forsøg på at dekode protokollen.

Og det er virkelig svært at slå en visual 2 controller ihjel. Ved gud jeg har gjort nogle ting hvor jeg troede den døde.

Ja det eneste "Med viewer" kan som den uden ikke kan er det indbyggede web/java baserede view - det er lækkert men er heller ikke blevet bedre med alderen. Ps. det er lykkes mig at få en ikke viewer til at køre med en viewer firmware - men mere om det senere.

Løst! Fandt batteri, frakoblede, slukkede for al strøm og genstartede - alt spiller

Først og fremmest gør den manglende afdækningerne af tavlerne din el-installation ulovlig. Det er en mangel, som du kan forlange udbedret på sælgers regning. Det samme gælder de løst hængende kabler. Vedr. den PC i har fået udleveret. Prøv at kigge en ekstra gang, om ikke der ligger nogle program backup'er på den. Det er meget længe siden jeg sidst har haft fat i Visual 1 softwaren, men såvidt jeg husker hedder IHC program filerne også .vis der. De burde være tilgængelige via Visual programmet i file menuen øverst til venstre i Visual programmet. Sammen med PC'en skulle du også MEGET gerne have fået udleveret det kabel som skal bruges mellem Visual 1 controlleren og PC'en. Uden det kabel er PC'en ikke meget værd. Men hvis du har kablet er det relativt nemt at tilslutte PC'en og downloade programmet fra controlleren, såfremt at du ikke har en af de Visual 1 controller hvor com porten stod af efter nogle år. Skulle du ende i den situation at du slet ikke kan finde nogle program backupper, og ikke kan trække programmet ud af controlleren så har @Henning Pedersen et værktøj, som gør det nemt at finde alle ind og udgange samt hvad der er tilsluttet dem. Desværre virker det kun med en Visual 2 eller 3 controller. Som Mikkel skriver, kan du opgrader din installation ved alene at udskifte controlleren til en nyer model. Den nyeste hedder Visual 3, men den har desværre været i restordre i et godt stykke tid nu. Visual 1 og Visual 2/3 er ikke program kompatible. Programmet til Visual 2/3 skal laves fra grunden. Programering kan gøres offline (kræver dog at du ved hvad der er monteret hvor), således at tiden uden lys m.m. under udskiftning er mindre end 1 time. En ny controller koster op til 10.000 kr. alt efter hvordan du køber den. En brugt Visual 2 controller kan typisk fåes for 2-4.000. En ny Visual 3 controller kan i en webshop fåes til om.kring 6-7.000 kr. Programmering kan nemt komme til at koste 10.000 kr. incl. fejl finding når controlleren er skiftet. Selve udskiftningen af controlleren tager som tidligere skrevet en times tid. Hvis du ved lidt om IT er det ikke så svært at lave programmeringen selv. Man skal dog lige sætte sig 20 år tilbage i tiden da LK IHC stort set ikke er ændret siden Visual 2 kom på marked i 2005. Softwaren kan downloades gratis fra https://www.lk.dk/professionel/support/varktojer/download-software/ Det kræver et login, men alle kan oprette sig som bruger, ganske gratis. Jeg kan desværre ikke anbefale nogen elektriker med IHC erfaring. Men eftersom du har PC'en med softwaren til Visual 1, og forhåbentlig også har kablet mellem controlleren og PC'en så vil jeg tro at alle elektriker som reklamer med LK IHC vil være istand til at hjælpe dig. De plejre at stejle overfor Visual 1 controller grundet den bruger RS232 til kommunikation med PC'en mens Visual 2 og 3 har USB og Ethernet netværks interface i steddet. Men når du har PC'en og kablet, bør dette ikke være noget problem, da Visual 1 et stykke hen af vejen ligner Visual 2/3.

Reset bruger firmwaren eksister fordi det kan ske at en bruger bliver corrupt. Specielt i ældre firmware versioner. Det er dog relativt nemt at afgøre om det er et Java problem eller corrupt bruger problem. Man behøver bare forsøge at logge på AdminView via USB. Får man login fejlen ved brug af USB, er det et Java problem da login via USB ikke kræver bruger ID og password. Fejl beskeden er temmelig misvisende når der er tale om et Java problem, men det skyldes at "Login mislykkes" er en standard fejl besked som dækker alle kommunikations fejl i authentication sekvensen, hvad enten de skyldes forkert bruger ID/password eller at authentikering ikke kan gennemføres grundet manglende understøttelse af de forældede krypterings protokoller som LK IHC anvender. Kan man logge ind, men ikke ændre brugerne, er det et corrupt bruger problem, som reset bruger firmwaren kan løse.

Der er nogle fejl i LED dimmernes firmware, som kan give de fejl du ser. Det spøjse er at fejlene kan løses midlertidigt ved at firmware opgrader dimmerne med seneste firmware. Problemet med unlink kan også løses med en firmware opgradering af dimmerne. Jeg måtte firmware opgrader mine dimmer 3 gange med samme firmware før mine dimmer blev stabile og jeg igen kunne unlinke dem. De har nu kørt i snart 6 mdr. uden problemer. Når du firmware opgrader dine dimmer, så vælg firmware opgrader ALLE dimmer. Af en eller anden grund bliver problemerne ikke løst hvis man vælger at firmware opgrader dimmerne en af gangen.

Det går i princippet ikke galt nogen steder. LK har "bare" droppet deres gamle doktrin om at én og kun én funktionsblok styrer udgangen. Dermed er blokken kun tænkt til at skulle styre lyset fra det/de lokale tryk. Dit "Sluk Alt" scenarie skal så bare direkte ind på lampen, tilbagemeldingen i % vil fortælle funktionsblokken at lyset er slukket. Hvis du gerne vil beholde den gode standart med én og kun én FB pr. udgang så åbner du bare blokken og tilføjer en ny indgang som du f.eks. kunne kalde "Sluk" samt en ny scenarie udgang som passende kunne kaldes "Scenarie Sluk". I højre side laver du et nyt program og fører indgangen over på hændelse med "X - ON", Scenariet trækkes over med "Fremkald x". I selve IHC programmet trækker du det nye scenarie over på lampen med 0%, eller OFF hvis det var en relæ udgang. Nu vil det virke som ønsket.

Openhab og IHC Captain er ikke samlignlige på nogen måde.