Astronaut

Som Lars skriver så skal du overveje hvad du ønsker i fremtiden uden at tænke for meget på hvad du har nu. Når det er sagt så er IHC dødt. Du kan sikkert købe brugte komponenter de næste mange år men på et tidspunkt vil det også blive svært. Du skal også være opmærksom på at de dimmere du har i tavlen har problemer med LED pærer. Der er ingen rigtigt gode løsninger på det problem efter at LK dræbte visual 3 controlleren. Før eller siden vil integration til Home Assistant og OpenHAB også dø når dem der har lavet det går videre til noget andet. Så uanset hvad det er du ønsker i fremtiden så vil det være en god ide at flå IHC ud nu mens du er i gang. Du kommer givetvis til at gøre det på et tidspunkt indenfor de næste 5 år alligevel.

Det kunne lyde som om det ville være en god at tage backup of SD kortet sådan at man har wireless links gemt. I praksis gør det ikke noget at det er et gammelt projekt der bliver restored. Jeg kan givetvis finde en nyere version fra en backup senere. Jeg går ud fra at man skal slukke controlleren inden man tager SD kortet ud.

Det store spørgsmål er hvad Wiser er. Det er ganske rigtigt at LK's Wiser Gateway ikke er meget værd. Men alle deres Wiser tryk, stikkontakter, lysdæmpere, etc. synes blot at være Zigbee komponenter der kan virke sammen med en generisk IoT hub. På den måde kan man få alt den programmering man har lyst til. Det kan også blive mere avanceret end IHC fordi programmeringsmulighederne er bedre, fordi 3. parts zigbee komponenter kan bruges og fordi integration med resten af verden er bedre. Problemet er at der ikke er nogen god vej frem for tavlekomponenter.

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.

Er der mulighed for at få alle inputs ud på MQTT på en nem måde? Eller skal man konfigurere hvert eneste man ønsker at få ud på MQTT?

Nej. Den kender jeg ikke og har aldrig set den. Ved du hvordan man aktiverer den?

Det prøvede jeg flere gange. Desværre var controlleren i et state hvor den end ikke ville acceptere upload af et tomt projekt. Jeg prøvede også at lægge nyeste firmware ind (den samme som allerede lå på controlleren). Det gav heller ikke gevinst. Det var først da jeg uploadede reset firmwaren at den blev til at arbejde med. Da uploadede jeg først et tomt projekt og så en backup af det oprindelige. Det gav gevinst. Bortset fra at alle wireless devices var i zombie state.

Opdatering: Nu er vi kommet hjem og efter nogle timer er controlleren i live. Men alle wireless devices er i zombie-mode. Jeg uploadede den reset firmware der ligger her på sitet. Det fik controlleren til at vise datalinje forbindelser og at RF modulet var i live. Herefter uploadede jeg en kopi af mit projekt og nu kom DIN Dimmerne i live og det samme gjorde wireless devices men kun i zombie-mode. Zombie-mode betyder er wireless komponenter både er linket og ikke linket. Kigger jeg i visual så er de alle unlinket. Bruger jeg service view så kan jeg tænde og slukke outputs. Betjener jeg inputs så viser service view at de skifter state men de fleste trigger ikke noget output selvom de skulle (dem der virker er dem der kontrollerer DIN dimmers). Kigger jeg i kaptajnen så er listen over linkede devices tom (se billede). Men på siderne for de individuelle rum kan man se både batteri og signalstyrke (se billede). Alle wireless komponenter er således i et mystisk state hvor de både er linket og ikke linket. Mystisk. I morgen vil jeg manuelt genlinke det hele.

Den 23. December klokken 13.10 genstartede vores IHC controller spontant. Vi var ikke hjemme og er stadigvæk ikke kommet hjem. Der var ingen aktivitet i hjemmet på det tidspunkt. Jeg kan se at controlleren er gået i fejltilstand hvor hverken datalinjemoduler, wireless eller DIN dimmers virker. Jeg kan kontakte controlleren over nettet og visual kan også få fat i programmet men selve controller funktionen synes død. Er det enden på vores IHC "oplevelse"? Er der nogen der har erfaring med "I fejltilstand"?

Lars har helt ret. Programmet kan godt køre på Windows 10. Du skal bare have en USB-RS232 dongle der er supportet. Desværre er det 5 år siden jeg sidst har rodet med Visual 1 så jeg kan ikke hjælpe dig mere andet end at sige at jeg for 5 år siden havde Visual 1 til at køre på Windows 10. Jeg kan ikke huske detaljer.

Jeg er ikke ekspert men kører med den her: https://github.com/arberg/docker-ihccaptain Som jeg husker det så gik det ret glat at få det sat op men jeg kan ikke huske detaljerne. Det er ikke så ofte jeg roder med docker.

Hvis man har en "avanceret" controller ifbm. Zigbee (aka Wiser og Philips HUE) eller Z-Wave så kan man lave rigtigt meget af det samme som med IHC. På de fleste punkter er mulighederne langt større men på nogen punkter også dårligere. Fx. kan en IHC controller måle ret præcist hvor længe en tangent er nedtrykket. Det kan man ikke nemt med andre produkter.

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.

Det burde være præcist samme protocol der kommer fra et input modul som der kommer fra et ulige output fra controlleren. Man bruger det til at koble to controllere sammen (output to input). Har du et oscilloscop du kan sætte på sådan at du kan se hvad der sker? Men når jeg kigger på koden for input så er det noget mystisk omkring bit 8-15 ... jeg er ikke helt sikker på det virker som forventet.

Basalt set ved vi ikke hvad problemet er i LED dimmerne. Det synes ret usandsynligt at de glemmer firmwaren for den gemmes i flash ram. Enten virker det eller også virker det ikke. Men når en geninstallation af firmware giver resultater så er det sandsynligvis fordi det resetter en del af opsætningen i dimmeren. Men for nu at komme med et eksempel på problemer der synes relateret til wired kommunikation så kommenterede du d. 24. Marts på et problem som viste sig at skyldes at en lampe fik en af dimmerne til at støje på RS-485 bussen. Og nej, wired er ikke bare noget der virker eller ikke virker. Jeg er uddannet elektronikingeniør. Støj, kapacitans, induktans, etc. er analogt og kan således dukke op over tid og komme og gå. Fx. kan fugtighed i luften kan ændre karakteristika. Slut herfra.

Der har været flere historier om folk der ikke kunne få LED dimmerne til at virke ordentligt selvom de har sat termineringsmodstand på. Problemet synes ikke at være at firmwaren glemmes men at kommunikationen er ustabil. Anyway, som jeg skrev tidligere handlede min kommentar om at wired kommunikation også kan give problemer. Det bør ikke komme som en overraskelse for nogen. Kapacitans i kabler kan give alle mulige sjove overraskelser når kabler bliver lange. Dårlige samlinger det samme. Jeg kunne fortsætte.

Du valgte selv at snakke for en gruppe uden af navngive den. Jeg syntes det var vigtigt at gøre klart at dit synspunkt omkring wireless er et du står ret alene med. Det er i øvrigt meget skægt at et af de steder hvor vi pt. har flest problemer med IHC kommunikation er med Schneiders RS-485 bus ifbm. deres LED Dimmere. Kabler er heller ikke uden problemer. Hvis man laver wireless og kabel protocoller dumt så giver det problemer. Laver man det rigtigt så virker det rigtigt godt. Begge dele. Men i sidste ende er det ligegyldigt. Wireless har vundet. Det er det er rulles ud kloden rundt. Det er bare ikke IHC Wireless.

Skal vi ikke blive enige om at det primært er dig er mener at wireless kommunikation generelt er et problem. De fleste kan blive enige om at Schneiders IHC Wireless protocol er et problem., men jeg synes ikke at have hørt andre der har wireless-fobi i samme omfang som dig.

Som jeg læser det så er det kode der implementerer IHC protokollen sådan at en Arduino kan snakke med IHC modulerne. Controlleren er således ude af billedet. Koden er ret gammel og skrevet som demo kode. Der er et stykke vej igen for at få den til at lave noget fornuftigt. Jeg tror det bliver svært at få den til at virke med mange IHC moduler på samme tid. Personligt ville jeg vælge en Raspberry Pi Pico W, som ligesom Arduino og ESP32 kan programmeres vha. Arduino IDE og de fleste libraries kan også bruges. Den har Wifi og nogle interessante PIO funktioner som burde kunne bruges til at implementere IHC protokollen sådan at resten af koden ikke bliver så tidskritisk og sådan at der er ressourcer til andet end WIFI og kommunikation. Hverken ESP32 eller Arduino har PIO funktioner indbygget i hardwaren - det betyder at hver eneste puls skal generere et interrupt. ESP32 reserverer også den ene kerne til Wifi. Det er i øvrigt spændende at han mener at det hele kan laves uden optocouplere mellem Arduino/ESP32/Pico. Det gør det simplere.

Du har brug for noget hardware for at få alle dine moduler til at snakke med HA. Basalt set skal du implementere IHC's puls tog protocol i fx. en PLC. Jeg tænker at det er et relativt stort projekt hvis du ikke har prøvet den slags før. At lave styringen i HA ville være for ustabilt for undertegnede. Jeg har oplevet at der kom en opdatering til HA som i praksis lagde HA ned i 2 uger

Den slags kompatibilitetsproblemer forsvinder typisk over tid. Under alle omstændigheder er der normalt veje omkring det. Under alle omstændigheder er problemet med IHC ikke at Schneider valgte at slå det ihjel. Det var forventet. Problemet var måden det skete på. Det er ganske enkelt uanstændigt at vi lige nu - 4 uger efter meldingen - står i en situation hvor vi ikke kan være sikre på at kunne finde "reservedele" til systemet.

Nemlig. Men der var ikke noget API i stil med det som kom med visual 2 og 3 controllere. Til gengæld kunne man styre alle I/O med RS-485 bussen. Men så skal man lave alt selv.

Jeg tror vi skal blive enige om hvad vi mener når vi snakker Wiser. I mine øjne er Wiser er også alle komponenterne. Spørgsmålet er hvorvidt fx en Wiser stikkontakt er standard Zigbee og således kan bruges med non-Schneider Zigbee komponenter. Mindre vigtigt men alligevel interessant er det hvorvidt Wiser kontrolleren kan kommunikere med non-Schneider Zigbee. Grundlæggende er spørgsmålet hvorvidt man står med håret i postkassen hvis Schneider i morgen holder om med at producere Wiser (uanset hvor realistisk nogen måtte mene dette være). Wiser lyder ikke specielt lukket for mig.

Jeg er helt enig. Ellers ender man med at stå med håret i postkassen igen. Jeg stoler ikke nok på HA til den slags. Jeg har en gang oplevet at det tog mig en uge at komme tilbage til noget der fungerede efter en opdatering og efterfølgende forsøg på restore af backup. Det er ikke klart hvor lukket Wiser er. Det synes efterhånden klart at det er Zigbee under overfladen. I beskrivelsen af supportede devices for Zigbee2mqtt står der også at Wiser er supportet. Det ville således være interessant at se om Wiser kan fungere med en kommerciel 3. parts Zigbee "controller". Det er vist det samme med dele af Niko systemet (men noget af Niko systemet synes at bruge lukkede protokoller).

Vi mangler faktisk noget feedback om Wiser her på sitet. Jeg er stadigvæk ikke blevet klog på om det bare er Zigbee produkter med et Schneider stempel på og hvor de kan fungere sammen med alt andet Zigbee grej. Eller om det rent faktisk er en lukket Schneider verden.