Zur Hardware

Die Software gliedert sich im Prinzip in 3 Teile. Ersten die Software für den Arduino, zweitens die Software für den PI und drittens Home Assistant.

Bei der Entwicklung wurde vorausgesetzt, dass das System in minimaler Umgebung, ohne Internet oder lokalem LAN/WLAN für sich lauffähig und im Prinzip voll Funktionsfähig ist. D.h. auch ohne PI oder PI und Home Assistant voll funktioniert, wenn auch bei höherem Bedienaufwand. Z.B. fahren dann Rolladen nicht mehr automatische, können aber manuell gefahren werden. Da der PI auch das MQTT CAN Interface enthält, ist eine Steuerung via Home Assistant nur bei funktionsfähige PI möglich, was aber nicht unbedingt ein gravierender Nachteil ist, im Gegensatz zum Vorteil, dass alle Basisfunktionen ohne WLAN oder sonstige externe Komponenten auskommen. Anderseits wird der PI über das Netzteil der Steuerung versorgt, so dass er auch immer laufen sollte und somit alle ausschliesslich PI abhängigen Funktionen ebenfalls verfügbar sein sollten.

Um die Pflege des Programmes zu vereinfachen enthält jeder Arduino NANO, d.h. jeder Knoten die gleiche Software. Das bedeutet zwar einen gewißen Overhead , d.h. nicht alle Teile werden benötigt, ist aber beim aktuellen Umfang leicht möglich. Da inzwischen dank der Arbeit von Peter Müller https:crycode.de . ein Bootloader vorhanden ist, kann die Firmware problemlos über den PI via CAN aktualisiert werden, was auch in der Praxis schon mehrfach erfolgreich gemacht wurde. Geplant ist jedenfalls die Software auf allen Knoten solange als möglich identisch zu halten.

Die unterschiedliche Funktion einzelner Knoten wird über eine im EEPROM gespeicherte Konfigurationsdatei gesteuert. Diese ist über den PI via CAN remote sowohl auslesbar als auch zu aktualisieren. Zusätzlich enthält der EEPROM auch eine Node ID (Abweichend vom CAN Protokoll, doch hierzu später) und ebenso eine Gruppen ID. beide können über den PI gesetzt und verändert werden.

Das CAN Protokoll arbeitet mit einer normalen ID 11 Bit bzw. einen extented ID 29 Bit welche ich verwende, zusätzlich gib es noch einen variablen Datenteil von 0 bis 8 Byte. Bei CAN hört jeder Knoten auf die Daten und liest diese mit, soweit im Controller kein Filter gesetzt ist. Ich mache mir diese Eigenschaft zu Nutze indem ich in der ID Konten ID, Gruppe und Teile der Funktion verschlüssele. Weitere Daten werden im Datenteil übertragen. Somit sind neben 1 zu 1 Nachrichten auch Multicast bzw. Broadcast Nachrichten möglich. Erkennt ein Knoten seine ID bzw. sein Gruppe oder Broadcasts wertet er  die restlichen Daten aus dekodierter CAN ID bzw. den Datenteil aus und verarbeitet diese.
Ebenso ist in der CAN ID auch die Absender ID enthalten somit können gezielt Anfragen an Knoten gestellt werden und diese auch gezielt beantwortet werden.

Die weitere im EEPROM gespeicherte Konfiguration enthält Informationen über die Hardware, d.h. z.B. wie viel und welche Taster/Schalter sind eingebaut, wie viel und welche LEDs gibt es, welche sonstige Hardware ist vorhanden, Sensoren, PIRs, RTC, Expander etc. Aber hier ist auch hinterlegt welche Aktion ein betätigter Taster/Schalter an welchem Knoten auslösen soll. D.h. welche Aktion an welchen Knoten als Auftrag gesendet werden soll und ob eine Rückmeldung erwarte wird etc.

Weitere Details zum Messageaufbau

Der Configbereich Beschreibung und Beispiele

Der aktuelle Stand der Software in Produktion. Gesteuert aktuell werden damit Flurlicht von 3 Stellen, Badlicht von einer Stelle, Licht Abstellkammer von einer Stelle , 2 Rollos im Bad, 1 Rollo im Esszimmer.

Läuft stabil, die Vorgänerversion lief seit März 2020 stabil.

Downlooad der PlatformIO Dateien

Ich arbeite eigentlich ausschließlich mit Tastern, da hier mehrere Funktion dargestellt werden können. Das sind Click, doppel Click und langer Click, Optional währe noch während Click möglich. d.h. die Funktion wird nur ausgeführt während der Taster gedrückt ist. Somit sind pro Taster 3 bzw. 4 Funktionen möglich, bei einer Bestückung mit 4 Tastern 2 bzw. 16 Funktionen.

Die LEDs werden als Statusanzeige verwendet. Bei Taster denen ein Leucht zugeordnet ist wird die grüne LED stark gedimmt aktiviert (konfigurierbar sowohl ob als auch Dimmfaktor), damit findet man den Schalter (Taster) auch im Dunkeln, ohne dass es störend wirkt. Ist eine Leute dann ein wir die rote LED  eingeschaltet. Dies geschieht durch ein Rückmeldung (CAN Message) von der Zentrale. Somit ist sicher, dass die Funktion auch ausgeführt ist. Wichtig vor allem wenn Leuchten geschaltet werden die nicht im direkten Sichtbereich sind. Leuten werden in der Regel mit Click und Toggle geschaltet, d.h. Click der aktuelle Zustand wird invertiert, ist die Leuchte aus, wird sie EIN geschaltet, nächster Click schaltet die Leuchte AUS. Das geht als One to One (z.B. eine Schalter eine Leuchte), One to Many (z.B ein Schalter mehrere Leuchten), Many to One (z.B. mehrere Taster eine Leuchte Flurlicht), Many to Many (z.B. mehrere Taster mehrere Leuchten Treppenhauslicht).
Im Falle von Many to One oder Many to Many bekommen, gesteuert über die Source_Group alle Taster LEDs eine Rückmeldung, rote LED geht ein bzw. aus.

Statt Leuchten können natürlich beliebige Geräte  geschaltet werden.

Die Timed Funktion wird im wesentlichen für die Rolladensteuerung verwendet. Die entsprechende Zeit in Sekunden wir im Paket mit übermittelt, das Gerät wird eingeschaltet, es erfolgt eine Rückmeldung rote LED geht an, die Zentrale überwacht die Zeit, d.h. zählt im Sekundentakt herunter und schaltet das Gerät wieder aus und gibt wieder eine Rückmeldung LED geht aus. bei Timed wird die grüne LED bei mir nicht verwendet, d.h. ist in der Regel aus. Aber auch das ist konfigurierbar.