IHC controller udgår, ny gateway?

[Michael B. Andersen]

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

[Lars1]

Din idee om en gateway er langt fra ny. Jeg har samlet en oversigt over de forsøg jeg har kendskab til i bunden af mit indlæg i denne tråd. https://www.ihc-user.dk/forum/forums/topic/10812-hvad-er-alternativerne-til-lk-ihc/ Som du kan se er nogen af dem nået lidt længere end dig, men alle, bortset fra den sidste, er stoppet seneste da de skulle til at lave gateway API'et.

Dernæst vil jeg sige at bekymringen for at controlleren står af deler jeg ikke. Controlleren har vist sig at være MEGET stabil. Det som plejre at stå af er strømforsyningen eller wireless enheder. Resten synes at være RIGTIGT holdbart. Hvis controlleren endeligt skulle stå af, så har LK jo lovet at de kan reparer en Visual 3 controller nogle år frem. Der går endda rygter om en ny firmware der skulle fikse problemet med LED dimmer og scenarier. Derudover kan man sikkert finde en brugt visual 2 controller hvis det går helt galt.

 

Personligt så jeg gerne en gateway, med et standard inteface som f.eks. modbus eller andet som kan bruges via f.eks. OpenHAB, men sandsynligheden for at jeg erstatter min IHC installation med kip relæer når den ikke længere virker, er større end at jeg kaster mig ud i en gateway og OpenHAB eller tilsvarende.

 

[Michael B. Andersen]

Hej Lars,

Først af alt tak for kommentarer og du har ret, controlleren virker stabil! Egen erfaring er, at de IHC ting, der er gået død i mit system igennem efterhånden mange år har været Wireless dimser.

Mht. listen du henviser til, jeg kan ikke se nogle hobby projekter der direkte går på at erstatte IHC contolleren? Men jeg er med på at der er mulighed for integration med andre systemer, men så bliver man jo blot bundet op på et nyt proprietært system

Kigger lidt videre på det .... Skal lige have fat i nogle løse output moduler for test

 

 

[Lars1]

En gateway er integration til andre produkter som f.eks. IHC captain, OpenHAB etc. Hvis ikke du vil være afhængig af andre produkter til program afvikling, så er det en ny controller du forsøger at lave fremfor en gateway. Det vil selvfølgelig være MEGET interessant, men det er voldsomt mere komplekst end en gateway.

[Astronaut]

On 3/31/2024 at 11:34 AM, Michael B. Andersen said:

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

Jeg har haft samme tanker som dig, men da jeg har ganske få moduler i tavlen valgte jeg ikke at gå videre. Men jeg nåede at kigge på at bruge PIO funktionaliteten i Pico'en. Det skulle give mulighed for at læse input fra op til 8 IHC Input 24 moduler. Har man også output moduler så burde en enkelt Pico kunne klare op til 64 moduler (og så store IHC installationer tror jeg ikke eksisterer). Fordelen ved PIO er at man kan ramme helt præcist med timing selvom man har gang i mange IHC I/O moduler på samme tid.

Hvis du lader Pico'en kommunikere med omverden vha. MQTT så kan du ret nemt bruge Nodered, HA, etc. til at orkestrere det hele.

On 3/31/2024 at 11:34 AM, Michael B. Andersen said:

Bemærk jeg har ikke kigget på wireless delen af IHC (endnu)

IHC Wireless bygger som jeg husker det på en protocol der hedder Wavenis. Den slog aldrig an og bruges til meget få ting nu. Der lå på et tidspunkt et SDK på nettet men det er vist forsvundet. Problemet er at det der sendes er krypteret. Så du skal både have fat i et SDK, have liv i SDK'et (Jeg tror det er 15-20 år gammelt), have fat i noget elektronik sådan at du kan sende og modtage wireless samt have hacket LK's protocol sådan at du kan finde deres krypteringsnøgler (du skal sikkert udlæse firmware fra en IHC device eller fra en controller). Jeg tvivler på at det er det værd når man i stedet kan købe en stak Zigbee eller Z-wave komponenter og skifte wireless installationen ud relativt nemt.

[Astronaut]

PS: Her er min plan for at udskifte IHC.

 

 

[Michael B. Andersen]

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.?

[Michael B. Andersen]

Hej Astronaut,

Nu blev jeg jo nødt til at kigge på PIO for Raspberry Pico. Fik bygget en prototype software for test af IHC output "protocol" via PIO og det virker rigtigt fint og er noget simplere end IRQ timer styring. Det er også mere præcist mht. timing på output. Kigger nu på input / flere kanaler...

Så tak for input!

 

[Astronaut]

10 hours ago, Michael B. Andersen said:

Nu blev jeg jo nødt til at kigge på PIO for Raspberry Pico. Fik bygget en prototype software for test af IHC output "protocol" via PIO og det virker rigtigt fint og er noget simplere end IRQ timer styring. Det er også mere præcist mht. timing på output. Kigger nu på input / flere kanaler...

Fantastisk. Der er 8 PIO kanaler. Som jeg husker det burde det være muligt at drive 8 IHC Output moduler med en PIO kanal. Basalt set burde man kunne signalere til alle 8 moduler på samme tid og således blot bruge en kanal.

Input signalerne er ikke synkroniseret så de skal hver have deres egen PIO kanal. I praksis betyder det at en enkelt Pico kan håndtere 7 Input moduler og 8 output moduler på samme tid.

I Pico SDK'et er der en MQTT client der kan connected til en MQTT broker. På den måde vil det være muligt at publisere ændringer af inputs og tage imod kommandoer om at sætte outputs. Nodered, Home Assitant eller OpenHAB kan så bruges til at orkestrere det hele.

Put det i en kasse og lav en lille vejledning og så har du et produkt du kan sælge til alle dem der har en IHC wireless installation.

[Lars1]

1 time siden, Astronaut skrev:

Put det i en kasse og lav en lille vejledning og så har du et produkt du kan sælge til alle dem der har en IHC wireless installation.

Jeg gætter på at det skulle have stået noget i retning af "LK IHC installation UDEN wireless". Udover det vil løsninge heller ikke virke hos os som har LED dimmer. Men alt andet lige en løsning som nogle sikkert godt kunne bruge til at binde dele af deres installation sammen med andre produkter som kan erstatte LED dimmer og wireless delen.

[Astronaut]

2 hours ago, Lars1 said:

Jeg gætter på at det skulle have stået noget i retning af "LK IHC installation UDEN wireless". Udover det vil løsninge heller ikke virke hos os som har LED dimmer. Men alt andet lige en løsning som nogle sikkert godt kunne bruge til at binde dele af deres installation sammen med andre produkter som kan erstatte LED dimmer og wireless delen.

Det her du helt ret i. Der skulle have stået "uden wireless".

I øvrigt er det ikke klart hvorvidt RS-432 kommunikationen med de nye LED dimmere kan "hackes". Hvis LK har valgt at kryptere kommunikationen så bliver det svært. Jeg har et par ledninger hængende i min installation sådan at jeg kunne koble min egen RS-432 adapter på og se på det. Desværre kom jeg aldrig så langt. Men er kommunikationen ikke krypteret så er der muligheder. Principielt ville man sikkert også kunne hive evt. krypteringsnøgler ud af en IHC kontroller. Det lyder som om Mikkel har kigget på firmwaren i controllere.

Noget helt andet er Michael sikkert også vil have behov for at dekode kommunikation fra IHC temperatur sensorer o.lign. Men som jeg husker det så er den protokol beskrevet flere steder her på sitet. Det burde ikke være svært for "Pico'en" til at gøre det.

[Michael B. Andersen]

Ja helt enig. Picoen har 2 PIO kanaler, hver med 4 state machines. Output kan synkroniseres og output shift registret er på 32 bit og der bruges 9 bit (8 data + paritet) til hver output kanal, dvs. hver state machine kan i princippet styre 3 output. Det hele lettes yderlige af at ændringer i output er (relativt) sjældne - ihverfald i min installation - og derfor kan data "genbruges" og det kræver så hverken FIFO eller DMA for at levere data til output. PIOen kan selv køre det hele.

Og ja input bliver lidt mere kompliceret  dels fordi det er asynkront og data skal fjernes eftersom PIOen ikke kan sortere i input og levere ændringer (eller rettere jeg kan ikke finde ud af det :-)). Dvs. alle input data skal omkring CPUen for check af ændringer, anyway det er nok nemmere end noget via IRQ.

Jeg har ingen kommerciel interesse i det her - det er mest hobby og måske for at lave en backup mikro IHC controller til  styring af mit eget IHC anlæg, hvis controllere dør. Omvendt skal jeg gerne frigive diagrammer SW osv. hvis nogen vil bygge videre på det - men først når jeg er lidt længere...

[Astronaut]

1 hour ago, Michael B. Andersen said:

Og ja input bliver lidt mere kompliceret  dels fordi det er asynkront og data skal fjernes eftersom PIOen ikke kan sortere i input og levere ændringer (eller rettere jeg kan ikke finde ud af det :-)). Dvs. alle input data skal omkring CPUen for check af ændringer, anyway det er nok nemmere end noget via IRQ.

Nu har jeg ikke selv prøvet at skrive koden men du har to registre X og Y - man kunne fx. gemme den foregående værdi i det ene af dem. Og så er der en JMP instruktioner der bl.a. kan hoppe på X!=Y. På den måde kan man raise et interrupt hver gang værdien ændrer sig. Det vil blive ganske få interrupts i sekundet og på den måde vil CPU'en have god tid til netværk eller andre ting som fx. hvis man putter et lille I2C display på til at vise status.

[Lars1]

4 timer siden, Astronaut skrev:

I øvrigt er det ikke klart hvorvidt RS-432 kommunikationen med de nye LED dimmere kan "hackes".

Jeg gætter på at du mener RS-485.

4 timer siden, Astronaut skrev:

Noget helt andet er Michael sikkert også vil have behov for at dekode kommunikation fra IHC temperatur sensorer o.lign. Men som jeg husker det så er den protokol beskrevet flere steder her på sitet. Det burde ikke være svært for "Pico'en" til at gøre det.

Der ligger et link til den bland de andre protokol links i bunden af oversigten over LK IHC alternativer. Men såvidt jeg ved er den ikke meget anderledes end kommunikationen med I/O modulerne. Det mest komplekse er der kun sendes 1 bit for hvergang input modulerne sender status på de enkelte indgange. Man skal derfor opsamle status på en input indgang 14-20 gange før man har værdien på temp. sensoren. Det vil derfor nok være smarter at forbinde temp. sensorne direkte til PIO'en istedet for via et input modul. Temp. sensoren sender jo ikke andet end en simple bit strøm, præcis som input modulerne.