Mikrokontroller-Geräte (Nodes)
Verbindungen
Alle AqHomeControl-Geräte (im folgenden Nodes genannt) werden über einen einfachen 4-adrigen Bus angeschlossen, der folgende Leitungen enthält:
- 5V
- GND
- COM_DATA
- COM_CLOCK
Die ersten beiden Leitungen bieten die Stromversorgung, die letzten beiden dienen der Kommunikation untereinander.
In AqHomeControl-Netzwerken sind alle Geräte gleichberechtigt und können jederzeit senden, wenn der Bus frei ist. Kollisionen führen hier schlimmstenfalls zu Datenfehlern, die aber durch Checksummen erkannt werden.
Damit das funktioniert, dürfen angeschlossene Geräte die Leitungen COM_DATA und COM_CLOCK immer nur in einen von zwei Zuständen versetzen:
- aktiv auf GND ziehen (also Pin als 'OUTPUT' definieren und diesen auf '0' setzen)
- offen lassen (also Pin als 'INPUT' definieren ohne Pull-Up-Widerstand)
Caution
Auf keinen Fall dürfen die COM-Leitungen aktiv HIGH gesetzt werden, denn das führt zu einem Kurzschluß, falls ein anderes Gerät gleichzeitig die Leitung auf GND zieht! Damit es hierbei nicht zu Zerstörungen kommt, werden auf jedem Gerät Widerstände in den Kommunikationsleitungen verwendet, die den Strom begrenzen.
Um definierte Zustände auf den Leitungen auch dann zu haben, wenn alle Geräte auf 'INPUT' stehen, muss es im Netzwerk genau ein Gerät mit Pull-Up-Widerstand geben. In meinen Netzwerken ist das praktischerweise das Gerät, das auch die Stromversorgung (5V, GND) einspeist.
Protokoll
Das Protokoll ist extrem simpel, damit auch das einfachste Gerät damit umgehen kann. Die COM-Leitungen sind normalerweise 'offen', d.h. alle Geräte definieren die entsprechenden Pins als INPUT und die Pullup-Widerstände im Stromversorgungs-Node ziehen diese Pins damit definiert auf HIGH.
Übertragung
Daten werden in Paketen übertragen, die eine Zieladresse, eine Längenangabe, Nutzdaten und eine Checksumme enthalten. Die meisten Pakete enthalten zusätzlich auch die UID und die Adresse des Senders sowie ein Kommandobyte.
Wenn ein Gerät senden möchte, beobachtet es den Bus und wartet, bis die Leitungen 'HIGH' sind. Dann zieht es die COM_CLOCK-Leitung nach GND (also 'LOW') und wartet eine kurze Zeit, damit alle angeschlossenen Geräte Gelegenheit haben, auf diese Änderung zu reagieren und in den Empfangsmodus zu schalten. Dann beginnt die Übertragung. Dabei wird bei jeder steigenden Flanke der COM_CLOCK-Leitung (also von LOW nach HIGH) das auf der COM_DATA-Leitung anliegende Bit gelesen und gespeichert, bis ein Byte übertragen ist.
Im ersten Byte wird die Zieladresse übertragen, so daß sich im Prinzip nicht angesprochene Geräte wieder aus dem Empfangsmodus ausklinken könnten (tatsächlich lesen aber meine eigenen Geräte immer ganze Nachrichten und entscheiden nach korrektem Empfang, ob diese zu verwenden sind).
Im nächsten Byte wird die verbliebene Anzahl an Nutzdaten-Bytes gesendet. Danach folgt die entsprechende Anzahl Bytes.
Im letzten Byte wird eine Checksumme übertragen.
Note
In früheren Versionen habe ich eine Art UART-Protokoll verwendet, weil z.B. der ATtiny841 zwei Hardware-UARTs besitzt. Das hat auch super funktioniert, solange ich nur ATtiny Mikrokontroller im Netz hatte. Als ich aber für die Display-Geräte die ersten ATmegas einsetzen wollte, gab es massive Timing-Probleme.
Das Problem ist, dass ich bei allen Nodes die internen Taktgeber verwende, und deren Frequenz ist in Zusammenarbeit mit anderen Prozessoren mitunter nicht stabil genug. Mit dem neuen Protokoll gibt es da keine Probleme mehr.
Adressierung
Jedes Gerät weist sich beim Start selbst eine freie 8-Bit-Adresse im Bereich 1-251 zu. Andere Adressen sind reserviert. Die spezielle Adresse 255 ("Broadcast") adressiert alle Geräte im Netz. Tatsächlich werden die meisten Nachrichten an Adresse 255 gerichtet und die Geräte entscheiden dann selbst, ob sie damit etwas anstellen wollen.
Note
Das generelle Broadcasten von Sensordaten ins Netz erscheint auf den ersten Blick übertrieben, hat aber 2 große Vorteile:
- Die Nachricht muß nur einmal gesendet werden.
- Der Sender muß nicht wissen, wer sich alles für diese Sensordaten interessiert, sondern nur die Geräte, die Sensordaten aus dem Netzwerk auswerten wollen, müssen entsprechend konfiguriert werden.
Im übrigen sendet jedes Gerät nur in bestimmten, sinnvollen Abständen seine Sensordaten (mit Ausnahme wichtiger Daten, wie z.B. die von Tür- /Fenstersensoren).
Zusätzlich weist sich jedes Gerät beim ersten Starten der Firmware eine zufällige UID zu (64-Bit), diese wird auch beim Flashen neuer Firmware beibehalten.
Pakettypen
Die weitaus häufigsten Pakete enthalten Statusmeldungen angeschlossener Sensoren (Temperatur, Luftfeuchtigkeit etc). Es gibt aber auch statistische Nachrichten der Geräte, z.B. über die Anzahl der empfangenen oder gesendeten Pakete, die Anzahl der Fehler und anderes. Diese werden generell immer an alle Geräte (Adresse 255) gesendet.
Dann gibt es aber auch Pakete, mit denen man bestimmte Werte/Schalter auf den Geräten selbst ändern kann, diese Pakete sind dann direkt an die Adresse des angeforderten Gerätes adressiert und werden im Erfolgsfall auch mit einem direkt an den Sender zurückgesendeten Paket beantwortet.
Als letztes gibt es noch Pakete, mit denen gezielt neue Firmware an Geräte übertragen werden kann, hierbei wird die Adressierung strenger gehandhabt, indem hier auch die oben genannte UID (64-Bit) zur Adressierung herangezogen wird, damit nicht das falsche Gerät geflasht wird.
Mikrokontroller
Einfachstes Beispiel
Im folgenden das Schema der einfachsten sinnvollen Schaltung für einen AtTiny84 in einem AqHomeControl-Netzwerk. Eine solche Schaltung kann sich schon mit einem Netzwerk verbinden und eine LED blinken lassen. Verbunden wird in diesem Beispiel mittels eines Netzwerkkabels. Diese Schaltung verzichtet bewußt auf einen Spannungsstabilisator und verwendet direkt die ca. 5V, die zur Versorgung der Mikrokontroller auf dem Bus geliefert werden.
Tip
Ich verwende in eigenen Schaltungen immer einen 3.3V Stabilisator und arbeite entsprechend mit 3.3V, um immer definierte Verhältnisse vor allem für die Sensoren zu haben (die AtTiny Mikrocontroller selbst arbeiten mit fast allen Spannungen, die man ihnen hinwirft, wenn man unter 5V bleibt, aber die Sensoren sind da meist weniger flexibel).
Tip
Aus den folgenden Gründen verwende ich in eigenen Schaltungen Ethernet-Buchsen und entsprechende Netzwerkkabel:
- weisen die beste Störungssicherheit auch über längere Entfernungen auf
- vorkonfektionierte Netzwerkkabel stehen in allen möglichen Längen zur Verfügung
Caution
Nicht an ein Ethernet-Netzwerk anschließen, angeschlossene Geräte und Netzwerkgeräte können Schaden nehmen!!
Wie man sieht hat man hier bei einem AtTiny 84 sage-und-schreibe noch 8 Leitungen frei für eigene Funktionen! Die kann man z.B. verwenden, um damit Sensoren oder Schalter zu betreiben.
In der Firmware von AqHomeControl gibt es entsprechende Treiber für z.B. gängige Ein-Draht-, Zwei-Draht- und SPI-Busse, über die man z.B. Temperatursensoren und andere auslesen kann oder auch LED-Streifen oder kleine Displays steuern kann.
Was wird benötigt, um ein Netzwerk zu betreiben?
Zum Betrieb eines Netzwerkes benötigt man:
- ein Gerät zur Stromversorgung (belegt die Leitungen 5V und GND)
- optional ein Gerät zum Anschluß eines Computers an das Netz
- Mikrokontroller-Geräte mit Sensoren und Aktoren
- gegebenenfalls Controller-Geräte mit Display und Touch-Screen (falls benötigt)
In meinen eigenen Netzwerken kombiniere ich die Stromversorgung und den Anschluß an einen Computer zusammen in einem einzelnen Gerät. Diese Box enthält dann mehrere Netzwerk-Buchsen zum Anschluß der Mikrokontroller-Geräte, einen USB-Anschluß für einen Computer und einen 5V Stromanschluß für die Stromversorgung (hier kann man dann z.B. USB-Akkus mit Durchladefunktion verwenden, um gegen Stromausfall zu sichern).
Anforderungen an Mikrokontroller-Geräte (Nodes)
- muß als erstes eine im Netz eindeutige UID (64 Bit) generieren
- muß das oben skizzierte einfache Nachrichten-Protokoll implementieren und sich eine Adresse zwischen 1-251 zuweisen
- muß von Zeit zu Zeit ein Discovery-Paket senden, mit dem es sich bemerkbar macht
- kann in beliebigen Abständen Pakete mit gemessenen Sensordaten versenden (dafür gibt es spezielle Nachrichten)
- kann auf eingehende Pakete reagieren (z.B. reagiert bei mir ein LED-Strip-Controller-Node auf Nachrichten eines Bewegunsmelder-Nodes)
Meine Nodes
N28: Türsensor ( Details )
- AVR ATtiny 84
- verwendet einen TCRT1000 Reflexkoppler, um den Zustand einer Tür oder eines Fensters zu ermitteln
- enthält zusätzlich einen SI7021 Sensor für Temperatur und Luftfeuchtigkeit
N29: Klimasensor ( Details )
- AVR ATtiny 84
- enthält einen SI7021 Sensor für Temperatur und Luftfeuchtigkeit
- enthält alternativ dazu einen SGP-30 Sensor für die Überwachung der Luftqualität
- enthält einen Bewegungssensor (AMN31112)
- enthält eine Photodiode zur Helligkeitsmessung
N30: LED-Controller ( Details )
- AVR ATtiny 84
- steuert SK6812 LED-Lichterketten (RGBW)
- enthält zusätzlich einen Temperatursensor vom Typ DS18B20
- kann auf Meldungen von Bewegungsmeldern (z.B. in N29 Nodes) reagieren und dann entsprechend eine Lichterkette schalten ("Treppenhaus-Licht")
C03: Controller mit SPI-Display
- AVR ATmega 644P
- steuert ein 2.8 Zoll Display mit Touch-Screen
- enthält einen Buzzer
- Software:
- Bildschirmschoner, der das Display bei Inaktivität ausschaltet und bei Touch oder Bewegung einschaltet
- Klimaanzeige (CO2, Temperatur, Luftfeuchtigkeit mit Farbhintergrund entsprechend den aktuellen Werten)
- Debug-Anzeige für Netzwerkstatus (empfangene und gesendete Pakete, Fehler)
- Debug-Anzeige für das interne EEPROM