MySensors Starter Guide
Einführung
MySensors ist ein open-Source-Projekt. Der Schwerpunkt liegt auf selbstgemachten Funk-Sensoren für die Hausautomatisierung und das "Internet der Dinge" in einer Art Baukastensystem. Die Bauanleitungen des Projekts für die einzelnen Musterbausteine sind in der Regel einfach nachzubauen, die Hard- und Softwarebauteile lassen sich dabei auch (fast beliebig) kombinieren.
Nodes und Children
Nodes
Die Kombination von einem Microcontroller und einem Funkchip wird jeweils als "Node" bezeichnet. Ein MySensors-Netzwerk besteht also (in der Regel) aus mindestens zwei Nodes, nämlich einer Gateway-Node und einer oder mehreren Sensor-Node(s). Jede Node ist durch eine sog. NodeID innerhalb des Netzwerks eindeutig identifizierbar, wobei die "0" jeweils für das Gateway reserviert ist[1]. Als Microcontroller werden in der Regel Arduinos (Nano oder Micro) verwendet, für das GW häufiger auch ESP8266. Als Funkchips lassen sich derzeit Module mit nRF24L01+ und RFM69 bzw. RFM95 verwenden, die allerdings jeweils eine eigene Funktechnik verwendet und daher innerhalb eines Netzwerks nicht gemischt werden können. Es kann auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufgebaut werden; hierfür werden 2 Adern als Datenleitung benötigt.
Children
Als Child wird alles bezeichnet, was jeweils innerhalb einer Node unterschieden werden soll. Beispiel: An einer Node wird ein BME280 angeschlossen. Dies ist ein I2C-Sensor, der drei Werte liefert, nämlich Temperatur, Luftfeuchtigkeit und Luftdruck. Jeder dieser Meßgrößen erhält üblicherweise eine eigene ChildID zugewiesen.
Softwarestand
Bei der letzten Aktualisierung dieses Artikels war
- 1.8.5 der Stand der verwendeten Arduino-IDE
- 2.2.0 die stable-Version von MySensors.
- 2.3.0-alpha der aktuelle Development-Zweig von Mysensors
Vor- und Nachteile von MySensors
Vorteile
- Preisgünstig
- Modular, Elemente können (fast) beliebig kombiniert werden
- Es kann ein sog. ACK verlangt werden. Damit läßt sich sicherstellen, dass eine Node einen Befehl auch tatsächlich erhalten hat (Bidirektionalität).
- Auf den Microcontrollern kann eine eigene Funktionalität unabhängig von der zentralen FHEM-Instanz vorgesehen werden (z.B. LED-Licht direkt bei Bewegung schalten). Die Nodes können seit 2.0.1-beta dabei auch ohne Verbindung zum Gateway die loop() ausführen, wenn eine entsprechende Option aktiviert ist.
- MQTT kann unterstützt werden.
- Es kann auch eine kabelgebundene Infrastruktur aufgebaut werden (RS485, zwei Adern).
Nachteile
- Standardmäßig wird ein nicht verschüsselter Funkstandard verwendet, so dass von der Verwendung in sicherheitsrelevanten Funktionen (Türschließer usw.) abzuraten ist.
Zum Start
Für erste Tests sind sinnvoll:
- ein Arduino mit USB-Anschluß (Nano) oder ein ESP8266[2]
- ein weiterer Arduino Nano
- zwei nRF24L01+ (alternativ: zwei RFM69)
- Die Arduino-IDE
- die gewünschte Sensorik, also z.B. einen DS18B20+Widerstand, ein Bewegungsmelder-Modul, ... siehe dazu die Build-Anleitungen bei MySensors.org, wo auch Bezugsquellen zu finden sind.
MySensors in FHEM
Allgemein
Die Nutzung von MySensors in FHEM ist (nicht nur für den Anfänger) mit der standardmäßig eingeschalteten autocreate-Funktion einfach umsetzbar. Die Kenntnis der FHEM-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere sind Quick-Start und Heimautomatisierung mit FHEM Pflicht! Dort werden wesentliche Punkte für ein Verständnis von FHEM vermittelt, auch wenn manches nicht mehr ganz aktuell ist. So sollte man z.B. ein direktes Editieren der fhem.cfg unterlassen.
Im Folgenden werden immer wieder Auszüge aus der Konfiguration dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der Konfiguration sollte - zur Verhinderung von Fehlern - nach Möglichkeit immer über das "Befehl-Eingabefeld" und die "Objektdetails" erfolgen.
Vorbereitung: Gateway
Zunächst ist das I/O-Device zu definieren, also das Gateway. Dies ist in MYSENSORS beschrieben.
Serielles Gateway am Raspberry PI:
define MyGateway_0 MYSENSORS /dev/ttyUSB0@115200
Nach erfolgreicher Definition ist das Gateway im Raum "Everything" in der Gruppe "MYSENSORS" zu finden. Wenn unten "initialized" oder "opened" angezeigt wird, ist FHEM in der Lage, mit dem MySensors-Netz zu kommunizieren. Es sollte dann noch auf autocreate gestellt werden.
Das Gateway ist auch ein MySensors-Device
Da am Gateway gleichzeitig auch bereits Sensoren angeschlossen sein können, legt FHEM direkt auch ein erstes MYSENSORS_DEVICE mit der NodeID "0" an. Sollten bereits ChildIDs im presentation()-Abschnitt des Gateway-Sketches enthalten gewesen sein, werden auch die zum Typ des präsentierten Sensor-Child-Typs passenden Readings automatisch angelegt.
Das erste Funk-MySensors-Device
In der Regel ist aber das erste "echte" MySensors-Device die 2. Node, die neben dem Gateway in Betrieb genommen wird. Hier gilt das Vorgesagte entsprechend: Nach dem ersten Start sind neu erkannte Devices ebenfalls im Raum "Everything" in der Gruppe "MYSENSORS" zu finden, die readings werden automatisch angelegt. Sobald Meßwerte übermittelt werden, werden die Readings damit gefüllt und entsprechend der per Sketch programmierten Vorgaben aktualisiert.
Details der Wechselwirkung zwischen FHEM und MySensors
Vergabe der NodeID
Die Vergabe der NodeID kann entweder im einzelnen Sketch erfolgen oder automatisiert. Dabei vergibt FHEM in der Regel fortlaufend Nummern ab 100. Die erste Node mit automatischer Nummernvergabe ist daher in der Regel das Device MYSENSORS_100.
Fehlende Sensor-Typen und Readings
Für Anfänger ist zu empfehlen, nur Typen und Variablen zu nutzen, die in der 10_MYSENSORS_DEVICE.pm auch hinterlegt sind. Die Angaben dort zu "receives" und "sends" sind aus der Sicht der Node gemeint. Gibt es einzelne Sensor-Typen oder Readings (noch) nicht, gibt es folgende Möglichkeiten:
- Noch nicht vorhandene Typen kann man umgehen, indem man vergleichbare andere nimmt, also z.B. Wasser- statt Gaszähler (Stand: 11/2015)
- Fehlende Readings können auch
- in die 10_MYSENSORS_DEVICE.pm manuell eingepflegt werden, das automatische Anlegen geht dann aber ggf. bei einem Update wieder verloren
- manuell, z.B.
attr MYSENSOR_99 mapReading_ir_send3 3 ir_send
Ist das Reading einmal angelegt, wird es auch automatisch befüllt, sobald die Node einen entsprechenden Wert sendet.
Austausch von Variablen oder Texten
Es ist möglich, Informationen auch bidirektional zwischen FHEM und den Nodes auszutauschen. Dies ermöglicht z.B. die Ansteuerung von Displays oder die Konfiguration von FHEM aus. Hierzu ist es am einfachsten, ein oder mehrere S_CUSTOM-Child zu präsentieren, die jeweils bis zu 5 Variablen ermöglichen. Die Zuordnung innerhalb der Node zu internen Variablen erfolgt dann über die Auswertung der Messages entsprechend der ChildID und der Variablennummer.
alive, NACK und dead
Mit Hilfe der Attribute timeoutAck bzw. timeoutAlive am MYSENSORS_DEVICE kann eingestellt werden, ob bzw. nach welcher Zeit eine Node den Status NACK bzw. dead erhalten soll. Beide Attribute funktionieren unabhängig voneinander, wobei timeoutAck nur verwendet werden sollte, wenn auch Ack's von der jeweiligen Node angefordert werden. Damit kann man z.B. Probleme bei der Funkverbindung leichter erkennen oder eine einfache Art der Batterieüberwachung realisieren.
Hier ein Beispiel mit Hilfe einer ReadingsGroup:
defmod rg_battery readingsGroup TYPE=MYSENSORS_DEVICE:state .*:battery attr rg_battery alias Batteriestatus attr rg_battery room Z_Batterie attr rg_battery valueIcon {'state.alive' => 'batterie', 'state.dead' => 'batterie@red', 'battery.ok' => 'batterie', 'battery.low' => 'batterie@red'}
Beispiel einer ReadingsGroup, die nur Nodes an einem bestimmten Gateway überwacht und Geräte nur dann anzeigt, wenn derzeit Kommunikationsprobleme vorliegen[3]:
define Status_RS485 readingsGroup <Gerät>,<Status> TYPE=MYSENSORS_DEVICE:FILTER=IODev=MySensorsRS485GW:state attr Status_RS485 group Technik attr Status_RS485 mapping %ALIAS attr Status_RS485 noheading 1 attr Status_RS485 room Startseite attr Status_RS485 valueFormat {$VALUE !~ m/alive/?$VALUE:undef;;} attr Status_RS485 valueIcon {'state.dead' => 'lan_rs485@orange','state.NACK' => 'lan_rs485@red' }
Benachrichtigung mittels eines Notify:
defmod n_state_chk notify .*:dead|.*:[Bb]attery:.* { if($EVENT !~ m/ok/ ) { { fhem ("msg FHEM Batteriewarnung, $NAME: $EVENT:\nBatterien sollten demnächst gewechselt werden!");; Log 3, "$NAME: Batteriewarnung $EVENT";; \ } } } attr n_state_chk room Z_Batterie
Mehrere Gateways
Es können auch mehrere MySensors-Gateways verwendet werden. Dabei sind jedoch folgende Einschränkungen zu beachten:
- Das jeweils zugehörige MYSENSORS-DEVICE Node_0 wird für jedes Gateway angelegt, was zur Folge hat, dass die jeweiligen Attribute und Readings in ein einziges Device gemappt werden. Dies hat zur Folge, dass
- lediglich eines dieser Devices als Empfänger von Nachrichten fungieren kann (z.B. zum Betrieb eines Displays)
- bei unterschiedlichen Software-Ständen der Gateways immer die Info erfolgt, dass Änderungen an der Konfiguration vorliegen ("Rotes Fragezeichen").
- Durch das intern genutzte Modul IODev werden mit autocreate eingebundene Nodes zunächst immer dem zuletzt angelegten Gateway als IODev zugewiesen. Dies kann jedoch manuell geändert werden. Nach der Zuweisung eines anderen IODev sollte die betreffende Node neu gestartet werden.
OTA
MySensors unterstützt für NRF-Chips zwar grundsätzlich OTA-updates, man muß dafür aber vorübergehend einen anderen Controller als FHEM einsetzen[4]. Ein Howto ist in diesem Forenbeitrag zu finden. Der dort verwendete Bootloader erwartet OTA-Updates fest auf Channel 76.
Links, Tricks, Kniffe und Erfahrungen
Interessante Links
Offizielles Debugging-Schema
Debug über Konsole (z.B. Putty)
- Über Picocom könnt ihr einfach das Gateway debuggen. Dazu in FHEM entsprechend das Device abschalten und Picocom auf der Konsole aufrufen. Damit alles schön angezeigt wird hilft das imap wie unten gezeigt. Bitte passt das Device /dev/ttyUSB0 auf euer Gateway an.
picocom /dev/ttyUSB0 -b115200 --imap lfcrlf
Vorgehensweise zur Kombination von mehreren Sketchen/Sensoren an einer Node
Mehrere Sensoren (Children) kann man recht einfach an einen einzigen Arduino anschließen und ist dabei nur durch die Größe des Speichers begrenzt. Die Vorgehensweise erläutert dieses Beispiel .
Verschlüsselung und Signierung
EEPROM
Die Nodes speichern einen Teil ihrer Einstellungen im sog. EEPROM. Dazu gehören z.B. die NodeID, der letzte bekannte "nächste" Punkt im Netzwert (RepeaterID) oder der Zustand von Relais. In der Regel ist nur die NodeID problematisch und kann beim flashen per Sketch auf einen anderen als den bisherigen Wert gestellt werden. Wer dennoch das EEPROM löschen möchte, muß den MySensor-Lösch-Sketch nehmen, der nicht "0000..." ins EEPROM schreibt wie der Arduino-Standard-Lösch-Sketch, sondern "FFFF...".
Funk-Themen (NRF-Chips)
Viele berichtete Probleme bei der Einrichtung von MySensors-Netzwerken haben ihren Ursprung in einer unzureichenden Funkverbindung.
Abhilfemaßnahmen
- Einen bzw. mehrere Kondensatoren einlöten. Es sind auch fertige Module erhältlich, die diese Bauteile und einen Spannungsregler bereits enthalten, auf die der NRF mit einem Stecksockel aufgesteckt wird.
- Einen anderen Kanal wählen; die verwendeten Frequenzen liegen im b/g-WLAN-Bereich, so dass wechselseitige Störungen möglich sind. In Deutschland sind die Kanäle bis 84 erlaubt.
- NRF tauschen (Fake NRF-Chips sind zwar verwendbar, haben aber eine deutlich reduzierte Funkreichweite)
- Ein allgemeiner Guide zur Verwendung der nrf24l01+-Module ist hier zu finden.
- Für das Gateway empfielt es sich, ein Modul mit externer Antenne zu verwenden (NRF24L01+PA+LNA Antenna version).
- Einstellen des richtigen PA_LEVEL_...s: Insbesondere der Standardsketch für das serielle Gateway definiert diesen als LOW, was korrekt ist, wenn der interne Spannungsregler des Arduino verwendet ist. Besser ist es, die benötigten 3,3V mittels eines seperaten Spannungsreglers zu erzeugen und dann den PA_LEVEL_MAX einzustellen.
- Funkstrecken lassen sich recht unkompliziert mit Repeatern überbrücken. Dieser muß nicht zwingend eine eigene Node sein. Jede (sinnvollerweise nicht Batterie-gespeiste) Node kann per
#define MY_REPEATER_FEATURE
zum Repeater gemacht werden. - Sonstige Vorschläge ohne Erfolgsgarantie, aber mit Unterhaltungswert:
Buffer-Management
Die NRF-Chips haben nur einen begrenzten Speicher, um Nachrichten zu puffern. Dieser kann überlaufen, wenn in kurzer Folge Informationen versendet werden, z.B. mehr als 5 Temperaturwerte von 1-Wire-Sensoren. Diese Problematik verschärft sich bei der Verwendung von Message-Signing, weil dort die volle payload-Bandbreite für einzelne Nachrichten genutzt wird. Für Abhilfe sorgen kurze Pausen zwischen den einzelnen Sendungen, z.B. wait(30);
.
Tips und Tricks zu MySensors-RS485
Stand: 06/2018, Version 2.3.0-alpha Seit 2.0.1 ist es möglich, statt der Funkmodule auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufzubauen; hierfür werden 2 Adern als Datenleitung benötigt, die Zahl der Nodes in einem solchen Netzwerk ist bei Verwendung der Standardmodule auf 32 beschränkt, bei Verwendung anderer Transceiver sind auch mehr Nodes möglich. Hierfür ist ein seperates Gateway erforderlich.
Node-ID
Die Vergabe der Node-ID's muß im Sketch selbst erfolgen, die automatische Zuweisung funktioniert systembedingt nicht.
Hardware Serial
Die für die Anbindung der Module definierten PINs (8+9) sind tief im Code der AltSoftSerial-lib verankert und sollten nicht geändert werden. Möglich ist jedoch, die Module an eine serielle Hardwardwareschnittstelle anzuschließen. Am einfachsten ist dies, wenn der Microcontroller mehrere Schnittstellen bereitstellt, wie z.B. der ATMega32U4, der im Arduino Pro Micro verbaut ist. Bei einem ATMega328 (Nano oder Pro Mini) steht jedoch nur eine Hardware-Serial-Schnittstelle zur Verfügung, über die standardmäßig Debug-Ausgaben ausgegeben werden. Bei diesen wären daher entweder die Debug-Ausgaben zu deaktivieren oder - solange erforderlich - auf die Software-Serial-Schnittstelle (PINs 8 und 9) umzuleiten[5].
Kann auf AltSofSerial verzichtet, werden, hat man ca. 10% mehr Speicher zur Verfügung (ATmega328).
Busauslegung und MAX485-Transceiver
Ein funktionaler Bus erfordert eine sinnvolle elektrische Auslegung, insbesondere bei der Wahl geeigneter Widerstände. Hier finden Sie hierzu ein Hilfsmittel. Beachten Sie, dass auf gängigen MAX-Transceiverbausteine in der Regel jeweils einen 120-Ohm-Widerstand verbaut ist. Dieser sollte nur am Gateway und der letzten Node auf dem Bus zu finden sein, bei eventuellen Problemen prüfen Sie daher zuerst, ob bei allen anderen Nodes mind. diese Widerstände entfernt wurden! Hier sind weitere Informationen zu diesen Modulen zu finden.
CAN-Transceiver
Statt der RS485-Transceiver können auch CAN-Transceiver eingesetzt werden. Diese haben folgende Vorteile:
- Die Datenleitung wird freigegeben, wenn der Microcontroller zu lange benötigt, um die nächsten zu versendenden Daten zu übergeben. Dadurch bleibt der Bus funktional, selbst wenn ein Busteilnehmer Probleme hat. Prüfen Sie vor der Beschaffung entsprechender Transceiver, dass die jeweilige Abschaltzeit zur geplanten Baudrate auf dem Bus kompatibel ist[6].
- CAN-Transceiver benötigen keinen DE-PIN, bei einem ATMega328 bleiben damit beide vollwertigen interrupt-Pins frei.
Nachteile:
- Die Paketgröße ist beschränkt, was aber im Zusammenhang mit MySensors keine effektiven Auswirkungen hat
- Nicht Pin-kompatibel zu MAX48x
Die elektrische Auslegung des Bus bleibt hierbei unverändert, es können auch RS485- und CAN-Transceiver auf demselben Bus verwendet werden.
Ablauf des Starts einer Node
Beim Start durchlaufen alle Nodes nacheinander bestimmte vordefinierte Programmroutinen in folgender Reihenfolge:
Vorversionen
- setup()
- presentation()
- loop()
seit MySensors 2.1.0
- preHwInit()
- before()
- presentation()
- setup()
- loop()
Im Detail
Dieser Ablauf ermöglicht, die Arduino-Pins vorzukonfigurieren und angeschlossenes Equipment an der für den Programmablauf richtigen Stelle zu initialisieren. Dies ist u.U. wichtig, da
- eine Node im Normalfall nicht in loop() geht, solange die presentation() nicht erfolgreich war (also solange der Controller nicht verfügbar ist). Eine Failsafe-Initialisierung von Schnittstellen sollte demnach in preHwInit() oder before() erfolgen. Es kann zusätzlich seit 2.1.1 auch die Option MY_TRANSPORT_WAIT_READY_MS min. auf 1 gesetzt werden, dann startet die loop() auch ohne Verbindung zum Gateway.
- die Initialisierung anderer SPI-Hardware auf einem gemeinsamen Bus mit den NRF-Modulem vor der presentation() erfolgen muß.
Beispiel-Sketche
- Mehrfachsensor, allerdings noch für MySensors Vers. 1.5.4
- Bidirektionale "Infrarot-Fernbedienung" aus FHEM raus iVm. remotecontrol
- mehrere Dallas-Temperatursensoren auf einem Bus eindeutig erkennen
- Display ansteuern
Hinweise
- ↑ Nutzt man mehrere Gateways, werden alle readings, die von direkt an den Gateways angeschlossenen Sensoren geliefert werden, auf diese NodeID gemappt. Dies kann nicht geändert werden.
- ↑ Es können auch andere Microcontroller genutzt werden, insbesondere auch STM32F103-Boards.
- ↑ Der Raum "Startseite" ist defaultroom" für eine FHEMWEB-Instanz.
- ↑ Stand 04/2018
- ↑ Eine kurze Beschreibung, wie hierzu forzugehen ist aus dem Forum
- ↑ Beispiele: MCP2551 - 9600 Baud möglich, TJA1050 - erfordert Datenraten von mind. 57600 Baud (nicht empfohlen)