Das Ziel des Ganzen

Auch verfügbar in:

English

Nach all dem Hardware-Kleinkram nun ein Exkurs zum Großen Ganzen: wo will ich mit dieser Idee überhaupt hin?

Redundanz. Es sollen möglichst viele Geräte ersetzbar sein, so dass das Ganze auch dann noch funktioniert, wenn eines ausfällt.
Einfache Programmierung. Kleine, auf das Nötigste reduzierte Skripte erledigen genau eine Aufgabe.
Aktive Konfiguration. Das heißt: die Systeme lauschen auf Änderungen der Konfiguration und legen dort ggf. einen Fehlerstatus ab. Es gibt kein "Reload" und keinen zentralen Server.
Das Konfigurationssystem "weiß", welchen Zustand jedes Objekt hat, welchen es haben soll, und wieso. Nirgends anders gibt es aktuelle Zustandsinformationen, d.h. wenn das System komplett neu startet (Stromausfall?), ist danach alles genauso wie vorher.
Backends, die auf ein shared medium zugreifen, sollen sich gegenseitig überwachen und notfalls ersetzen. D.h. Funksysteme haben einen Empfänger, der überwacht, dass tatsächlich gesendet wurde; wenn ein kabelgebundener Adapter nicht mehr funktioniert, so gibt es einen weiteren, der ihn ersetzen kann.
Funksysteme werden nur im äußersten Notfall eingesetzt, weil Batterien wechseln doof ist und weil die Funkerei störanfällig ist.

Und wie will ich das erreichen?

Als Programmiersprache wird durchgängig Python3 verwendet. Nein, kein Java, kein Javascript, und auch kein Go oder Erlang.
Für die statische Kommunikation (d.h. alles, was nach einem Stromausfall genauso wieder da sein soll wie vorher) und für alle Zustandsangaben (Temperatur, …) verwende ich etcd.
Auch Ziele ("das Licht im Flur soll AN sein") und Fehler ("Der fürs Licht zuständige KNX-Aktor reagiert nicht") behandle ich als statische Daten. Sie werden natürlich entfernt, wenn das Ziel erreicht bzw. das Problem behoben ist.
Für die dynamische Kommunikation (RPC, PubSub, …) verwende ich RabbitMQ. Dieser Bus hat den Vorteil, dass er das MQTT-Protokoll unterstützt, d.h. man kann problemlos OpenHAB oder mobile Geräte anbinden.
Für die kleinen peripheren Steueraufgaben verwende ich den 1wire-Bus mit selbstentwickelter Slave-Software ("MoaT").
Für die 230V-Geräte verwende ich KNX.

Nächstes Problem: das Alles braucht Software.

Aufbauend auf AMQP schreibe ich ein kleines aber feines Messaging-System. Das System ist auf Redundanz ausgelegt (d.h. mehrere RPC-Server für dasselbe Objekt kommen sich nicht in die Quere) und insbesondere beobachtbar (Fehlersuche!).
- Die Basis ist fertig.
- Code für RPC oder PubSub ist schnuckelig klein.
- Die Tools fehlen noch.
Aufbauend auf etcd schreibe ich ein kleines Monitoring-System, das mir erlaubt, Ereignisse auf beliebigen Ebenen zu beobachten.
- Der grundlegende Code ist fertig.
- Code für Monitoring von Änderungen ist noch rudimentär und zu komplex.
- Tools: ?
Der etcd-Datenbestand muss geeignet strukturiert werden: * Hardwareebene (der KNX-Bus für Adressen 1/2/* wird über Rechner xyzzy erreicht) * funktionale Ebene (das Licht im Flur wird von einem Bit auf KNX-Adresse 1/2/3 gesteuert) * Status (das Licht im Flur ist an) * Ziel (das Licht im Flur soll aus sein, weil es jetzt Tag ist)

Status: rudimentäre Gedanken.
1wire und die Geräte daran möchten angesprochen werden.
- Im alten MoaT-Pythoncode existiert Code dafür, der viel zu aufwändig und fehleranfällig programmiert ist und recycelt werden mag.
- MoaT-Autodiscovery (Geräte erkennen und in etcd einfüttern) fehlt großteils.
- MoaT-Alarmbehandlung ist rudimentär vorhanden.
dito KNX.
- Die Busanbindung erledigt der knxd. Status: funktioniert einigermaßen.
- Statt Autodiscovery gibt es eine Projektdatei, für die es noch keinen Parser gibt.
Visualisierung: Fehleranzeige, etcd-Strukturbrowser * rudimentäres GTK-Frontend dafür ist vorhanden. * Webfrontend wäre nett.
???
Profit.

Demnächst mehr.