Astronaut

Det store problem er at der er rigtigt mange custom designede funktioner i mange IHC løsninger. Min IHC løsning består fx. stort kun af custom komponenter og her på sitet er der folk der har levet af at lave løsninger med custom designede IHC funktioner fordi LK's lod meget tilbage. Derfor bliver det svært at hive noget brugbart ud af VIS filen for I vil kun kunne identificere nogle få standard IHC funktioner. Men kan I tage navne og så i øvrigt lade brugeren vælge ting som kip, dim, on og off i et UI. Evt. med en timer. Så er det vist så langt I kan komme hvis I skal holde det simpelt. Alt andet vil kræve at I laver en maskine der kan udføre IHC lignende programmer. Til gengæld åbner MQTT op for at andre kan bygge en "IHC engine". En maskine der kan køre IHC lignende programmer men hvor alle enheder tilgås over MQTT. Jeg tænker jeg ville kunne bygge sådan en på et par uger men desværre ved jeg intet om UI og der ville også være brug for en editor. Anyway, så vil det være muligt at indlæse en VIS fil i en sådan engine. En sådan engine er i øvrigt ikke langt fra hvad Nodered laver men Nodered kræver en hel del programmering hver gang man skal lave noget. Det gør at det tager lang tid.

Det ser spændende ud. Jeg har en række IHC PIR og magnetsensorer som det vil virke fint med. Men IHC LED dimmere (RS-432) er ikke supporteret. Er der nogen planer den vej? Alle mine tangenter er IHC wireless (jeg her skiftet nogen af dem til Zigbee) så det vil ikke fungere der. Det ville give mening at udvide dimsen med Zigbee sådan at der var en nem vej fremad for dem der ikke har trådet alle deres tangenter. Men jeg er blevet brændt en gang. Jeg har oplevet at stå med håret i postkassen. Vi er nødt at få lidt at vide om hvordan controlleren er lavet. Jeg tænker at I godt vil kunne fortælle om hvordan det er skruet sammen. Basalt set kunne I fortælle det samme som jeg ville kunne finde ud af hvis jeg købte en og åbnede den og analyserede printet i et par timer. Jeg er klar over at I har en forretning der skal køre. Men køber jeg sådan en tingest så er det for at have noget der kan fungere de næste 10-15 år. Valget af MQTT er strålende for det gør at selv hvis der dukker sikkerhedsissues op, så kan vi gemme den bag en firewall sådan at den ikke er udsat. Det bedste ville selvfølgeligt være at I fiksede evt. problemer, men som kunder vil vi være nødt til at operere ud fra en betragtning om at der til ethvert tidspunkt ikke kommer flere software opdateringer. MQTT gør det også muligt at lave ret kompliceret programmering - fx. i Home Assistant eller Nodered. Det er klogt at vælge ikke at supportere alt muligt avanceret når det gælder programmering selvom lidt mere en kip ville være smart. Spørgsmål: - Hvilken CPU/Microcontroller bruges? - Hvor meget RAM er der? - Bruges der flash ram? Hvor meget er der? Er det loddet fast eller kommer det fx. som M.2 SSD? - Hvordan driver I (rent elektrisk) input og outputs? - Er der noget Operativ System i dimsen? Hvilket? - Er softwaren låst eller ville man være i stand til at uploade egen software til den i tilfældet af at I stopper med support?

Opdatering. Her til morgen genstartede jeg controlleren efter at den har kørt i 3 måneder. Erfaringen er at wireless nogen gange kan "repareres" med en genstart. Jeg brugte Kaptajnens funktion til at genstarte. Da controlleren kom op efter genstart var den i fejltilstand. Der var netværksadgang men selve IHC delen kørte ikke. Hvad der ikke virkede: Genstart af controlleren Reset af controlleren (på reset knappen) Gen-upload af 3.3.44 firmware Hvad der virkede Upload af reset firmware til controlleren Gen-upload af 3.3.44 firmware Gendan af IHC programmet Herefter var jeg tilbage hvor jeg var i går. Heldigvis så er jeg langsomt ved at få reduceret mit IHC footprint sådan at ulykken var mindre end tidligere. Det ændrer ikke ved at Schneiders IHC 3.0 controller er noget skrammel. De burde sagsøges for at levere et ikke færdigt produkt.

Det ser sgu smart ud. Bekymringen er selvfølgeligt om det kun virker sammen med Ikeas Dirigera Hub og jeres egen hub. Et problem med Zigbee kan være om jeres dims ligner andre lignende dimser sådan at det virker automatisk. Det ville således være interessant hvis I havde vist at det virker sammen med en række andre kendte ZigBee hubs. Umiddelbart tænker jeg at dette kan bruges til at få inputs fra alle mine magnet-, PIR og røgsensorer ind i en ZigBee hub og således kan bruges til fx. at tænde lys automatisk. Jeg tænker at de fleste professionelle ikke vil være i stand til at vurdere jeres produkt. Jeg tror således at I skal regne med at det bliver private der driver salget og/eller I kommer med nogle ret færdige løsning som er lige til at sætte op.

Alle de Ikea pærer jeg har prøvet virker.

Ja, men det er ikke helt klart for mig hvornår der laves backup til SD kortet. Sidst var jeg nødt til at smide reset firmware på og på et eller andet tidspunkt overskrev controlleren det der lå på SD kortet. Der er liv i skidtet igen. Jeg ved ikke helt hvad jeg gjorde. Jeg kunne ikke få kontakt med controlleren over USB hverken med visual, din java starter eller med firmware updateren. Jeg resatte controlleren flere gange. Ingen kontakt. Holdt pause. Ingen kontakt. Resatte controlleren. Pludseligt virkede det. Da jeg kom på kørte jeg gendan og det ser ud til at alt virker igen nu.

Her til morgen havde vi en strømafbrydelse i nabolaget. Spændingen på en af faserne faldt til ca. 180V i en halv time og så forsvandt den helt. Desværre var den netop den fase som IHC controlleren kører på. Nu står den så og blinker normalt. Desværre kan jeg ikke komme i kontakt med den men der er da håb om at det kommer til at virke. Desværre betyder det sikkert at jeg skal rundt og genlinke alle wireless komponenter. Hvor er det bare elendigt. Det samme skete i Januar hvor vi også havde problemer med netop den fase. Hvorfor laver man et produkt der er så følsomt overfor strømafbrydelse?

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.

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.

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.

PS: Her er min plan for at udskifte IHC.

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

Det er lidt knudret skrevet. 03.04.72 er versionen på visual programmet. Ikke IHC firmwaren.

Jeg har også en wireless dimmer (HW2) der nogen gange driller. Når lyset har været tændt i lang tid så kan den finde på at gå i koma. Trykker man på knapperne til dimmeren så vågner den op igen. Tager man strømmen til dimmeren så vågner den også op. Eneste belastning på den er en 15W LED pærer.

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.