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

Der klassische ModBus ist ein serieller Feldbus mit einem Master und einem oder mehreren Slave-Systemen. Elektrisch kommt hier RS-232, RS-422 oder RS-485 zum Einsatz. Die Bits werden entweder als RTU-Mode ( 1 Byte mit 8 Bit sind 2 Hex-Zahlen von 0-F) oder im ASCII-Mode (1 Byte enthält das ASCII-Zeichen von 0-F) gesendet und empfangen. Bei ASCII startet ein Befehl mit einem Doppelpunkt" :" und wird mit einem CR LF beendet. Bei der RTU-Übertragung wird mindestens die 3,5fache Zeit eines Zeichens "Ruhe" eingehalten und dann gestartet. Klassisch wird 9600,n,7,e,1 genutzt (7 Bit 1 Startbit, Parity, Stop-Bit). Die ersten beiden Zeichen oder 8 Bit sind die Adresse des Slave, die nächsten beiden Zeichen oder 8 Bit die Funktion. Dann kommen die Daten gefolgt von einer Prüfsumme und das Ende.

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.

Wenn man mehr Systeme betreiben will, gibt es RS-485 Repeater.

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

Achtung: DMX nutzt die Modbus RTU als physikalische Schicht RS-485 aber ist ein andere Protokoll

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

Diese Geräte sorgen nur für die elektrische Kompatibilität aber sind keine aktiven Protokollgeräte. Das ist dann Sache der Software, ob sie Modbus, DMX o.. sprechen

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

Wer etwas mehr Zeit hat, kann die Adapter natürlich auch in China bestellen

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$
RS485 to TTL Converter Unit

4€
XY-017

2-3€

Natürlich finden Sie noch viele weitere Module, die entweder auf dem MAXIM485 oder anderen Chips basieren.

Modbus Scanner

Was ARP und PING im LAN ist, ist ein ModBus-Scanner für RS485. Auf einem Windows PC nutzt er den RS485-Adapter, der als COM-Port eingebunden ist, um auf dem Modbus nach Geräten zu suchen.

RS485 und WLAN/LAN

RS485 gibt es nicht nur als seriellen Bus über Kupferleitungen sondern in der IoT - Internet of Things-Welt möchte man Daten auch über weite Strecken übertragen. Daher bietet es sich geradezu an, bidirektionale serielle Übertragungen über TCP zu leiten. Das ist auch nicht sonderlich schwer, einen TCP-Strom als RS485 Signal umzusetzen und kann z.B. per Arduino oder dem beliebten ESP8266 recht einfach umgesetzt werden. Sie sollten allerdings einen Pegelwandler wie z.B. einem MAX485 oder SN75176 einsetzen.

Natürlich gibt es auch hier wieder fertige Bausteine, die direkt in ihren IoT-Projekten genutzt werden können, z.B.

Wer gar nicht mehr löten will, kann auch Komplettmodule für kleines Geld finden, die einen RS485-Bus per WLAN ins Netzwerk bringen, z.B.

ModbusTCP

Das Protokoll ist aber nicht nur auf serielle Leitungen ausgelegt. ModBus kann auch über Computer-Netzwerke gesprochen werden. Dazu wurde der Port 502/TCP reserviert. Hausinstallation heißt auch immer 230V, Schaltschrank, Hutschiene etc. Ein Platz, auf dem sich der RasPi nicht immer wohl fühlt und vor allem der übliche Nerd tut sich da schwer entsprechende Hardware zu bauen (Stichwort VDE, Sicherheit, galvanische Kopplung etc.). Es gibt aber sehr viele kommerzielle Module, die auch mit einem RasPI funktionieren können. Diese bestehend fast immer aus einem Buskoppler, der entsprechende Klemmenmodule mit einem Feldbus verbinden. Es gibt sehr viel Feldbusse (RS232, RS485, EtherCat, CANopen, ProfiNet, DALI, KNX, LON, EnOcean etc.)

Interessant sind hier die Feldbusse, die direkt TCP/IP sprechen. Dann können Sie nämlich einfach die "Elektrik" im Schaltschrank verstecken und über Ethernet die Eingänge abfragen und Ausgänge schalten. Interessant dabei ist z.B. ModbusTCP, bei dem die Pakete per TCP Port 502 übertragen wird.

Sind Sie vorsichtig, wenn Sie nun einen Portscan auf 502 durchführen. Es gibt in der Regel keine Authentifizierung, Verschlüsselung o.ä.. Solche Steuerungsnetzwerke sollten also immer strickt getrennt aufgebaut werden.

All You need to know about Modbus TCP
http://www.youtube.com/watch?v=E1nsgukeKKA

Raspberry Pi PLC - Industrial Remote IO with Modbus/TCP Driver
http://www.youtube.com/watch?v=EAXJ_3dfeNI

DEFCON 16: ModScan: A SCADA MODBUS Network
http://www.youtube.com/watch?v=z14tgdvZf_E

Modbus und PowerShell

Serielle Post von RS485-Umsetzern kosten nur wenig Geld. Als USB-Sticks sind sie für wenig Euro zu erhalten. Auch per PowerShell kann man einfache auf diese Schnittstelle zugreifen. So kann ein Skript sehr einfach die Bytes auf dem Bus lesen oder senden. Interessant wird es nur, wenn man auch die Bytes für das Modbus-Protokoll korrekt formatieren will. Bislang hatte ich selbst dafür noch keinen Bedarf sondern nutze zwar RS-485 als physikalische Schicht aber mit eigenen Protokoll.

Daher hier nur ein Link zu einem Beispielcode, der per PowerShell über MODBUS ein Relay schaltet: 

Modbus und ESP

Sensoren und Aktoren

Auf dem RS485-Bus können bis zu 32 Geräte angebunden sein. Nicht immer muss das Gerät eine Lüftungsanlage (PRTG Pluggit), eine Heizung oder eine Wallbox mit RS485-Schnittstelle sein. Es gibt auch kleinere Geräte, die z.B. Temperaturen und Luftfeuchte messen.

Eine Suche nach RS485 bei AliExpress u.a. liefert verschiedene Sensoren.

Wenn mal jemand einen Ultraschall Sensor mit RS485-Schnittstelle findet, dann geben Sie mir doch bitte Bescheid, ehe ich mit mal einen mit einem ATTiny85 selbst baue.

Modbus und PRTG

Eigentlich wäre "JSON" und TCP viel schöne als MODBUS aber nicht alle Wechselrichter sind so kommunikativ wie ein Kostal 15. Einige Systeme sprechen halt nur MODBUS/TCP und die Daten sind auch für PRTG interessant. Manchmal muss man einfach Glück haben, dass Dirk Paessler selbst vor so einem Problem steht und auf seinem Blog schön beschrieben hat, wie er per ModBus/TCP einen Wechselrichter liest. Mittlerweile gibt es aber schon fertige Sensoren von PRTG zu ModbusTCP und Modbus Seriell.

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. Wenn man mit dem RasPI im Bereich Hausautomatisation unterwegs ist, dann wird man sehr schnell auf FHEM und entsprechende Adapter stoßen, um bestehende Komponentendort anzubinden. Aber auch die klassischen Haussteuerungen und Prozessteuerungssysteme sprechen mittlerweile TCP/IP und Webservices. Gerade wenn es um viele IO-Module geht, sind deren Komponenten interessant. So kostet eine KL1809-Klemme von Beckhoff mit 12 Digitaleingängen (24V) unter 100€ und die ist schon Hutschienentauglich und im Gehäuse und elektrisch ausgereift.

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