RS485 / ModBus / DMX
TeWenn 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.
- EIA-485
https://de.wikipedia.org/wiki/EIA-485 - Der RS-485 Bus
https://rn-wissen.de/wiki/index.php/RS485 - W&T: RS485-Bussysteme
https://www.wut.de/e-6wwww-11-apde-000.php - Der RS-485 Bus
https://rn-wissen.de/wiki/index.php/RS485 - Überblick RS422/RS485 Bus
https://expertdaq.com/de/faq/difference-between-rs422-and-rs485-bus/
RS422 belastet den Bus wir 3 RS485 Geräte und es darf nur einen Sender geben. - RS-485 basics: When termination is
necessary, and how to do it properly
https://e2e.ti.com/blogs_/b/analogwire/archive/2016/07/28/rs-485-basics-when-termination-is-necessary-and-how-to-do-it-properly - Maxim Integrated: RS-485 Cable
Specification Guide
https://www.maximintegrated.com/en/design/technical-documents/tutorials/7/763.html
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
-
https://modbus.org/
Homepage der Organisation
Specs: https://modbus.org/specs.php
https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf - ModBus
https://de.wikipedia.org/wiki/Modbus - FHEM: Modbus
https://wiki.fhem.de/wiki/Modbus - Modbus over serial
http://www.modbus.org/docs/Modbus_over_serial_line_V1.pdf - Modbus
https://www.mikrocontroller.net/articles/Modbus - Modbus RTU
https://expertdaq.com/de/faq/modbus-rtu/ - Modbus (RS-485) Using Arduino
https://create.arduino.cc/projecthub/maurizfa-13216008-arthur-jogy-13216037-agha-maretha-13216095/modbus-rs-485-using-arduino-c055b5 - Ziehl: Modbus Protokoll Beschreibung
https://www.ziehl.com/de/produkte/dl/Modbus_Betriebsanleitung-873/?task=download
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.
- DMX Busylight
- DMX (Lichttechnik)
https://de.wikipedia.org/wiki/DMX_(Lichttechnik) - USITT DMX 512/1990
http://www.soundlight.de/techtips/dmx512/dmx512.htm - RS485 DMX512 Controller - [Teil 1]
https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/rs485-dmx512-controller-teil-1 - Steuersignale der Lichttechnik
https://wiki.production-partner.de/licht/steuersignale-der-lichttechnik/ - DMX Explained; DMX512 and RS-485
Protocol Detail for Lighting Applications
https://www.element14.com/community/groups/open-source-hardware/blog/2017/08/24/dmx-explained-dmx512-and-rs-485-protocol-detail-for-lighting-applications - DMX Library
http://www.mathertel.de/Arduino/DMXSerial.aspx
https://www.arduino.cc/reference/en/libraries/dmxserial/
https://playground.arduino.cc/Learning/DMXSerial/ - Ethernet zu DMX
Es gibt mehrere Selbstbauprojekte einer LAN/WLAN-Kopplung, da DMX ja nicht "schwer" ist und 512Bytes eines UDP-Pakets auf einen seriellen Port zu senden
AVR ArtNet Node Bausatz https://shop.ulrichradig.de/Module/Light-Control-DMX/AVR-ArtNet-Node-Bausatz.html
Ethernet/UDP mit DMX zu sprechen. https://shop.codm.de/automation/dmx/8/ethernet-dmx-bridge-v0.4 - DMX Test-Sender
https://www.elektronik-labor.de/AVR/T13contest/DMX.html - https://www.dmx4all.de/
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.
- ATTiny85
- ATtiny
https://elektro.turanis.de/html/prj252/index.html - TINNYMODBUS
https://circuitmaker.com/Projects/Details/Cristian-Balint/TinnyModbus
ATTiny spricht "MODBUS" auf RS485 um SPI/I2C/PWM/Digital-Eingänge bereitzustellen
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 |
- M5Stack: RS485-Module
https://m5stack.com/search?type=product&q=rs485
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.
- CAN Bus
https://www.kfztech.de/kfztechnik/elo/can/can_grundlagen_1.htm - CANBUS
https://www.mikrocontroller.net/attachment/6819/canbus.pdf
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.
- Using an ESP8266 to Control Mains Sockets Using 433mhz Transmitter and Receiver
https://www.instructables.com/Using-an-ESP8266-to-Control-Mains-Sockets-Using-43/ - 433MHz Funksignale entschlüsseln und anwenden
https://forum-raspberrypi.de/forum/thread/33819-433mhz-funksignale-entschluesseln-und-anwenden-teil-1/
https://forum-raspberrypi.de/forum/thread/33842-433mhz-funksignale-entschluesseln-und-anwenden-teil-2/
https://community.openhab.org/t/tutorial-rtl-433-brings-433mhz-sensors-to-openhab/81018
https://github.com/merbanan/rtl_433 und https://triq.org/
https://www.instructables.com/Using-an-ESP8266-to-Control-Mains-Sockets-Using-43/
- TFA Dostmann "weather direct light wireless device"
TFA Dostmann Thermo-Hygro-Sender mit Display, 30.3180.IT, für TFA Klimalogg Pro
https://alexbloggt.com/funkthermometer-sdr/ - DEBO 433 RX/TX Entwicklerboards - 433
MHz RX/TX Modul (2€)
https://www.reichelt.de/de/de/entwicklerboards-433-mhz-rx-tx-modul-debo-433-rx-tx-p224219.html - 433 MHz Funk mit dem Arduino
https://wolles-elektronikkiste.de/433-mhz-funk-mit-dem-arduino - Funk – RF433 (433MHz)
https://beelogger.de/solar_und_universal/funk_easyplug/master/funk-rf433-433mhz/
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
- KNX-Standard
https://de.wikipedia.org/wiki/KNX-Standard - LCN
https://www.lcn.eu/ - HausBus
http://www.haus-bus.de/ - Übersicht verschiedener Bus-Systeme
https://www.mikrocontroller.net/articles/Hausbus
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:
- KQ-130F power line carrier modul
https://de.aliexpress.com/item/32826213893.html
https://ninagalkina.blogspot.com/2019/02/kq-130f-power-line-carrier-module.html
https://www.arduiner.com/en/prodotto/kq130f-power-line-carrier-module/ - TDA5051
https://www.nxp.com/docs/en/data-sheet/TDA5051A.pdf
Sign up DudeYarvie / JARViE_Home_Automation_Modem
https://github.com/DudeYarvie/JARViE_Home_Automation_Modem
https://www.youtube.com/watch?v=ITzsOVux5es&feature=youtu.be
https://www.youtube.com/watch?v=mUbpu3sr3Cc
https://github.com/DudeYarvie/JARViE_Home_Automation_Modem - Powerline Communications Modem Highspeed
PLC-UART-HS
https://www.sparkfun.com/products/retired/9359 - Send simple signal over AC power line
for Arduino / ESP8266
https://electronics.stackexchange.com/questions/292852/send-simple-signal-over-ac-power-line-for-arduino-esp8266
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
- I2C-Bus
- 1-Wire Bus
- EN-485
https://de.wikipedia.org/wiki/EIA-485 - SN65176B MAX485 Wandler IC (0,40€)
https://www.reichelt.de/rs485-422-1-treiber-1-empfaenger-dip-8-sn-75176bp-p19202.html - MAX485 Module TTL Switch Schalter to
RS-485 Module RS485 5V Modul
https://eckstein-shop.de/MAX485-Module-TTL-Switch-Schalter-to-RS-485-Module-RS485-5V-Modul - TINNYMODBUS (ModBus tiny multi-sensor
module)
https://github.com/cbalint13/tinnymodbus - RS485 Serial Communication Between
Arduino Mega and Arduino Nano With Visuino
https://www.instructables.com/RS485-Serial-Communication-Between-Arduino-Mega-an/ - ATtiny LED Control using RS485 protocol
from PC
https://www.xanthium.in/cross-platform-attiny-2313a-rs485-communication-with-pc-led-control-csharp-dot-net - Modbus (RS-485) Using Arduino
https://create.arduino.cc/projecthub/maurizfa-13216008-arthur-jogy-13216037-agha-maretha-13216095/modbus-rs-485-using-arduino-c055b5 - Vellemann Bausatz K8062 :Bausatz:
DMX-Schnittstelle über USB
https://www.reichelt.de/?ARTICLE=119288 - Modbus (RS-485) Using Arduino
https://create.arduino.cc/projecthub/maurizfa-13216008-arthur-jogy-13216037-agha-maretha-13216095/modbus-rs-485-using-arduino-c055b5 - Arduino / ESP8266 RS485 MODBUS
Anemometer
https://www.hackster.io/philippedc/arduino-esp8266-rs485-modbus-anemometer-45f1d8 - RS-485 Modbus IoT Gateway using ESP8266
NodeMCU ESP-12E
Part 1 of 3 :https://cmheong.blogspot.com/2018/07/rs-485-modbus-iot-gateway-using-esp8266.html