Astronaut

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.