Bjarne Sørensen

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" :-)
 

Jeg er ret sikker på at viewer modulet er til HW 6.1 uden viewer. Mig bekendt har der aldrig været et viewer modul til Visual 1. Det var noget som kom med Visual 2, hvor den første controller blev solgt i 2 udgaver. En med viewer og en uden viewer. Fortrød man og ville opgrader til en med viewer kunne man købe et eksternt viewer modul i steddet for en ny controller. Mener prisen for controller uden viewer var ca. 2/3 af controllerne med viewer og en løs viewer var ca. halv pris af en controller med viewer.

Det er bare en dum enhed der skal have 24V så åbner den (voks der varmes langsomt op).
Har du ikke en transistorudgang? Det er ikke smart med et mekanisk relæ der står i tavlen og klikker 2 nagde i sekundet når en LED i et tryk skal blinke.
Mine gulvfølere ligger i gulvet og er ikke alle lige til at skifte. I bedste fals skal dørgerikter af og dørkarmen afmonteres og man skubber en ny føler i flexrøret. I værste fald skal gulvet brækkes op.
Kan man styre efter en minimumpemperatur på gulvet og rummet som med LK?
Her står hvordan de virker: 
 
Der kommer 1 puls pr kWh ja. De skal have hver sin indgang på controlleren og pulser skal samles sammen af controlleren og der skal være statistik på data og en oversigt over forbrugt strøm pr dag, uge, måned, året en sum for året og en som fra de forrige år. Ugens forbrug osv.
 
Jeg tænker at der er mange her der følger med så det ville også gavne dit salg hvis du åbent kunne skrive her hvad jeg skal bruge af dele og hvad de ca ville koste samt hvor jeg kan købe delene.
Men jeg sender dig lige en privat besked her med min installation og min mail, så kan du sende mig et udspecificeret tilbud.
Edit: 1 puls pr Wh / 1000 pulser pr kWh. Kan controlleren følge med når der kommer 4,7 pulser pr sek og fra flere målere samtidig?

LK har siden LK IHC blev lanceret i 1991 lavet 4 forskellige generationer af LK IHC controller. De er alle næsten 100% HW kompatible, hvilket vil sige at man kan op/nedgrader sin LK IHC installation ved kun at udskifte controlleren. Alle I/O moduler som er forbundet til I/O portene på en controller vil virke med samtlige generationer af LK IHC. LK IHC enheder som er tilsluttet controllerne via RS485 bussen eller wireless vil som udgangs punkt virker ved en opgradering, men ikke nødvendigvis ved en nedgradering. Enkelte produkter som f.eks. voice og ældre SMS modems er dog ikke understøttet af Visual 3 controllerne.
Visual 2 programmer kan bruges direkte i Visual 3 controller uden ændringer, ligesom et TermIHC program kan bruges direkte i en Visual 1 controller uden ændringer. Dette er desværre den eneste software kompabilitet der findes på tværs af de 4 generationer.
En fuld oversigt over LK's IHC produkt portefølge kan findes her. https://www1.lk.dk/katalog/fam/14.html
 
Visual 3 (August 2017 - August 2023):
Visual 3 controlleren er den sidste generation af LK IHC. Der kommer ikke nogen ny LK IHC controller fra Schneider. Controlleren kan genkendes ved
Vare nr. 820B1600 En QR kode på fronten. En reset knap på fronten. SD card i toppen. Antenne nederst til højre S0 indgang øverst til venstre RS485 bus i toppen.
Visual 2 (2006 - 2017):
Visual 2 findes i 3 udgaver. Det er desværre meget svært at se forskel på dem, og for varianterne med viewer kræver det at man logger på AdminView for at se om det er en HW 6.1 eller HW 6.2 controller man har. Det var en kort overgang muligt at købe en ekstern viewer til HW 6.1 uden viewer. Desværre har jeg ikke kunnet finde noget billed af den.
Alle Visual 2 varianter Antennen sidder øverst til venstre LAN stik nederst til højre HW 6.1 uden viewer (2006-2012 Vare nr. 820B1202 Teksten på controlleren er "IHC Visual Controller" HW 6.1 med viewer (2006-2012) / HW 6.2 med viewer (2012-2017) Vare nr. 820B1400 Teksten på controlleren er "IHC Visual Controller/Viewer"
Visual 1 (2000-2006):
Visual 1 controlleren ligner TermIHC controlleren rigtig meget, og bliver ofte forvekslet med denne, men man kan genkende en Visual 1 controller på nedenstående punkter.
Vare nr. 120B1202 Tekst på controlleren. Modul 1 tekst "IHC controller Visual". Modul 2 Ingen tekst.
 
TermIHC (1991-2000):
TermIHC controlleren ligner Visual 1 controlleren rigtig meget, og bliver ofte forvekslet med denne, men man kan genkende en TermIHC controller på nedenstående punkter.
Vare nr. 120B1200 og 120B1201 Tekst på controlleren. Modul 1 tekst "IHC controller", Modul 2 tekst "IHC I/O Interface"
 
 
 
 

Jeg har været inde og kigge på din hjemmesiden.
det er jo fine produkter, der uden tvivl kan en hel masse. Jeg dog usikker på hvilken controller jeg skal bruge af de mange slags du har.
Jeg har som sagt ca. 15 stk dimmere til diverse LED spots.
Derudover en del stikkontakter der kan tændes over relæ. Det er 10A belastning pr stk, i hvertfald for dem i køkkenet og de udendørs.
Så har jeg en del 24V statusdioder i tryk.
 
Som input har jeg ca 15 stk Zigza (som lk's) temperatursensorer der sender en bitstrøm for rum- og gulvtemperatur.
Og så har jeg ca 15 stk. telastater 24V AC/DC til gulvvarmen.
Udover det har jeg vel en ti stykker af el-målere med SO puls udgang, de kører på et almindeligt input.
Så har jeg en undertavle i garagen med 16 inputs og 8 230V relæudgange og 8 stk 24V DC udgange til diverse. Kan jeg sætte et decentralt modul til det?
Jeg ser frem til at høre fra dig hvad jeg skal bruge og til hvilken pris.
PS. Kan man køre den APP på dansk så familien har en chance?

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.

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

Shelly har meldt deres forslag ud.
https://shelly.guide/ihc-til-shelly-konvertering/?fbclid=IwAR0xmLwkgrOKXf0wFODWFafBp2zmUd4hV7IiOGIp4g5RAN0UAoUnnrdadAw
 
Med kursus
https://us06web.zoom.us/webinar/register/WN_SRFPp1PjQz6IFvIyII6Ytg?fbclid=IwAR1XeqUQtZOzCSwGgI6Rs1d9gI-O_5T-Z92mgJsO2s0iERMZm-l3PfB5Qx4#/registration

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 :-)
 

Hej Allan. 
her er der nogle der har løsningen til dig:
https://www.dingus.dk/ihc-temperatur-protokol/?fbclid=IwAR13iotonyTn7FY3SdgR5BIPdzJrK7ger5rmMgqaFysY2dxWwvEM9wvU1yk_aem_ATppmQDuOYpVryPKIwBQxmVZ8yimqx93i0Dd_zzWuobHtsyIQmYpiFGrd1Cd76W2_PY

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.

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.

Jeg må desværre trække lidt i land.
Da jeg slog Zigza temperaturfølere op, fik jeg fejlagtigt læst mig til det var PT1000 sensorer. Det er det vi kan få direkte ind på indgangene i ZIF5031.
Lars har gjort mig opmærksom på min fejl og som jeg også har skrevet i svaret til ham, så kan vi ikke kommunikere på IHC's protokol.
Jeg undskylder fejlen

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.

Der har jeg vrøvlet lidt, 0V DC skal ikke jordes. Men det gør man på maskiner og maskinanlæg med den ene AC pol.
Den trafo er fin.

Du kan se indgangen pulse i serviceview med det samme.
Du skal finde den elmåler version 5.1 som @Lars Jacobsen har lavet.
Den er genial og virker perfekt. Jeg har over 10 stk kørende. Jeg bruger iPad'en til at se målerne på hvor jeg har lavet et simpelt overblik på skærmen.
Du skal lige se hvor mange pulser din måler giver pr kW og så indstille det i funktionsblokken. Jeg vil også anbefale at du indtaster din nuværende målerstand, så kan du følge med og se om den bliver ved med at passe.
Jeg har flere målere det giver 1000 pulser pr kWh og der kan controlleren godt glemme lidt, men det retter jeg i serviceview en gang om måneden.
Du skal være opmærksom på at du kan smadre dine målerdata hvis ikke du gør det i denne rækkefølge når du skal lave rettelser i din projektfil:
1. Sluk controller (husk at fjern et evt. backupbatteri).
2. Start Visual på PC og vent til controlleren er helt oppe og køre. Så kan du hente din projektfil når upload/download ikonerne er blå.
3. Hent hele filen, lad den arbejde færdig med det. Gem filen på PC.
4. Rediger det du skal gøre, lad ikke PC'en gå i dvale osv. Gem filen.
5. Upload filen og lad den gøre det helt færdigt! inden du trykker på noget eller går i panik.
Så skulle din målerværdier være intakt, dog mangler pulser mens du arbejde i filen.

+1 på Henning. Han er prof og arbejder med IHC til hverdag og han lave det for jer så i bliver 100% fortrolige med installationen.

+1 på Henning. Han er prof og arbejder med IHC til hverdag og han lave det for jer så i bliver 100% fortrolige med installationen.

Alternativt kunne du sætte en temp. sensor på afgangen fra din buffer tank og så stoppe cirkulations pumpen i tidsrummet 17-20 hvis temperaturen kom under dit setpunkt.

Jeps.
https://andelenergi.dk/sel/netpriser/
https://cerius.dk/priser-og-tariffer/prisaendringer/

Jeg kan så oplyse at jeg begyndte igår, da jeg havde en pi model 3 liggende. Tidsforbrug er 1,5 dag med installation og en kop kaffe men jeg ventede Fik integreret rigtig mange enheder, UniFi, Apple tv osv. Fik også installeret SSH, VSC og hacs og skulle til at se på ændringer i brugerfladen da jeg fandt ud af den pi ikke har det så godt.
så jeg vil skifte til en NUC. 
 IHC fik jeg ikke integreret da jeg lige ville se det an først. Men er blevet klogere. Der er meget hjælp at hente på YouTube.
 

Selve integrationen tager ikke mere end en kop kaff's tid, hvis man har sine ID'er fra IHC klar til manuel setup. Automode er hurtigere, men ikke så fleksibelt.
Det er klart, så kommer der alt muligt automatik, som kan tage længere tid. 
Herfra kan man smide data videre til influxDB/Grafana, hvis man virkelig ønske at nørde data/grafer.

Måske ville det være bedre at installere HA på en rasperry pi og den vej gemme data. Det virker til at man kan meget når det først er i HA