In Arbeit: SmartHome-Zentrale und Communicator

Translate from German into English (some links may be mistranslated, then turn back to the original site): 

Ich muss etwas ausholen. Die Steuerung meiner Jalousienantriebe läuft seit einigen Jahren elektronisch. Sie wurde seinerzeit - der Not gehorchend - schnell aus dem Boden gestampft, weil ich sie nach dem Umbau auf elektrischen Antrieb möglichst schnell in Betrieb nehmen wollte. Ich habe daher zunächst auf eine moderne Steuerung mittels Controllern verzichtet. Die Zeit für solch eine Entwicklung war definitiv nicht vorhanden. Deshalb wurde auf eine "altbackene" Steuerung mittels CMOS-Logik und Transistoren gesetzt. Hier hatte ich bereits davon berichtet. Erst Jahre später kamen weitere Funktionen hinzu.

Geamtüberblick des Racks. Oben links finden sich die Jalousien-Interfaces, die den Fahrstrom schalten, und oben rechts sind die Steckkarten, die die Anschlusskabel der Jalousientaster aufnehmen. Die Logik dahinter ist ebenfalls CMOS (CD40xx). Lediglich 1 später nachgerüstete Einzeltastensteuerungs-Platine verwendet ausschließlich einen kleinen Microcontroller-Chip.

In 2021 habe ich die Steuerung um die Alarmanlage "ALA" ergänzt, die in der mittleren Reihe ihren Platz gefunden hat.
Die alte Jalousien-Zeitschaltuhr in der 3. Reihe unten links kann nun aufs Altenteil.

Direkt rechts neben den beiden Platinen für die Alarmanlage findet sich nun - in 2022 - die neue SmartHome-Zentrale "SYS" ihren Platz: rot umrandet. Das Display rechts wird davon gesteuert. Das schräg nach unten rechts abgehende Kabel führt zum DCF77-Empfänger, der für eine genaue Zeitbasis sorgt.

Impression: ganz früher Testaufbau.

Auf Schaltungseinzelheiten der Zentrale "SYS" will ich hier nicht weiter eingehen. Ebenso wenig auf die Programmierung der Controller. Wie bereits beschrieben, ist das ganze Konstrukt ein Stückwerk, historisch gewachsen, wie man so schön sagt. Und die älteren Teile davon würde ich heute anders realisieren... Besser so: zunächst alles sehr sorgfältig planen und die Steuerung mehr zentralistisch ausführen.

Aber es gilt das Motto: aus dem Vorhandenen das Beste machen. Mit den technisch nicht so tollen Kompromissen muss ich nun leben. Letztendlich funktioniert es trotzdem perfekt! Es liegt nun ein modulares System vor, dass durch "verteilte Intelligenz" hard- und softwaremäßig fast beliebig erweitert werden kann. Und: die wichtigste Funktion (Jalousien manuell steuern) steht auch bei Ausfall aller Erweiterungen uneingeschränkt zur Verfügung!

Test der Platine "SYS". Oben links am Bildrand: der DCF77-Empfänger samt Ferritantenne.

Hier wird das Zusammmenspiel mit der Alarmanlage "ALA" getestet.

Die SmartHomeZentrale "SYS"

In der Zentrale - hier das Schaltbild - kommt ein ATMEL-AVR-Controller MEGA644PA zum Einsatz. Die Buchstaben am Ende unterscheiden ihn von seinen sonst gleichlautenden Artgenossen: er hat abweichend 2 UARTs an Bord. Also 2 serielle Schnittstellen. Beide werden zwingend benötigt. Über den 1. Kanal wird die Kommunikation mit dem weiter unten beschriebenen SmartHome-Communicator "COM" durchgeführt. Über den 2. Kanal wird der interne Kommunikationsring ("Token-Ring") betrieben. Alle aktuellen und alle später noch dazu kommenden Komponenten (Einschubplatinen mit rückseitiger VG-Buchse) kommunizieren miteinander darüber. Nach dem Prinzip: jeder kann mit jedem sprechen. In alle Richtungen und auch nach Außen - über Kanal 1 - zum Communicator. Und von dort ins Web...

In der Zentrale laufen die essentiellen - unbedingt notwendigen - Funktionen: sehr genaue Uhrenfunktionen, Berechnung der Zeiten für das Auf- und Abwärtsfahren der Jalousien (dämmerungsabhängig), Anbindung an den Communicator "COM", Lauschen auf dem Antriebsbus (zur Ermittlung der Jalousienzustände, weil die manuelle Jalousien-Tastensteuerung weiterhin rein über Hardware gesteuert wird), Steuerung der LCD-Anzeige, Routing der Nachrichtentypen von außen und auf dem "Token-Ring" sowie die Überwachung deren Korrektheit. Und Funktionen, die ich heute noch nicht kenne... Für diese Funktionen muss der Communicator "COM" nicht verbunden sein!

Übersicht der Funtionen auf der LCD-Anzeige

1. Seite: Aktuelles Datum, aktuelle Uhrzeit. Kennzeichen "Syn", ob die interne Uhr mit dem DCF77-Signal synchronisiert ist.

2. Seite: die Jalousien-Positionen der 8 Kanäle. "0" ist ganz unten, eine positive Zahl heißt: es wurde eine Laufzeit in 1/10 Sekunden gemessen, bzw. gesteuert.

3. Seite: ein "X" signalisiert, dass diese Jalousie automatisch auf- bzw. abwärts gesteuert wird.

4. Seite: Anzeige der 1x täglich neu berechneten Auf- bzw. Abwärtszeiten. Löschen des DCF77-Synchron-Kennzeichen durch Drücken der Taste (oben auf der "SYS"-Platine).

5. Seite: Laufzeit der "SYS" seit dem letzten Reset / Hochfahren.

6. Seite: Bei Drücken der Taste für 3 Sekunden fordert die "SYS" die Alarmanlage "ALA" auf, den aktuellen Status zu senden. Letzterer wird dann empfangen und angezeigt.

7. Seite: der letzte Alarm wurde durch den Bewegungsmelder im Wohnzimmer ausgelöst.

8. Seite: Anzeige der Software-Stände aller am "Token-Ring" angeschlossener Komponenten (z.Zt. nur 2).

Dieters SmartHome-Communicator "COM"

Der Communicator ist zweierlei:

• das Konfigurationstool für die Zentrale "SYS". Damit werden die benötigten Parameter gepflegt und zur "SYS" gesendet. Um sie dort im Flash-ROM des Controllers zu speichern.
• das, was der Name sagt. Der Kommunikator. Mit seiner Hilfe werden Meldungen der "SYS", der "ALA" und später aller weiterer Module an die "COM" angezeigt und protokolliert - und ggf. werden von der Zentrale weitere Aktionen getriggert. Weiterhin kann man über Konsolenkommandos mit der "SYS" sprechen.

Das Programm läuft aktuell auf einem PC, der mittels seriellem Kanal (COM-Port) mit der Zentrale verbunden ist. Es ist in Lazarus programmiert. Ich hatte über Lazarus bereits hier berichtet.

Das Schöne an Lazarus ist, dass es ein plattformübergreifendes Entwicklungstool ist. Slogan: "Write once, compile anywhere". Also: einmal den Code schreiben und dann sowohl auf Windows als auch auf Linux zum Laufen bringen! Das funktioniert tatsächlich (s.u.)!

Mittelfristig soll der PC durch einen Einplatinencomputer RaspBerry Pi (mit dem Betriebssystem Linux) ersetzt werden. Letzterer wird dann in das Rack eingebaut.

Ein Klick auf das Bild vergrößert - dann zurück

Das Programm hat eine linke (Konfigurations-) und eine rechte (Kommunikations-) Seite.

Zunächst die linke Seite: im Tab "GEO" werden die Daten für Sonnenauf- und Untergang verwaltet. Die Tabelle habe ich in Excel berechnet und der Communicator importiert bei Programmstart die zugehörige CSV-Datei. Änderungen der Auf- und Abwärtszeiten sind aber auch hier möglich. Die Tabelle enthält 14-tägige Stützwerte. Dazwischen wird linear interpoliert. Die Genauigkeit ist ausreichend. Aktuell sind die Zeiten so berechnet: Aufwärtsfahrt bei Sonnenaufgang minus halbe Bürgerliche Dämmerung. Abwärtszeit bei Sonnenuntergang plus volle Bürgerliche Dämmerung. Diese Zeiten können gespeichert und zum Controller gesendet werden. Die Buttons "V" stehen für Verify, also für den Vergleich zwischen Controller und Communicator. Bei Differenz wird das Ergebnis rechts rot ins Protokoll geschrieben.

Die rechte Seite enthält Kommunikationsdaten. Im Tab "Ereignisse" werden relevante Ereignisse farbig dokumentiert. Ein Alarmanlagen-Alarm wird dort einen roten Eintrag erzeugen, das Ergebis der Zeitberechnungen wird in blau angezeigt.

Weiter geht es links mit den Konfigurationsdialogen. Im Tab "JA1" werden die gewünschten Jalousienaktionen für den Zeitpunkt Auf bzw. Ab beschrieben. Abschließend: Speichern, zum Controller schicken, Verify.

Der Dialog im Tab "JA2" erfasst die - mit Stoppuhr gemessenen - Laufzeiten der Antriebe. Für Auf und Ab, ebenso für die Lückenfahrt (Jalousie geht auf Lücke, liegt unten gerade noch auf).
Und das obligatorische Speichern, zum Controller senden, Verify..

Tab "Jobs1" erfasst KEINE Controller-Konfigurationsdaten. Die hier beschriebenen zeitgesteuerten Aktionen laufen nicht in der "SYS" sondern nur im Communicator. Es sind eher Luxus- und nicht essentielle Funktionen.

Auch die Daten der Tab "Jobs2" laufen vom Communicator getriggert ab. Abhängig von Sonnenauf- / Untergang, bzw. zu den berechneten Jalousienlaufzeitpunkten.

Bei Bedarf werden einfach neue Dialoge und Funktionen hinzu programmiert!

Zurück zur rechten Seite des Programms: Thema Kommunikation.

Die "Konsole" ist genau das: hier können Kommandos eingetippt und in Richtung "SYS" gesendet werden. Dort werden sie ggf. weitergeleitet. Antworten zurück werden angezeigt.

In der Box unten können Blockkommandos erfasst und gemeinsam gesendet werden. Zum Beispiel zur Abfrage der Stati bei Programmstart - auch automatisch.

Tab "Doku": damit man nicht immer und auch noch nach Jahren nicht alles auswendig wissen muss, gibt es hier als Hilfe die Online-Dokumentation

Hier ist auch die jetzige und künftige Topografie aufgezeigt. Ziemlich in der Mitte ist die Zentrale "SYS", nach rechts die Anbindung zum Communicator "COM", später weiter in die eigene Cloud. In Hin- und Rückrichtung.
Links geht es über den "Token-Ring" zu den Komponenten. Zur Zeit ist das lediglich die Alarmanlage "ALA".
In der Pipeline für die nächste Zeit stehen ein TCP-Modul und ein Funksteckdosenmodul ("FSD"). "DEV" ist nur ein Testdevice.
Dann habe ich so einen schönen Helligkeitssensor an einem Fenster hängen; damit ließe sich doch bestimmt auch was machen. Und eine Heizungs-Fernüberwachung, oder: eine Kopplung mit dem Stromzähler. Und...

Man kann schön die Ringstruktur erkennen: da sind jeweils der Ausgang des ersten mit dem Eingang des zweiten Moduls verbunden. und so fort. Und zurück zur "SYS".
Jedes Modul prüft beim Empfang eines Nachrichtenblocks, ob es selber zuständig ist. Wenn nicht, wird weitergeleitet, ansonsten wird nur die Antwort zum nächtsten Modul gesendet. Bis es beim gewünschten Empfänger ankommt. Das kann z.B. "WEB", sein, weil ich über die Cloud ein Kommando gesendet habe...

Tab "Notizen": selbstredend.

Tab "Verbindung": Über welchen Kanal kommunizieren die "SYS" und der "COM"? Möglich sind ein serieller Port (oder ein virtueller COM-Port eines eingesteckten USB-Seriell-Adapters) und eine TCP-Verbindung.

Tab "Cloud": nur ein schneller Entwurf. Wahrscheinlich wird die Realisierung später stark anders aussehen. Ich möchte nicht so sehr auf das http-Protokoll setzen. Da ist eher das Web-Socket-Protokoll besser geeignet. Wer weiß?

Alle Dialoge sind noch experimentell! Es wird sich zeigen, ob ein Lösungsansatz so passt, oder ob es bessere Antworten gibt. Da habe ich schon so Manches verworfen und neu gemacht, weil der Praxiseinsatz zeigte, dass der erste Gedankenblitz nicht der Beste war...

Ein Raspi-Test

Mein neuer Raspi: ein Tastaturgehäuse samt eingebautem Linux-Rechner (Raspberry Pi 400). Damit will ich mich zunächst mit diesen Dingern vertraut machen.
Das Wissen benötige ich, will ich später einen Einplatinencomputer RaspBerry Pi 4B mit dem SmartHome koppeln. Der abgebildete Pi 400 ist leider aktuell (Ende 2022) der einzige Raspi, der zu nicht völlig überzogenen Preisen lieferbar ist...

Ein erster Kommunikationstest: im Hintergrund der Raspi-Desktop per VNC-Fernsteuerung. Links mit geöffnetem Chat-Testprogramm. Im Vordergrund rechts das Windows-Testprogramm. Derselbe Quelltext, einmal mit Lazarus auf dem kleinen Linux-Rechner und einmal mit Lazarus auf Windows compiliert. Die Daten kommen ggf. ge"chunked" an. Das ist kein Problem, da später alles zusammengehängt wird. Chunks kennt man auch von diversen Internetprotokollen.

Web-Integration

Inzwischen habe ich mich mit der "Verheiratung" aller Komponenten mit dem WWW beschäftigt. Und es gibt einen ersten Design-Entwurf für das Web-Interface "WEB":

Sieht ganz nett aus: abgerundete "Ecken", pastellfarbene Hintergründe, Schatten, ...

Das Webdesign sieht natürlich eine responsive Darstellung vor: auch auf Tablets und SmartPhones soll das Interface vernünftig bedien- und anzeigbar sein!

Die IT-Umsetzung sieht einerseits PHP für die serverseitige Unterstützung vor. Damit wird die Verbindung zum SmartHome-Communicator hergestellt. Andererseits werden die Bildschirminhalte per AJAX - also mittels JavaScript clientseitig - aktualisiert. Alles in allem nicht mehr ganz trivial. Und alles soll in Echtzeit und schnell kommunizieren!

Web-Kommunikations-Test

Etwas später: Und schon gibt es einen Kommunikationsprototypen!

Das Beispiel links zeigt das Ergebnis einer Anfrage vom Tablet: Von der HTML-Webseite geht es per AJAX zu einem PHP-Script. Dieses triggert die Verbindung zum Communicator, der sich wiederum um das Routing der Nachricht zum Ziel und zurück kümmert. Javascript zeigt schließlich das Ergebnis im Browser an. Das funktioniert weltweit - dank der eigenen Cloudservices auf diesem meinem Webspace.

Bis es soweit war, musste ich mit 4 verschiedenen Programmiersprachen (2 für die Webanbindung, 1 für den Communicator, 1 für die Microcontroller im SmartHome) zahlreiche Module erstellen. Puh! Aber als Rentner hat man ja sonst nichts zu tun...

Ein erstes funktionierendes Webinterface wurde fertiggestellt. Zunächst mit minimalen Basisfunktionen. Das hat ganz schön Mühe gekostet. Die Tücken des Objektes stecken wie so oft in den Details (z.B "CORS-Fehler" oder "gemischte Inhalte").
Und da ich nicht der Profi-Webentwickler bin, muss ich mir so manche Technik erst erarbeiten. Das kostet Zeit...

Später wird das Interface um weitere Funktionen entsprechend ergänzt werden. Neben den für irgendwann angedachten Hardware-Erweiterungen einschl. derer Web-Funktionen ist es denkbar, die Konfiguration des Communicators COM aus der Ferne zu ermöglichen. Auch die EEPROMs der Zentrale SYS ließen sich ferngesteuert umprogrammieren. Dazu müsste ein korrekter und in diesem Falle etwas längerer Kommando-String gesendet werden. Und der Communicator müsste diese Aktion erlauben und weiterleiten an die Zentrale. Ebenso ließe(!) sich die Alarmanlage aus der Ferne ein- und ausschalten. Sicherheitsaspekte sind gegen Komfortmerkmale abzuwägen...

Web-Fernkonfiguration

Es geht weiter: Bei den Jobs 1 und 2 handelt es sich um die Tasks, die ich bereits hier und hier als Funktion der COM weiter oben beschrieben habe. Diese sind nun über das Webinterface fernkonfigurierbar.

Um das SmartHome tatsächlich smart zu machen, müssen intelligente Funktionen eingebaut werden. Einen ersten Schritt dazu habe ich begonnen: mein Communicator "COM" beherrscht nun "Ereignisse" und "Zustände". Ereignisse sind plötzliche und kurzzeitige Situationen. Im Gegensatz dazu sind Zustände meist das Ergebnis von Ereignissen und halten länger an. Dazu gibt es im Communicator nun einen neuen Dialog: "Jobs3". Dieser Dialog ist natürlich auch im Web-Client verfügbar.

Links im Bild sind nun Ereignisse (neudeutch: Events) und Zustände (States) verknüpfbar. Für beides gibt es Auswahlboxen zum Anklicken. Da gibt es in der ersten Zeile das ausgewählte Ereignis "JALAB+1" sowie daneben den Zustand "ALAON". Beide sind mit logisch UND = "AND" verknüpft. Führt diese Verknüpfung zu einem wahren Ergebnis, so wird der Kommandostring in der Zeile darunter ausgeführt - wenn das Häkchen ganz rechts es erlaubt.

Also im Klartext: wenn nach dem Zeitpunkt "Autom. Herunterfahren der Jalousien" 1 Minute vergangen ist (dann sind sie sicher unten) UND die Alarmanlage ist eingeschaltet (dann ist niemand zuhause), so wird das Kommando zum Löschen des Lichts (Anwesenheit während der Dämmerung vortäuschen) an die entsprechenden Funksteckdosen ("FSD") gesendet.
Oder es wird bei "ALARM" bei eingeschalteter Alarmanlage (nicht im Lüftungsmodus!, siehe hier) eine eMail versendet.

Die nächste Hardware-Erweiterung

Aktuell die letzte Erweiterung: die manuelle Steuerung der Funksteckdosen ("FSD"). Der WEB-Client kann es, der Communicator kann es. Fehlt nur noch das Stück Hardware, das innerhalb meines SH-Racks diese Funktion realisiert.

Rechts im Bild gibt es die ersten Überlegungen dazu: man nehme ein preiswert erwerbbares Funksteckdosen-Set samt Handsender. Ein kleiner Controller simuliert die Tastendrücke und fügt sich über den seriellen Bus perfekt in das Gesamtsystem ein.
Und da am Ende noch Pins am Controller frei sind, könnte dieses Modul weitere Funktionen übernehmen. Z.B. das Ansteuern eines "1-wire-bus" für das Auslesen mehrerer Temperatursensoren. Oder das Überwachen eines Wasserstandssensors. Und da ist ja noch der Sonnensensor, der auf eine Anwendung wartet...

Etwas später: der Aufbau ist fertig, programmiert und getestet. Nur der Einbau fehlt noch.

Links sieht man die VG-Steckerleiste. Im unteren Teil daneben wurde der Controller (ATMega8) mit den wenigen nötigen Bauteilen platziert. Die 10-polige Buchse ist der ISP-Anschluss zum Programmieren des Chips. Oben in Grün ist die Platine des Handsenders erkennbar.
Es ist noch reichlich Platz für Erweiterungen vorhanden. Auch der Controller hat noch reichlich Reserven dafür.

Die Reihe Transistoren ganz unten ist für die Simulation der Tastendrücke zuständig. Und man sieht die Verkabelung mit dünnem Kupferlackdraht.

Die Integration der FSD

Das neue Modul habe ich nun ins Rack eingebaut und in Betrieb genommen. Die Software der "SYS" ist um dieses Modul erweitert. So zeigt die LCD-Anzeige nun auch noch den aktuellen Status der Funksteckdosen an.

Die Anzeige der Software-Stände aller im System angeschlossener Module ist um die "FSD" erweitert. Da ich gerade dabei war, habe ich auch noch einen Schönheitsfehler in der "ALA" beseitigt. Der Stand aller Module ist gerade identisch. Das wird wohl nicht lange so bleiben!

Links ist beispielhaft ein Auszug aus dem Systemprotokoll zu sehen.
Um 17:54 Uhr war Sonnenuntergang. Die Logik von "Jobs2" des Communicators hat ein Ereignis ausgelöst: "FSD" Kanal 1 wird eingeschaltet ("SWI"). Die 1. Zeile in grün. Die "FSD" antwortet prompt und meldet die Ausführung an die "COM". Der Status ist "1" = "00000001": 2. Zeile in violett. Die indirekte Beleuchtung in der Wohnung ist damit eingeschaltet.

Um 18:28 fährt die "SYS" die Jalousien herunter: doAutoAb() am Ende der "Bürgerlichen Dämmerung". Dies ist in der "SYS" so konfiguriert. Die Ausführung wird 22 Sekunden später an die "COM" gemeldet (4. Zeile).

Um 20:24:19 wird die Alarmanlage scharf geschaltet. Dies wird von "ALA" in Zeile 5 gemeldet. Und sofort wird in der "COM" ein Ereignis aus "Jobs3" erzeugt. Der zugehörige Steuerstring veranlasst die "FSD", ihren Kanal "1" abzuschalten. Die Ausführung wird in der letzten Zeile von "FSD" an "COM" gemeldet. Da die Wohnung verlassen wird und die Jalousien bereits heruntergefahren sind, wird die Beleuchtung ausgeschaltet.

Alle Meldungen der Module an die "COM" werden gespeichert, so dass diese Daten sofort zur Verfügung stehen, wenn sie vom WEB-Client bei der "COM" abgefragt werden. Die Abfragen erfolgen je nach Dringlichkeit in unterschiedlichen Zeitabständen.

Die FSD-Platine hat ihren Platz im Rack meines SmartHomes gefunden.
Direkt rechts daneben steckt eine "Brückenplatine" (RX-TX-Leitungen verbunden) als Platzhalter für die Platine des nächsten Projektes. So langsam füllen sich die Reihen...

"Spielwiese"

Zum Anschauen und Spielen gibt es das Web-Grundgerüst. Man beachte die anklickbaren Infos ganz am Ende. Und funktioniert der "Alarm-Test"? Ggf. müssen Sie Ihrem Browser erst erlauben, den Sirenensound abspielen zu dürfen!
Hinweis: inzwischen ist das Web-Interface einem kleinen Re-Design "zum Opfer gefallen". Ich habe die Oberfläche etwas übersichtlicher gemacht. Die Spielwiese ist noch nicht angepasst.
Hinweis 2: Der Javascript-Anteil in dieser Demo geht gegen Null. Im Original-Webinterface nimmt allein der Javascript-Teil knapp 1000 Zeilen ein. Da kommt ganz schön 'was zusammen...

Wird später fortgesetzt!

     Kommentieren Sie hier!