Ok, Ik heb een eerste deftige versie van een custom component gemaakt. Die draait nu al enkele dagen en werkt redelijk goed.
Sprijtig genoeg zit er in de “get state” procedure die ik gevonden heb geen identificatie in het antwoord, dus moet ik met wat locks etc werken, maar het werk dus meh. Zelfs met 100 relays zou de update nog maar 2s in totaal moeten duren, dus da’s nog wel OK.
De update interval kan ook wel een pak hoger, want de internal state blijft consistent omdat de antwoorden van de CAN modules op drukknoppen ook rechtstreeks gelezen worden.
Die update / GET state zit er eigenlijk enkel in om bij het opstarten van HA de juiste state te krijgen.
Jouw systeem is anders, jij hebt andere commandos dan mijn SX systeem, is dat eventueel mogelijk om dat als variable aan te maken, dat je kan kiezen welke can messages gestuurd worden als een config?
de lights defenieer je hardcoded?
als laatste, ik gebruik HassOS , ik gebruik momenteel de SLCAN, probleem is dat deze niet default geladen worden met de kernel, dus daarom heb ik een addon gemaakt, als ik die opstart, dan laad ik ook effectief de kernel modules
is dat iets wat je ook vanaf een custom component kan doen?
after defining in the secrets.yaml, it worked.
But ofcourse, as it goes, I stumbled on a new issue.
it seems that my dobiss installation uses different hex values in TCP. (I believe I have an SX Evolution Pro but can be mistaken)
when I turn a light on, wireshark gives me the following data in the packets:
Ik ben overgestapt van een “experiment rpi” met Arch Arm + HA install op host naar een stabielere “dedicated” HA rpi met HAOS op een SSDtje, dus ik moest alles wat properder inpakken zodat ik mooi updates kan doen etc.
De code ondersteund nu ook mooi local push, dus de state in HA volgt live de lamen ook als je de schakelaar gebruikt.
Ja, had het idd al gevonden… Ik heb zelf de canable gekocht, denk al jaartje geleden ofzo… Heb toen ook PR submit voor de can drivers te loaden in HassOS, zoals Slcan etc…
Heb zelf ook een component actief, waarmee ik de can interface online breng… Dan heb je die add-on niet nodig… Werkt super en idd alle States zijn direct goed
Ik heb zo’n waveshare CAN+RS485 HAT, heeft altijd mooi gewerkt op die Arch Arm, maar de HAOS versie van de ip utils missen wat opties om de bitrate van de CAN bus te zetten. Daarom heb ik die add-on, daar heb ik controle over de versies van de utils etc.
Nu de RS485 nog aan de praat krijgen, maar das voor mijn zonnepanelen, dus misschien in een ander topic
Nee, de knoppen zelf gaan niet over de CAN bus, enkel de relay aan/uit commandos.
Ik heb wel eens gedacht om een bus snooper op die onewire te hangen, maar heb ik tot nu toe nog niet nodig gehad.
Ik heb nu voor mijn dimbare verlichting de dimmers rechtstreeks op de 230 aangesloten, dus die relays schakelen niets eigenlijk. Met een HA integration koppel ik die zodat als de relays uit gaan, de dimmer mee volgt.
Niet ideaal, maar werkt goed genoeg.
Ik denk dat de CAN data hetzelfde is eigenlijk. Toch voor de basics.
Ik heb wel wat voorbeeld data in de readme staan denk ik, moest je eens met candump willen vergelijken.
Ik heb ook wel bereid om support voor andere generaties in te mergen, maar ik kan die natuurlijk niet goed testen
Om 1 of andere reden is 41 de eerste module, bij ambience is dat gewoon 01 dacht ik… Voor de rest gaat er volgens mij idd niet veel verschil zijn…
De dimmers miss wel, mijn gaan van value 00 to 90…
Waarbij 90 eigenlijk 100% brightness is…
Geen idee waarom ze dat destijds zo gedaan hebben …
Was eens even aan het kijken, jij vraagt per lamp de state op? Hoe zet jij alle States goed bij een HA restart?
Ik stuur altijd 1 specifiek commando bij een HA boot waarbij ik alle states uitleest van alle relays, zo zet ik dan alle states goed voor mijn lampen