MySensors Starter Guide: Unterschied zwischen den Versionen

Aus FHEMWiki
Zur Navigation springen Zur Suche springen
Zeile 1: Zeile 1:
== Einführung ==
== Einführung ==
[http://www.mysensors.org 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.  
{{Randnotiz|RNTyp=g|RNText=Auch wenn hier einige typische Fragestellungen zu MySensors beantwortet werden: Die beste Referenz für alle Fragen zu MySensors ist und bleibt aber die offizielle Hompage des Projekts!}}[http://www.mysensors.org 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.  
{{Randnotiz|RNTyp=g|RNText=Auch wenn hier einige typische Fragestellungen zu MySensors beantwortet werden: Die beste Referenz für alle Fragen zu MySensors ist und bleibt aber die offizielle Hompage des Projekts!}}
 


=== Nodes und Children===
=== Nodes und Children===

Version vom 18. April 2018, 10:27 Uhr

Einführung

Info green.pngAuch wenn hier einige typische Fragestellungen zu MySensors beantwortet werden: Die beste Referenz für alle Fragen zu MySensors ist und bleibt aber die offizielle Hompage des Projekts!

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

Info green.pngDer Verfasser hat in der Vergangenheit festgestellt, dass die bei MySensors beteiligten Entwickler eventuelle Verbesserungen und Fehlerkorrekturen nicht mehr in die "stable"-Version rückportieren. Bei Problemen empfiehlt es sich daher, die jeweilige beta-Version zu testen. Hierzu muß aber in der Regel auch das verwendete Gateway auf diese Version upgedated werden.

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:

Info green.png1. Für Sensbender-Boards sind spezielle Board-Definitionen für die IDE verfügbar. Nach den Release Notes sind diese ab der Version 2.0.0 zu empfehlen, die Installation erfolgt über File -> Preferencies -> Additional Boards Manager URLs 2. Manche neueren Boarddefinitionen aus der IDE führen u.U. zu häufigeren Reboots. Seit 1.6.18 scheint das Problem behoben zu sein, ansonsten ist ein Downgrade der Boarddefinitionen für AVR-Boards bis <=1.6.11 zu empfehlen.
  • 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.

Info blue.png
Bei Verwendung eines seriellen Gateways ist zu empfehlen, einen Arduino mit orginalem FTDI-Chip zu verwenden und diesen mit der "by-id"-Methode (Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden) zuzuweisen. Beim Anschluß mehrer Arduinos mit einem CHG340/CHG341 an denselben Computer/Raspberry sind diese nur mit hohem Aufwand eindeutig addressierbar.


Info blue.png
Die Einbindung eines MySensors-Netzwerks kann auch über MQTT erfolgen. Dabei übernimmt ein MySensors-MQTT-Gateway die Kommunikation mit dem Broker.


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

Info blue.png
Sobald die ersten Meßwerte übertragen wurden, werden nach einem Browser-Refresh auch die aktuellen Meßwerte angezeigt, dies kann je nach Einstellung im Sketch aber einige Zeit dauern.


Info green.pngDie Readings werden dem Modul MYSENSOR_DEVICE.pm entnommen. Sind diese dort nicht im Bereich "reads" bzw. "sends" enthalten, kann man fehlende Readings auch manuell anlegen.

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.

Info blue.png
Die NodeID wird - wie einige weitere Informationen - im sog. EEPROM des Arduinos abgespeichert. Ist sie einmal vergeben, ändert sie sich auch bei einem erneuten flashen der Node nicht mehr, es sei denn, man gibt per "define" im Sketch eine andere NodeID vor.


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'}

bzw. 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

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[3]. 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.

Info blue.png
Ob dies der Fall ist, läßt sich leicht testen, indem man die fragliche Node wieder in die Nähe des Gateways bringt. Funktioniert es dort wie erwartet, liegt eine schlechte Funkverbindung vor.


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);.

RS485

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.

Bekannte Probleme bei RS485

[4]

  • Die Vergabe der Node-ID's muß im Sketch selbst erfolgen, die automatische Zuweisung funktioniert nicht.
  • Die für die Anbindung der Module definierten PINs (8+9) sind tief im Code verankert und sollten nicht geändert werden.
  • Sollte der Speicher knapp werden, empfielt es sich, statt der softserial-Variante HW_SERIAL zu verwenden. Dies benötigt ca. 10% weniger Speicher (ATmega328).

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

Hinweise

  1. 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.
  2. Es können auch andere Microcontroller genutzt werden, insbesondere auch STM32F103-Boards.
  3. Stand 04/2018
  4. Stand: 04/2018, Version 2.2.0