MySensors Starter Guide

Einführung

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!

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

Der 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.3.1 die stable-Version von MySensors.
• 2.3.2-alpha der aktuelle Development-Zweig von Mysensors

Die MySensors-Bibliothek kann direkt über die Arduino-IDE mit Hilfe des Library Managers bezogen werden. Sketche, die externe Bibliotheken nutzen, sind in einem separaten Repository verfügbar. Dieses sollte komplett installiert werden, da teilweise Modifikationen an den externen Bibliotheken vorgenommen wurden.

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, solange keine Verschlüsselung aktiviert wurde.

Zum Start

Für erste Tests sind sinnvoll:

1. 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. Möglich ist auch, ein Gateway mit einem Raspberry Pi aufzubauen, diese Variante ist jedoch weniger empfehlenswert (siehe Thread unten).
• ein weiterer Arduino (Nano oder Pro Mini)
• zwei Transceiver-Module. Da sehr viele gefälschte nRF24L01+-Module (aus historischen Gründen der default) im Umlauf sind, ist es empfehlenswert, mit einem alternativen Transport-Layer zu arbeiten: je zwei RFM69, RFM95, RFM96 oder RS485-Module, zumal die Funk-Reichweiten bei 868- oder 433MHz deutlich größer sind als die, die mit den Standard-nRF24L+-Modulen realistischerweise erzielt werden können.
• 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.

Einige instruktive Hinweise zu "typischen Anfängerproblemen" wegen unpassender Hardware-Vorauswahl (Stand: 05/2020) sind in diesem Thread auf MySensors.org zusammengetragen.

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.

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.

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

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.

Die 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 im Raum "MYSENSORS_DEVICE" 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.

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

Dieser Abschnitt muss überarbeitet werden, seit einiger Zeit wird der Sendestatus in einem eigenen Reading verwaltet!

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:

defmod Status_RS485 readingsGroup <Gerät>,<Status> TYPE=MYSENSORS_DEVICE:FILTER=IODev=MySensorsRS485GW:heartbeat
attr Status_RS485 group Technik
attr Status_RS485 mapping %ALIAS
attr Status_RS485 noheading 1
attr Status_RS485 room Startseite,Steuerung->Allgemein
attr Status_RS485 valueFormat {$VALUE !~ m/alive/?$VALUE:undef;;}
attr Status_RS485 valueIcon {'heartbeat.dead' => 'lan_rs485@orange','heartbeat.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

smartSleep

Verwendet eine Node smartSleep, wird im Reading state angezeigt, ob die Node derzeit schläft oder nicht. Messages an eine schlafende Node werden dabei zwischengespeichert und erst dann versendet, wenn die Node empfangsbereit ist. Um Datenverluste durch sich überschneidende Messages zu vermeiden, ist aus FHEM-Sicht eine Node grundsätzlich nur zwischen dem Empfang der pre-sleep-Message (im Arduino-Code durch eine smartSleep()-Anweisung verursacht) und dem Ablauf eines kurzen Timeouts (ca. 300ms) empfangsbereit. Man kann FHEM durch das Senden einer heartbeat-Message auch vorher mitteilen, dass die Node empfangsbereit ist, etwa, um Wachphasen für Messzyklen direkt für die Abfrage von anstehenden Informationen beim Controller (FHEM) zu nutzen. Empfangsbereitschaft wird dann bis zum Ablauf des geschilderten Timeouts angenommen. Der Empfang einer heartbeat- oder pre-sleep-Message ist auch aus FHEM-sicht der Trigger, um alle anstehenden Messages zu senden, wobei zunächst ausstehende Ack-Messages versendet werden, und dann die allgemeine Queue.

Hinweis: Sketch-seitig sind 500UL als Timeout eingestellt, was bei 1MHz 500ms entspricht. Wird der Controller mit einer höheren Frequenz betrieben ist der Wert entsprechend anzupassen, sonst kann es aus diesem Grund zu verlorenen Messages kommen.

Da FHEM nur über die pre-sleep-Messages die Information bekommt, ab wann eine Node wieder nicht mehr zu erreichen ist, ist zum einen eine zuverlässige Funkverbindung sicherzustellen, zum anderen kann eine Kombination mit normalen sleep-Anweisungen dazu führen, dass eventuell nachrichten verloren gehen.

Mehrere Gateways

Es können auch mehrere MySensors-Gateways verwendet werden. Dabei sind jedoch folgendes zu beachten:

• Das erste zugehörige MYSENSORS_DEVICE wird als Node_0 angelegt
• Weitere MYSENSORS_DEVICE-Geräte werden für jedes weitere Gateway angelegt, wobei jeweils der Name jeweils aus dem des Gateways abgeleitet wird.
• 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

Zwischenzeitlich wird ein update über den jeweiligen Transport-Layer (OTA) von FHEM unterstützt.

• Im Firmware-Verzeichnis braucht es eine Datei csv-Datei, die definiert, welche Firmwares es für MySensors gibt. Das Format entspricht 1:1 dem für die MYSController-Software, wie es unter [1] beschrieben ist
• Die Firmware-Dateien (*.hex) müssen auch ins firmware-Verzeichnis gelegt werden
• Jedem Node kann man einen Firmware-Typ mittels der Setter-Funktion fwType zuweisen
• Mit der Funktion flash kann man dann den Node flashen
• Als erweiterte Option gibt es das Attribute autoUpdate. Ist dieses gesetzt, wir bei jedem Bootvorgang der Node geprüft, ob es eine neuere Firmware gibt und diese ggf. automatisch upgedated.

Alternativ kann für OTA-updates, vorübergehend auch ein anderer Controller als FHEM eingesetzt werden. Ein Howto ist in diesem Forenbeitrag zu finden. Der dort verwendete Bootloader erwartet OTA-Updates für nRF fest auf Channel 76.

Links, Tricks, Kniffe und Erfahrungen

Interessante Links

Offizielles Debugging-Schema

• Debug / FAQ bei MySensors.org

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

• Forumsbeitrag zu MySensors Verschlüsselung und Signierung
• Darstellung bei MySensors.org

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.

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:
  • Eigenbau-Antennenverbesserung
  • Schirmung

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

Funk-Themen (RFM-Chips)

1%-Regel (868MHz)

Nutzt man den Frequenzbereich um 868MHz, ist die 1% Regel zu beachten.

Funk-Leistung

Bei Transceivervarianten mit höherer Leistung (insbes.: RFM69HW) muß diese ggf. per Software begrenzt werden, um die in Deutschland geltenden Grenzwerte einzuhalten

Tips und Tricks zu MySensors-RS485

Stand: 06/2019, Version 2.3.1 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.

Als Softwareversion sollte mind. die Master-Version 2.3.0 verwendet werden.

Node-ID

Die Vergabe der Node-ID's muß im Sketch selbst erfolgen, die automatische Zuweisung funktioniert systembedingt nicht. Das entsprechende #define MY_NODE_ID <ID> muß im Code der Node vor #include <MySensors.h> erfolgen.

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.

Kann auf AltSofSerial verzichtet, werden, hat man ca. 10% mehr Speicher zur Verfügung (ATmega328).

Busauslegung und MAX485-Transceiver

• 

  Anschlussschema für Nanos und Pro Minis mit Altsoftserial und geshieldeter Verbindung

• 

  Anschlussschema für Nanos mit Inclusion-Mode-Taster und LED's (AltSoftSerial)

• 

  Verkabelung mit CAN-Transceivern (MCP2551) und Hadware-Serial (Arduino Micro Pro)

• 

  Gateway-Anschlussbeispiel bei Verwendung von Pro Micro und einem CAN-Tranceiver an Serial1 (HardwareSerial)

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! Leider ist die Wikispaces-Seite zu den MAX-Modulen (https://arduino-info.wikispaces.com/RS485-Modules) nicht mehr verfügbar, dort waren viele weiteren Informationen zu diesen Modulen zu finden. Die wichtigste: Verbinden Sie den DE und RE-Pin miteinander!

Einige Hinweise sind noch bei arduinoinfo.mywikis.net und in diesem RS485Example zu finden.

Beachten Sie dabei, dass die PIN-Vergabe bei MySensors der (fest vorgegebenen!) von AltSoftSerial entspricht, nicht der von SoftwareSerial, weitere Informationen dazu finden Sie bei den beiden Beispiel-Sketchen, die bei mysensors.org unter Build RS485 zu finden sind (Achtung: in dem Motion-Sensor-Sketch sollte noch eine NodeID vergeben werden wie oben beschrieben!).

Ein Schema für die Verkabelung mit SoftwareSerial entsprechend der Beispielsketche bei MySensors.org ist rechts abgebildet. Sofern dies möglich ist, ist zu empfehlen:

• geschirmte Kabel zu verwenden (Schirmung muß auf einer Seite auf GND gehen)
• eine gemeinsame GND-Verbindungen für alle Nodes (ggf. mit Ausnahme des Gateways) herzustellen
• alle Nodes (ggf. mit Ausnahme des Gateways) zentral zu versorgen (z.B. über eine bzw. zwei weitere Adern, wobei für längere Kabel eine höhere Spannung, z.B. 12V, nebst lokaler Adaptierung auf 5V durch den internen Spannungswandler des Nano oder einen separaten step-down-Baustein für eine stabile Versorgung zu empfehlen sind).

Eine etwas abweichende, aber dennoch funktionale Variante der Busauslegung is in Easy-RS485-Bus zu finden; diese sollte auch mit CAN-Transceivern verwendbar sein.

CAN-Transceiver

Statt der RS485-Transceiver können auch CAN-Transceiver eingesetzt werden. Benötigt wird dabei nur der Chip, der die Modulation der seriellen Ausgabe des Arduino auf den RS485-Bus übernimmt, kein vollständiges CAN-Chipset, das üblicherweise über SPI anzubinden wäre. Getestet wurde dies mit MCP2551 (leider seit 2014 EOL, aber - Stand Mai 2020 - noch erhältlich) und TJA1050 (der aber höhere Datenraten benötigt, die an der Obergrenze dessen liegen, die ein ATMega32 an softwareserial bei 16MHz liefern kann).

Die CAN-Bus-Treiber 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.
• 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. Dabei muss allerdings beachtet werden, dass man die Kanäle nirgendwo vertauscht, es muß strikt CANhi auf CANhi gehen.

Debug-Ausgaben: Tauschen von Hardware- und Software-Serial

Will man eigentlich Hardware-Serial für die Kommunikation von und zum Gateway verwenden, kann man übergangsweise zum Debuggen der Nodes auch die dafür benötigten Ausgaben mit AltSoftSerial machen und das dann später abschalten. Benötigt werden dann aber die entsprechenden PINs (bei ATMega328: 8+9), siehe dieser Beitrag:

#include <AltSoftSerial.h>

#define MY_DEBUG              //MYSENSOR lib

#define MY_BAUD_RATE (9600)                      //MYS debug, braucht man das wirklich?
#define MY_SPLASH_SCREEN_DISABLED        //MYS bug, SPLASH SCREEN kommt sonst auf RS485 raus

#define MY_DEBUGDEVICE altSerial

// Set RS485 baud rate to use
#define MY_RS485_BAUD_RATE 9600

#define MY_RS485_HWSERIAL Serial

AltSoftSerial altSerial;

#include <MySensors.h>

void before()
{
  altSerial.begin(9600);

  altSerial.print(bla);
  altSerial.println(blub);
}

Andere Microcontroller

Neben "klassischen Arduinos" (und dem ESP8266, insbes. als Gateway) können auch andere Microcontroller verwendet werden. Diese erfordern jedoch teils eine vertiefte Einarbeitung. Hier einige Stichpunkte dazu:

STM32

Dokumentation

Leider scheinen einige Wiki-Artikel im Zusammenhang mit einem Serverumzug oä. verloren gegangen zu sein, die Seite stm32duino.com scheint jedenfalls 2019 für längere Zeit (mehrere Monate) nicht mehr zu erreichen gewesen zu sein und man konnte nicht mehr alle alten Artikel wiederherstellen. Also trifft man im Verlauf der Recherchen immer wieder mal auf links wie "siehe hier nach: https://www.stm32duino.com/viewtopic.php?f=2&t=873" ...

Board-Definitionen

Diese sind aus verschiedenen Quellen erhältlich. Für MySensors wird jedoch u.a. eine libmaplebenötigt. Diese erhält man jedoch nicht, wenn man die Board-Definitionen gemäß https://github.com/stm32duino/wiki/wiki/Getting-Started lädt, man muss tatsächlich vorgehen wie bei https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation beschrieben - zumindest für die Erstellung von firmwares für MySensors.

Nomenklatur

Es gibt keine wirklich klare Terminologie, insbesondere werden für die gehandelten Boards teils eigene Begriffe verwendet, man muß teils raten, was man tatsächlich erhält. Dies gilt insbesondere für "Blue Pills" und "Black Pills" - hier muß man ggf. raten, insbesondere anhand der Prozessorbezeichnung und der Methode, verschiedene Boot-Einstellungen vorzunehmen (Jumper oder Buttons usw.). Teils wird der vorinstallierten Bootloader "Arduino Bootloader" genannt, obwohl dies keine allgemein eingeführte Bezeichnung ist. Tatsächlich scheint es sich um einen einen Maple 2.0 Bootloader (in der Nomenklatur der alten STM32 Infrastruktur) zu handeln, in der Nomenklatur der "MySensors-relevanten" Infrastruktur der Arduino IDE entspricht das dem "STM32duino bootloader".

Schaltleistung

Da z.b. der weit verbreitete STM32F103 nur 20mA pro GPIO schalten kann, empfiehlt es sich, spezielle Schaltbausteine wie z.B. den ULN2803 zu verwenden, um z.B. Relais zu schalten.

nRF52

Info-Thread bei MySensors.org.

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