Astronaut
-
Antal indlæg
302 -
Medlem siden
-
Senest besøgt
-
Days Won
13
Indholdstype
Profiler
Forummer
Downloads
Galleri
Indlæg skrevet af Astronaut
-
-
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?
-
On 12/27/2023 at 6:51 PM, Lars1 said:
Har du prøvet den wireless rebuild funktion som kom med Visual 3?
Nej. Den kender jeg ikke og har aldrig set den. Ved du hvordan man aktiverer den?
-
2 hours ago, Henning Pedersen said:
Hvis du ikke har prøvet et uploade et tomt projekt med genstart, så prøv det lige inden du laver for meget. Jeg er ikke helt med på hvad der sker ved det, men det retter ofte nogle mærkelige fejl.
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"?
-
On 12/9/2023 at 3:16 PM, Rompa said:
Hej igen, tyvärr så ser det inte ut att kunna använda senare operativsystem än XP enligt denna text på deras hemsida;
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.
-
On 11/8/2023 at 4:15 PM, Lars1 said:
Wiser og Philips HUE kan LANGT fra det samme som LK IHC og vil være relativ dyre løsninger hvis man bare skal kunne tænde og slukke noget lys
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.
-
15 minutes ago, Lars1 said:
Jeg har haft en kammerat som til dagligt udvikler embeddede systemer til at kigge på om man vil kunne får en Raspberry PI til at kommuniker med I/O modulerne via GPIO interfacet. Han mener ikke at den er stabil nok til at kunne aflæse tidskritiske signaler som dem som kommer fra input modulerne. Måske er det det samme problem med Arduino boardet?
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.
-
On 10/22/2023 at 8:18 PM, Mads M said:
Men jeg kan ikke få noget ind hvis jeg sætter et IHC input 24 til min Arduino og flasher med BasicInput.ino, det virker fint hvis jeg sætter et output fra min IHC Controller på samme indgang på min Arduino.
Så koden virker men den vil bare ikke direkte med et Input modul, er der nogen der kan hjlæpe?
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.
-
20 hours ago, Lars1 said:
Derfor synes jeg det er fair at du nævner hvem der har problemer med LED dimmer som ikke er blevet løst via en firmware opdatering, en kabling som overholder RS485 standarden eller en ombytning grundet fejl på dimmeren.
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.
-
On 10/17/2023 at 10:04 AM, Lars1 said:
Problemmet med LED dimmerne er derfor næppe RS485 bussen, men at firmwaren over tid "glemmes" i dimmerne. Dette problem vil være det samme ligegyldigt om du bruger wireless eller kablet kommunikation.
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.
-
On 10/15/2023 at 5:10 PM, Lars1 said:
Der er andre som har samme synspunkt som mig. Både på dette board og udenfor. Men det er egentlig en ret ligegyldig diskution IMHO. Prøv at gå efter bolden i steddet for manden.
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.
-
17 hours ago, Lars1 said:
Jeg tror ikke det specifikt er z-wave som der er berørings angst for. Vi er bare nogle som har en del erfaring med wireless kommunikation. Wireless kommunikation er bare ikke så stabilt som kablet kommunikation, ligegyldigt hvilket produkt du vælger. Problemerne bliver særligt tydeligt jo større din installation bliver.
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.
-
6 hours ago, Torben V said:
Lars1, perfekt det vil jeg da lige prøve at kigge lidt på.
jeg har været inde på https://www.dingus.dk/arduinoihc/ , men kan ikke helt finde ud af om det kun er Arduino til ihc input også hen til ihc controlleren eller om det er også kan bruges som standalone uden en ihc controller.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
-
10 hours ago, Lars1 said:
I den anden grøft er systemer baseret på åbne protokoller som KNX, Z-Wave, Zigbee m.fl. Her er problemet ikke så stort hvis en producent trækker sig fra marked, men tilgengæld har man udfordringer med at man sommetider løber ind i at produkter fra forskellige producenter ikke kan tale sammen, eller at produkter som er +10 år gamle ikke altid kan tale med nye produkter. Specielt Z-Wave har for år tilbage været hårdt ramt af dette.
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.
-
58 minutes ago, Bjarne Sørensen said:
Der var et Viewermodul til Visual 1 hvor man kunne udføre kommandoer via e-mails frem og tilbage.
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.
-
14 hours ago, Bjarne B. Dollerup said:
Wiser er ikke forskellige fra f. eks. Homey eller Smart Things. Det er en proprietær kontroller, der kan kommunikere med Zigbee enheder.
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).
10 hours ago, Lars1 said:Når det er sagt, er jeg enig i at det er lukket system og at der er lang vej før de har samme produkt bredde som LK IHC eller deres konkurrenter.
Wiser lyder ikke specielt lukket for mig.
-
12 hours ago, Bjarne B. Dollerup said:
Jeg har tidligere kigget på Homey og @Lofterpalle's indlæg om Niko har jeg også kigget på. Jeg er dog lidt loren ved endnu en løsning som binder mig på hænder og fødder til én leverandør, med risiko for at denne "forsvinder" af den ene eller den anden grund.
Jeg er helt enig. Ellers ender man med at stå med håret i postkassen igen.
12 hours ago, Bjarne B. Dollerup said:Jeg har en række udtag og tryk samt to grupper af halogen spots, som er koblet på Controller. Derudover har jeg 3 trådløse udtag. Derudover har jeg omkring 44 Zigbee og 22 Zwave enheder koblet op mod HA via Zigbee2mqtt og Zwave2mqtt integrationerne. Enheder er primært strømmålere, temperaturfølgere, PIR, lamper, etc.
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.
4 hours ago, Palleholgerjensen said:Jeg ville nok passe på med at vælge wiser, det jo stadig et lukket system og kun aktuelt på det danske marked. Jeg ville gå efter produkter som er mere internationalt på markedet i EU. Det kunne være KNX, Niko og z-wave eller zigbee produkter der hsr åbne protokoller der kan integreres i homey eller fibaro (bare ikke produkter fra SE)
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.
-
On 9/29/2023 at 6:28 PM, Palleholgerjensen said:
Du kunne arbejde som konsulent for Logic Group
He he he. Jeg har ikke brug for et nyt job. Når det er sagt så er min eneste interesse at gøre det klart hvad det er vi snakker om. Jeg har ikke selv truffet et valg om hvad jeg gør. Specielt er jeg i den situation at min installation primært er wireless. Det gør situationen lidt anderledes end mange andres. Min tavle har blot to input moduler (til PIR, magnet sensorer, temperatur/fugt sensorer) samt 3 stk. IHC DIN 2 kanal dimmere. Til gengæld har jeg 30 wireless stikkontakter og en del mere der skal skiftes på et tidspunkt. At ligge på gulvet og rode med for korte ledninger til stikkontaker er ikke lige noget jeg har lyst til.
Men en ting er sikkert er at jeg ikke vælger en løsning hvor en enkelt producents beslutning efterlader mig i samme situation som nu.
-
On 9/26/2023 at 10:15 PM, Nils B said:
Er virksomheder som for eksempel Logic Group potentielt ikke mere risikable at investere i, end IHC fra store Schneider var? Min forståelse er, at Logic Group har en proprietær controller og bruger Z-wave-teknologi i stedet for Matter, som måske er fremtidens standard. Er der noget, jeg overser i denne sammenligning? Hvordan er man fx stillet hvis Logic Group lukker om fem år? (ps jeg er vil med dansk producerede projekter, og ønsker Logic Group alt godt. Men jeg har ikke lyst til at stå med håret i postkassen endnu engang).
Logic Group kan forsvinde hver dag det skal være. Det er en relativt lille virksomhed.
Men køber du deres løsning så har du valgt Z-wave standarden - ikke en Logic Group løsning. Dit eneste problem hvis Logic Group går ned er hvis du i fremtiden ønsker at købe mere fra dem og de er væk.
De har ikke deres egen controller. De køber Fibaro's controller og sælger den videre til dig. Hvis du hellere vil have en anden controller så kan du bare købe en anden. Går Fibaro firmaet ned og du får problemer med din controller så kan du købe en anden Z-wave controller og køre videre.
Hvad der bliver fremtidens standard er et godt spørgsmål. Personligt er jeg ret bekymret for hvorvidt Matter/Thread bare er endnu måde for Apple, Google, Amazon, Microsoft at stikke næsen i mit liv. For når enheder bruger IP til at kommunikere så er det ikke langt til at alle enheder kræver en internet forbindelse og en cloud konto.
Men hvilken standard der vinder er lidt ligegyldigt fordi de i de fleste situationer kan co-eksistere. Undtagelsen er de situationer hvor du trykker på en tangent og så ønsker at lyset tænder uden nogen forsinkelse. Der er det pt. vigtigt at de er på samme standard. Men ellers kan Z-wave, Zigbee, etc. godt co-eksistere hvis blot man laver integration i controlleren. Din største bekymring bør således være om du kan købe Z-wave I/O moduler, stikkontakter, dimmere og betjeningstryk til dit fremtidige forbrug. For det er netop der hvor det er vigtigt at de er på samme standard. Resten mixer du bare sammen.
Enden på IHC ?
i Rygter
Besvaret
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.