RS485 / ModBus / DMX

Te

Wenn mehrere Systeme miteinander kommunizieren können, wird normalerweise ein Bus-System eingesetzt. I²C-Bus und 1-Wire sind bekannte Beispiele aber auch Ethernet, WLAN sind technisch ein Bus. Für zwei kleine Bastelprojekte musste ich mehrere Sensoren an mehreren Stellen abfragen. Die Entfernung war zu lang, um jeden Sensor individuell abzugrafen oder über I2C zu verbinden aber jeder Sensor sollte nicht gleich eine IP-Adresse per WLAN bekommen. Ein Bus war gesucht, der Versorgungsspannung und Daten zuverlässig überträgt. Daher habe ich mit die elektrischen Eigenschaften von RS485 genauer angeschaut, der auch bei DMX (Lichttechnik) genutzt wird, und Zugriffsprotokolle überlegt.

Es gibt eine Unzahl von "Bus-Systemen" in der Elektronik und jeder hat seine Vor/Nachteile. Der 1-Wire Bus kommt in der kleinsten Form mit 1 Kabel (zzgl. Masse) aus, während I²C-Bus eine Leitung für den Takt und eine zweite Leitung für die Daten nutzt. In der Gerätesteuerung oder Industrie kommt häuft das Protokoll Modbus über Ethernet aber noch häufiger über serielle Verbindungen vor.

Ich habe mich mit dem Thema befasst, weil ich in mehreren Projekten solche Anforderungen hatte, z.B.

  • Parkplatz-Belegt-Melder
    Mich hat interessiert, wie ich die Parkplätze in einer Tiefgarage erfassen kann
  • Haus-Klima
    Weiterhin wollte ich mehrere Messpunkte im Haus auf Temperatur aber vor allem auch Wasser (z.B. in Kellerschächten) überwachen und viele batteriebetrieben Einheiten sind nicht ökonomisch

Es gibt sicher noch weitere Projekte, in denen mehrere Geräte an einem Bus hängen aber der Einsatz vo WLAN oder LAN technisch nicht möglich oder sinnvoll ist.

RS485 = Physik (OSI 1)

Serielle Schnittstellen gibt es schon sehr lange. In der PC-Technik wurde RS-232/V.24 früher oft für Mäuse und Modems genutzt. Es gab getrennte Leitungen für jede Funktion (Senden, Empfangen, Steuerung). Die Signalisierung erfolgte über positive/negative Spannungspegel  (-3/12 und +3-12Volt. Es war nur eine 1:1 Verbindung und nicht für lange Strecken nutzbar. In der Industrie wurden daher die Informationen über 4-20mA-Stromschleifen übertragen, von denen jeder Hersteller eigene "Standards" geschaffen hat. Die Informationen selbst wurden dann seriell übertragen und auch hier hat jeder Hersteller eigene Definitionen eingeführt. Beide Schnittstellen verbinden nur zwei Geräte.

RS485 nutzt Spannungsdifferenzen und erlaubt den Betrieb mehrerer Endgeräte an einem Bus im Habduplex oder Vollduplex-Betrieb. Am Bus müssen Geräte natürlich sicherstellen, dass Sendungen Sie sich nicht überlagern. Für meine Bastelprojekte reicht mir der Halbduplex-Betrieb.

Mehr als die maximal möglichen 32 Endgeräte werde ich vermutlich nie an einen Bus anschließen. Die Stromversorgung ist gesondert zu sehen.

Technisch gibt es von MAXIM einen Treiber-Baustein, der diese Pegel auf TTL-Level setzt und getrennte Ein/Ausgänge für die Daten. Wichtig ist dabei die "Enable"-Funktion, da ein Gerät im Halbduplex-Betrieb immer im "Empfangsbetrieb" sein muss und eine Sendung aktiv eingeleitet werden muss.

Protokoll ModBus? (OSI2+)

Einzelne Bits zu übertragen ist nur die Basis. Das fängt schon damit an die kleinste Informationseinheit zu beschreiben, da RS485 keine "Taktleisung" hat. Daher müssen sich alle Geräte am Bus auf die gleiche Geschwindigkeit (Baudrate) einigen, sei es per Definition oder durch eine Präambel zur Synchronisierung der Empfänger. Eine serielle Übertragung (RS-232) nutzt eine vereinbarte Bitrate und Start/Stop-Bits.

Über die RS-485-Schnittstelle nutzen viele Produkte das "ModBus-Protokoll". Neben der neueren Übertragung per TCP ist immer noch die serielle Übertragung als binäre Daten (Modbus/RTP) oder als String (Modbus/ASCII) häufig im Einsatz. Modbus definiert sogar Stecker und Belegung:


Modbus Pins: https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
Zur EIA485-Bennenung: D0=A, D1 = B

Die Übertragung selbst nutzt 1 Start, 8 Daten (LSB first), 1 Party, 1 Stop-Bit, konfigurierte Baudrate und ein Rahmen hat folgendes Format:


Modbus RTP Quelle: https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf


Modbus ASCII Quelle: https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

Der Modbus-Funktionscode (1 Byte) und die Daten sind im gelben Paket codiert. Modbus funktioniert bidirektional aber ein Master steuert den Bus und stellt Anfragen und sammelt die Antworten ein. Eine direkt Kommunikation zwischen Slave-Systemen ist nicht vorgesehen

Protokoll DMX (Digital MultipleX)

Die RS485 Schnittstelle wird z.B. auch von der Bühnentechnik genutzt. Hier kommen sogar genormte robuste Steckverbinder zum Einsatz. Zusätzliche optische Entkopplungen sichern die Geräte selbst weiter ab.

  • Elektrisch ist es ein RS485-Bus mit maximal 32 Geräten
    Das 32er Limit ist elektrisch begründet und hat nichts mit einer "Adressierung" zu tun. Mehr Geräte erfordern entsprechende Repeater
  • Als Kabel kommen abgeschirmte Leitungen (meist Twisted Pair) mit 110Ohm Impedanz zum Einsatz, um die 125kHz Rechteck-Signale gut abzuschirmen
  • Die Informationen werden seriell mit 8 Datenbits, kein Paritätsbit und 2 Stoppbits (8N2)
  • Signalrate ist 250 kBaud festgelegt
  • Starterkennung "Break" ist ein 22 Bit (88μs) lange logischen 0, gefolgt von zwei Bits 8μs mit logischer 1
  • 512 Byte Paketrahmen a 8 Bytes
  • Es gibt keine "Adressen" sondern Kanäle mit 8Bit-Auflösung
  • Ein Gerät kann mehrere Kanäle belegen
    So belegt RGB-LED mit 0-255 für Rot, Grün und Blau dann drei Kanäle.
  • Ein Datagramm hat bis zu 512 Kanäle
  • Es gibt einen Master. alle andere sind Slaves
  • Der Master senden immer wieder das komplette Datagramm

Jedes Gerät bekommt dann eine "Adresse" zwischen 1 und 512 und werden das Byte (oder die Bytes) aus. Ein Gerät, welches z.B. drei Bytes zur Steuerung benötigt, belegt damit auch drei Adressen. Eingestellt wird die Startadresse. Mit 250kBaud können damit maximal 50 Gruppe/Sek gesendet werden. Wobei DMX-Controller wohl sowieso immer wieder die Gruppe senden. Wenn Sie mal verloren gehen würde, dann ist 20ms später die Information noch mal da.

Günstige DMX-Systeme haben nur einen 3-poligen XLR-Stecker, obwohl eigentlich 5-polig definiert sind. Die beiden zusätzlichen Leitungen sind dann ein zweiter Bus oder kann als Rückkanal genutzt werden.

How to program DMX lights for beginners (simple lesson)
https://www.youtube.com/watch?v=dJQAZsNwcv4

DMX-Tutorial Part 1: Grundlagen | haus-automatisierung.com
https://www.youtube.com/watch?v=VVeJo-57ZXQ

Slave/Master

Bei DMX und ModBus/RTP aber auch I2C und 1-Wire gibt es immer genau einen Master, der mehrere Slave-Systeme abfragen kann. Die Slaves senden ihrerseits eigentlich nur auf Anforderung aber nicht alleine. Für meine Bastelprojekte kann ich so etwas auch umsetzen aber dann muss jeder Slave auch eine Adresse haben und auf Anfragen lauschen. Er muss also immer oder zumindest zu bekannten Zeiten empfangsbereit sein.

Für meine Projekte mit wenig Daten ziehen ich ein anderes Verfahren vor, bei dem jeder Sensor einfach seine Daten regelmäßig hinausposaunt. Im LAN/WLAN könnte er das sogar per Broadcast/Multicast machen, so dass mehrere Empfänger die Daten empfangen könnten und ich mir eine aufwändige Konfiguration auf dem kleinen Sensor spare. Er braucht aber zumindest eine Art "Adresse", damit man die Sensoren unterscheiden kann.

  • Der oder die Master ist 24h empfangsbereit
    Er wartet dauerhaft auf eingehende Datagramme. Das kann ein RS485-USB-Stick sein aber auch ein ESP mit Netzwerkzugang, der die empfangenen Daten einfach z.B. per MQTT, HTTP o.ä., weiter gibt
  • Die Sensoren sind meistens "aus" (Sleep) oder im Empfangsmode
    Die dürfen den Bus in dem Zustand natürlich stören (Hochohmig) aber das ist kein problem.
  • Die Sensoren wachen auf, machen ihre Messung und senden das Ergebnis aus den Bus
    Der Sensor sendet eine hinterlegte/konfiguriert "eindeutige Adresse" und dann die Daten. Wenn ein Client z.B. 1 Byte Adresse + 4 Bytes Daten sendet, dann sind das auf jeden Fall weniger als 100Bit Dauer. Bei 250kBaud (DMX-Rate) belegen wir 1/2500Sek den Bus.
  • Kollisionen sind sehr selten
    Natürlich könnte es sein, dass zwei Clients zur gleichen Zeit etwas senden. Theoretisch könnte ein Client auch "mitlauschen" und Kollisionen durch "überschreiben" erkennen. Wenn aber ein Client eh nur alle 10 Min einen Messwert  oder ein "Lebenszeichen" sendet, dann sind das bei 30 Clients gerade mal 0,002% Wahrscheinlichkeit. Das Risiko kann man weiter verhindern, wenn der Client einfach mehrfach die Daten mit unterschiedlichen Verzögerungen sendet.
  • Master kann neue und ausbleibende Meldungen erkennen
    Damit ist eine einfache Plug&Play-Erkennung und Fehlerdiagnose möglich
  • Datenformat = String
    Für meine einfachen "Wasserstand" oder "Temperatur" o.a. Messungen reicht das locker aus und ist flexibel genug. Selbst wenn ich die Daten nicht binär sondern als ASCII-String (leichter zu debuggen) sende, bleibt genug Reserve

Klingt eigentlich ganz einfach

Bausteine

Für den Empfang kann ich einen ESP8266, ESP32 aber auch Arduino oder sogar Raspberry nutzen. über entsprechend billige "RS485/USB-Adapter kann ich sogar einen PC einfach mit an den Bus anschließen und damit sogar die gesendeten Daten einfach debuggen. Von der Firma Sertronic aus Berlin gibt es einen Adapter, der z.B. auch bei Reichelt günstig erhältlich ist.


Quelle: Reichelt
Hier bin ich noch nicht ganz sicher, denn mir fehlt zumindest der dritte Anschluss für Masse

Damit steht einem Debugging nichts entgegen, wenn keine elektrischen Störungen zu befürchten sind.

Die Sendeseite ist ebenso flexibel, da auch hier ja "nur" eine serielle Schnittstelle auf einem PIN erforderlich ist, die dann z.B. durch einen Schnittstellen-Bausteine elektrisch sauber umgesetzt werden kann. Folgende zwei Bausteine werden oft genutzt

Baustein Preis Volt

SN75176 :Differential Bus Transceiver

0,40€ (Reichelt)

5V

MAX 485 CPA RS485/422

2€  (Reichelt)

12V

Der SN75176 ist mit 5V für meine Projekte besser geeignet und nebenbei sogar noch günstiger. Allerdings müssen Sie auch hier mit ESP8266/ESP32 aufpassen, die mit 3,3V arbeiten. Die Eingänge erkennen ein High ab 2Volt, so dass man nur den Ausgang von 5V auf 3,3V z.B. per Spannungsteiler anpassen muss. Ein ATTiny85 hingegen kann auch mit 5V arbeiten und können daher direkt angeschlossen werden.

Wenn man dann einen ATTINY85 mit USB-Anschluss nutzt dann sind D0-D2 ideal als Verbindung zu Sensoren per I2C-Bus oder 1-Wire Bus. Für die Ansteuerung des RS485-Busbausteins brauchen wir noch zwei Pins, die den Sendebetrieb aktivieren und Daten übermitteln.

Aber wenn Sie ihre Sensoren im Code statisch abfragen, dann sollte das problemlos möglich sein.

Ehe Sie aber nun selbst "Löten", können Sie auch einfach mal auf den Markt schauen, was es da schon gibt. Es gibt nämlich schon Fertigbausteine mit RS485-Schnittstelle, z.B.

Bild Preis Beschreibung
M5Stack ATOM RS485 Kit
 12US$
16€

Komplettes Kit bestehend aus dem M5Lite und dem passenden Adapter.
ATOM Tail485 - RS485 Converter for ATOM

5 US$

https://m5stack.com/products/atom-tail485

 
RS485 to TTL Converter Unit

4€

Reines Modul, um den Grove Connector zu RS485 umzusetzen

https://eckstein-shop.de/M5Stack-RS485-to-TTL-Unit

Projekt Kellerüberwachung

Es ist mir mehr als einmal passiert, dass Regenwasser von oben in den "wasserdichten" Kellerschacht" gelaufen ist. Daher wollte ich in jedem Schacht einen "Wassermelder" einbauen und wenn ich schon dabei bin, auch eine Fensterüberwachung/Glasbuchüberwachung. Auch ein Thermometer und Feuchtigkeitsmelder wäre nett. Alles in allem genug, um einen Atmel mit BME280 per I2C-Bus und zwei Digitaleingängen zu verteilen. Gegen "Kabeldefekte" hilft dann ein Device am Ende, der auch den 120 Ohm-Widerstand trägt aber vor allem regelmäßig ein Lebenszeichen sendet. Verlegt wurde dann ein 4-adiges EIB-Kabel in der Kehle von Kellerdecke und Wand rund ums Haus, so dass ich zwei Adern für den Bus und zwei Adern als Stromversorgung habe. Elektrisch habe ich folgendes "fliegend" verdrahtet.

Zuerst habe ich an einen ATTiny gedacht, der direkt über einen USB-Anschluss programmiert werden könnte. Ich hatte mir folgende Verdrahtung überlegt:

AT85Pin  ATTiny   Extern
  1        D5    (nicht verwendet, Reset)
  2        D3    Digitaleingang (Wassermelder Glasbruch/Fensteröffnung potentialfreie Kontakte)
  3        D4    RS485 D   zum Daten zu Senden
  4              GND
  5        D0    I2CBus  SDA
  6        D1    RS485  DE und !RE, um Senden/Empfang umzuschalten.
  7        D2    I2CBus  SCL
  8              5V VCC

Dann bleibt aber nur ein Digitaleingang übrig. Für weitere Eingänge müsste ich einen i2C-Expander, z.B. PCF 8574 N (Remote 8-Bit I/O Expander for I2C Bus, PDIP-16) mit 8 Eingängen verbauten. Dann kann ich gleich einen D1Mini, Wemos Mini oder Arduino Nano einsetzen. Da macht dann auch der "echte serielle Port" die RS485-Kommunikation einfacher als ein "SoftSerial".

 

Die Seite wird fortgeschrieben, wenn ich das Projekt abgeschlossen habe

Andere BUS-Systeme

RS485 ist nur ein Bus. Es gibt natürlich noch andere Systeme, auf die ich hier kurz eingehe

CAN-Bus

Den CAN-Bus finden sie in der ein oder anderen Variante bei fast allen Kraftfahrzeugen.

433MHz Funk als Bus

Wenn man nicht mit Kabeln arbeiten will, dann kann man die gleiche Logik auch per Funk nutzen. Es gibt mit dem HC12-Modul sogar einen interessanten Baustein, der den Funk über 433 MHz als serielle Schnittstelle ganz einfach macht. Wobei man dann auch schon wieder überlegen kann, ob nicht handelsübliche Außeneinheiten, die auf 433MHz/868MHz funken nicht die bessere Option sind, wenn deren Datagramme entschlüsselt werden können.

Bei Funk muss man natürlich immer damit rechnen, dass auch andere Systeme das Band belegen und Störsender oder fremde Daten einstreuen. Das eigene Datenback sollte also nicht nur eine Adressierung und Prüfsummer haben, sondern auch validieren oder sogar verschlüsseln.

Gebäudesteuerung: KNX/EIB

Auch In der Gebäudesteuerung gibt es natürlich schon viele Jahre entsprechende Bus-Systeme und KNX/EIB ist hier sicher der bekannteste Vertreter. Allerdings spielt er in meinen IoT-Projeken keine Rolle. Gleiches gilt für verschiedene andere Bussysteme anderer Hersteller

Powerline (PLC)?

Sie könnten natürlich auch auf den Gedanken kommen, einfach die Stromleitung als "Übertrager" zu nutzen. Es gibt ja auch "Powerline" um Daten über Strom zu übertragen. Nun können Sie mit 3,3/5 Volt-Ausgängen natürlich nicht an 230V gehen und auch VDE-Vorgaben, Funkfrequenzen und letztlich auch ihr eigener persönlicher Überlebenswillen sollte Bastelexperimente hier verbieten. Wenn, dann müsste man das Signal mit einem Übertrager einkoppeln, und als Frequenz codieren. Aber technisch sind je nach Leitung und Frequenz sehr hohe Datenraten möglich. Entsprechende "Modems" gibt es natürich:

Wobei die Konformität mit lokalen Sicherheitsvorschriften des Module aber auch des späteren "Gesamtkunstwerks" auf einem anderen Blatt steht. Auch muss an jeder Stelle eine entsprechende Steckdose vorhanden sind.

Interessant wäre es, wenn es tatsächlich ein komplett verschweißtes Fertigmodul geben würde, welches auch noch ein 3,3/5V-Netzteil für IoT Experimente enthalten würde, z.B. in Form eines Steckernetzteil mit entsprechendem Raum für eigene Module.

Weitere Links