Wie so häufig basiert eine Erklärung auf einer verständlichen Kommunikation oder ganz einfach einer verständlichen Sprache. Kommt es zu einem Transfer von Daten unterliegt dieser entsprechenden Schichten, beispielsweise OSI – Model. Üblicherweise passiert diese „Schichtung“ im typischen Rahmen eines Gateways oder mal ganz praktisch einem Router.
Reduziert man sich nun auf eine Datenumsetzung von RS485 auf beispielsweise WLan ist die Bezeichnung Gateway fragwürdig. Der Transfer reduziert sich hier auf Schicht 4 ganz gleich ob TCP (Transmission Control Protocol) oder UDP (User Datagram Protocol).
Hierzu addiert sich nun die Anwendungsschicht im OSI – Model Schicht 7. Hier werden typische Protokolle wie HTTP, SMTP, FTP, MQTT,… innerhalb des vorgenannten Layer 4 Transportschicht durchgereicht.
Dementsprechend reduzieren wir uns auf die Bezeichnung Bridge, zu Deutsch eine Brücke. Ganz praktisch – im Bezug unseres RS485 Tasmota Modbus Modul – es wird vom RS485 Level (von -7V bis +12V) auf UART Level (3,3V) umgesetzt. Eine höhere serielle Signalspannung wird auf eine niedrigere Signalspannung und umgekehrt umgesetzt. Das passiert gleichermassen wie bei einem RS485 USB Konverter, also RS485 Level auf 5V Level.
RS485 WLan Bridge im Detail
Basierend auf der oben beschriebenen Funktionsweise erfolgt dies alleinig durch Hardware. Wird ein RS485 Signal empfangen wird dieses auf UART Level reduziert und geht auf die serielle Schnittstelle des ESP8266 des EI-OT RS485 Moduls über.
Wie man nun weiß erscheinen die seriellen Daten nicht im Webinterface der Tasmota Firmware, sondern lediglich in der Konsole, – die übliche Form seriell zu kommunizieren -. Mittels entsprechender Syntax / Tasmota Befehlssatz kann man nun direkt über WLan – man nutzt also TCP / die Transportschicht in Kombination mit dem HTTP Protokoll (die Tasmota Benutzeroberfläche / Konsole) um Daten auf RS485 auszugeben bzw. zu empfangen -.
RS485 und Modbus
Wie bereits erwähnt bezeichnet RS485 eine Schnittstelle also Hardware, Modbus hingegen ist ein standardisiertes Protokoll welches unter anderen (auch RS232 und RS422) die RS485 Schnittstelle nutzt. Kommt nun Modbus zum Tragen wird man mit einem typischen seriellen Befehlssatz bestenfalls (meist nicht einmal das) einen Error als Antwort erhalten. Denn im Eigentlichen ist RS485 keine einfache serielle Schnittstelle sondern ein Bussystem. Mit einfachen Worten es können mehrere Teilnehmer über nur eine Schnittstelle kommunizieren. Dies können selbstredend unterschiedlichste Geräte sein, jedes mit individueller Funktion als auch Firmware und Protokoll zum einfachen Verständnis Befehlssätze.
Das Modbus Protokoll vereinfacht basierend auf einem einheitlichen Standard / Syntax die individuelle Kommunikation mit jedem Endgerät. Hierbei sollte man nun zwischen Modbus RTU (Master/Slave) und Modbus TCP (Client/Server) differenzieren. Im Bezug der Topologie sollte man stets beachten der Master im TCP Modbus ist stets der Client und der Slave ist der Server.
Zurück zum Tasmota EI-OT RS485 WLan Bridge Modul wird nun die jeweilig notwendige Konfiguration, basierend auf die Anwendung deutlich.
Denkbare Modbus Anwendungen sind
- Modbus TCP Server, man nutzt einen Modbus TCP Client um über WLan mit einem Endgerät oder mehreren Endgeräten zu kommunizieren – siehe Modbus TCP –
- direkte Modbus Kommunikation über die Tasmota Konsole, man nutzt den Tasmota Modbus Bridge Befehlssatz und kommuniziert über HTTP, bzw. nutzt Rules oder Script um beispielsweise auf MQTT zu transferieren
- direkte Modbus Protokoll Integration, beispielsweise durch Verwendung von Tasmota Skript / Tasmota Smart Meter Interface
- direkte TCP Bridge, die RS485 Daten werden unabhängig vom jeweiligen Protokoll, also 1:1 direkt über einen TCP Socket übertragen unter Verwendung der Tasmota Serial to TCP Bridge.
- direkte serielle Bridge, ist häufig ausreichend wenn String, Hex oder Binary übertragen werden sollen, beispielsweise mittels Tasmota Befehlssatz
Modbus Bridge im Vergleich zu TCP Bridge
Oftmals ist die Lösung viel einfacher als man zunächst dachte. Häufig ist der Ansatz eine kabelgebundene RS485 Anbindung durch eine kabellose WLan Verbindung zu ersetzen. Hierbei sollte man stets zwischen Protokoll und Transport differenzieren.
Als einfaches Beispiel, die vormals kabelgebundene Lösung basiert häufig auf einem Slave (Endgerät) und einem Master (PC) oft in Kombination mit einem RS485 USB Konverter und einer Software mit entsprechender Schnittstellen Infrastruktur.
Ersetzt man nun den RS485 USB TTL Konverter durch das Tasmota RS485 Modul ist es keineswegs notwendig die Daten / das Protokoll (Modbus) zu interpretieren. Es muss lediglich die Schnittstelle entsprechend definiert werden, im Bezug Modbus üblicherweise Port 502. Zur Erinnerung TCP ist der Transport Schicht / Layer, das heisst das Modbus Protokoll wird über TCP übertragen, ohne eine Veränderung des Datenpakets / Protokoll. Modbus nutzt den Transportlayer / TCP zur Übertragung der Datenpakete.
Hierzu darf allerdings die RS485 Schnittstelle / GPIO1 und GPIO3 nicht als Modbus-Bridge, sondern muß als TCP-Bridge konfiguriert werden.
Im Detail handelt es sich hierbei um eine Serial to TCP Bridge, das heisst die Konfiguration der Schnittstelle basiert auf dem typischen Befehlssatz serieller Schnittstellen.
Im Vergleich zur Serial to TCP wird bei der Tasmota Modbus Bridge das vorgenannte Modbus genutzt. Das heisst es erfolgt ein Request basierend auf dem Modbus Protokoll und das Endgerät antwortet basierend auf dem Request.
Hierzu wird die Tasmota Konsole mit entsprechendem Befehlssatz verwendet innerhalb der Tasmota Modbus Bridge verwendet. Mittels dem Befehl ModbusSend wird ein Request in Form eines JSON Object über die serielle Schnittstelle des ESP8266 auf den RS485 Konverter ausgegeben.
Das jeweilige Endgerät interpretiert den Modbus Request und antwortet mit einem entsprechendem Datenpaket über den RS485 Konverter über die serielle Schnittstelle des ESP8266. Die Konsole interpretiert das mittels ModbusReceived Datenpaket und gibt das Datenpaket als JSON Object in der Konsole aus.
Im Detail fungiert das EI-OT Tasmota RS485 Modul somit als Modbus „Master“ um Daten via Befehlszeile / Konsole zu senden und entsprechend zu empfangen. Möchte man nun die Daten anderweitig verwenden bedarf es entweder entsprechender Tasmota Rules oder die Verwendung von Tasmota Script.
Dementsprechend stehen folgende Tasmota Firmware Versionen zum Download bereit
RS485 Tasmota Firmware in Deutsch mit Tasmota Script Unterstützung
https://www.ei-ot.de/download/4134/?tmstv=1723019633
RS485 Tasmota Firmware english version with Tasmota Script Support
https://www.ei-ot.de/download/4133/?tmstv=1723018886
RS485 Tasmota Firmware in Deutsch mit Tasmota Rules Unterstützung
https://www.ei-ot.de/download/4130/?tmstv=1723018721
RS485 Tasmota Firmware english version with Tasmota Rules Support
https://www.ei-ot.de/download/4127/?tmstv=1723018749
Selbstredend ist auch die Umsetzung auf ein anderes Protokoll beispielsweise MQTT Telnet bzw. fixer Log Server mit entsprechendem Port, oder gar HTTP realisierbar.
Ein YouTube Video Tutorial zur EI-OT RS485 Modul Konfiguration
15 Comments
Jörg Nissen
Hallo,
ich setzte das Modul mit einem SDM72D ein. Ich bekomme auch Daten. Die Aktuellen Wert sind richtig. Allerdings wird mir bei den Total werten, ein anderen Wert als auf dem Zähler angezeigt.
Zähler zeigt 2.89 in Tasmota 0.029. Mir scheint hier wird irgentwie der Wert in in KWH umgerechnet. Kann ich hier irgentwo was einstellen ?
admin
Hi Jörg,
hm ich kratze mich da mal vorsichtig am Kopf 😉
Also ich vermute Du hast das nachfolgende Script für den SDM72D (MODBus) von der Tasmota Seite verwendet :
https://tasmota.github.io/docs/Smart-Meter-Interface/#sdm72d-modbus
>D
>B
->sensor53 r
>M 1
+1,25,mN1,0,9600,SDM72D,26,1,01040000,01040002,01040004,01040006,01040008,0104000a,0104000c,0104000e,01040010,01040012,01040014,01040016,01040018,0104001a,0104001c,0104001e,01040020,01040022,0104002a,0104002e,01040030,01040034,01040038,0104003c,0104003e,01040046,01040048,0104004A,01040156,01040158,0104018c,01040500,01040502
1,010404ffffffff@i0:1,Voltage P1,V,voltage_phase1,2
1,010404ffffffff@i1:1,Voltage P2,V,voltage_phase2,2
…..
weiter unten im Script ist
1,010404ffffffff@i26:1,Energy Imported,kWh,energy_imported,3
1,010404ffffffff@i27:1,Energy Exported,kWh,energy_exported,3
1,010404ffffffff@i28:1,Energy Total,kWh,energy_total,3
1,010404ffffffff@i29:1,Energy Reactive Total,kVArh,energy_reactive_total,3
1,010404ffffffff@i30:1,Net Energy,kWh,energy_net,3
das heisst es wird auf kWh umgerechnet
Ohne das ich jetzt tiefer in das Script eintauche wenn Du die obigen Zeilen durch
1,010404ffffffff@i26:1,Energy Imported,kWh,energy_imported,2
1,010404ffffffff@i27:1,Energy Exported,kWh,energy_exported,2
1,010404ffffffff@i28:1,Energy Total,kWh,energy_total,2
1,010404ffffffff@i29:1,Energy Reactive Total,kVArh,energy_reactive_total,2
1,010404ffffffff@i30:1,Net Energy,kWh,energy_net,2
könnte die Divison draussen sein, bin mir nicht sicher aber einen Versuch ist es wert
Grüße
Markus
Bernd Theis
Hallo,
ich habe mir das „Tasmota RS485 Modbus TCP MQTT WLan WiFi Bridge Modul 5-12V“ zugelegt und wollte damit meinen Goodwe Hybrid-WR abfragen, aber irgendwie bekomme ich keine Verbindung zustande.
Mein Verständnis:
1.) wenn ich das Modul auf „ModBr“ setze, dann könnte ich per Konsole oder einem passenden Script Daten auslesen und diese dann z.B. per MQTT senden.
2.) wenn ich das Modul auf „TCP“ setze, dann sollte sich das Modul transparent verhalten und ich könnte mit einem beliebigen Modbusmaster per TCP auf den WR zugreifen und Daten abholen.
Ich möchte die Anwendungsvariante 2.) verwenden. Dazu habe ich folgendes eingestellt:
– in der Confi habe ich „TCP“ eingestellt (ich nehme an das Vertauschen von RX und TX ist ein Versehen, oder? Funktioniert aber auch andersherum nicht.)
– Baudrate (9600) und Config (8N1) habe ich eingestellt und überprüft
– die Schnittstelle habe ich mit „TCPStart ,:502“ gestartet
==> TCP: Starting TCP server on port 502
==> TCP: Filtering 192.xxx.xxx.0 (was mich wundert ist die IP 192.xxx.xxx.0. Das Modul hat die IP 192.xxx.xxx.224?)
==> RSL: RESULT = {„TCPStart“:“Done“}
– mit „SerialSend 3d 03 89 1f 00 01“ versucht zu verbinden und Daten abzuholen
==> RESULT = {„SerialSend“:“Done“}, keine weiteren Ergebnisse oder Daten
Bei dem Versuch mich mit QModBus über TCP und Deinem Modul zu verbinden kommt auch nur eine Fehlermeldung
==> „Protocol error: Slave threw exception ‚No error‘ or function not implemented.
Mit einem Standard USB-Konverter und einem Terminalprogramm (QModBus) kann ich mich mit dem WR verbinden und ihn auslesen, bzw. auch Befehle senden.
Auch über Fhem mit dem Modul Modbusattr funktioniert es, mit Deinem Adapter bekomme ich aber leider keine Verbindung zustande.
Ich habe gerade keine Idee mehr woran es liegen könnte. Vielleicht verstehe ich aber auch etwas grundsätzliches falsch.
Wenn Jemand eine Idee hat woran es liegen könnte, dann immer her damit. Danke.
admin
Guten Morgen Bernd,
ähm ich bin leicht verwirrt 😉
zu 1. mit Script auslesen – ja insofern die Script Firmware auf dem ESP-01+ installiert wurde
zu 2. beliebigen Modbus Master leider liegt hier aus meiner Erfahrung der Hase im Pfeffer
… beispielsweise bei Homeassistant wird oft TCP Bridge ausgewählt, muss aber als rtuovertcp wie folgt konfiguriert werden
modbus:
– name: modbus_hub
type: rtuovertcp
host: IP_ADDRESS
port: 502
gegen die TCP Bridge und Schnittstelle / Baudrate (Befehl TCPBaudRate 9600) ist nichts einzuwenden
TCPStart 502 gibt zwar aus das TCP Socket gestartet wurde aber eine Socket Verbindung wurde nicht hergestellt,
hier würde ich zunächst einmal strikt auf den „Master“ WICHTIG zu beachten im Detail ist es ja umgekehrt das Modul ist der Master
verweisen also
TCPStart 502, IP Adresse des Client <-- also PC oder ? dann in der Konsole mal schauen was ausgegeben wird Zu SerialSend ... der Befehl müsste wie folgt lauten SerialSend5 3d 03 89 1f 00 01 da Hex übergeben wird siehe https://tasmota.github.io/docs/Commands/#serial-bridge
So bei QModbus bin ich auch schon raus aber die Richtung dürfte der Modbus Client sein
https://doc.qt.io/qt-6/qtserialbus-modbus-client-example.html
Connection type TCP
Port IPAdressedesModuls:502
Abschliessend bitte nicht falsch verstehen mir geht es letztlich nur um Fehlereingrenzung,
wurde bei dem Modul TCPStart ausgeführt und es wird done zurückgegeben
dann läuft das <-- habe da schon ein paar Jährchen Erfahrung, dann gilt es auf der "anderen Seite" Fehler einzugrenzen Grüße Markus
Bernd Theis
Hallo Markus,
vielen Dank für die schnelle Antwort, hatte ich Gestern leider nicht mitbekommen. Hab ich da wieder was übersehen oder gibt es keine eMail-Benachrichtigung bei neuen Kommentaren?
Das mit dem Client war der treffende Hinweis. Es funktioniert jetzt. Auch das RTU über TCP trifft evtl. zu. Ich kann im FHEM-Modul (modbusattr) auch “ RTU“ oder “ TCP“ angeben. Diese Unterscheidung war mir in FHEM auch schon aufgefallen, aber ich hatte nirgends einen Hinweis für den Zweck gefunden. Ich habe jetzt also gleich „RTU“ eingetragen.
Die Variante „Script“ hatte ich nur zum Verständnis erwähnt. Natürlich muß ich dafür eine Tasmota-Version mit eingeschalteter Scriptunterstützung haben. Ich verwende das an anderer Stelle auch schon (Stromzähler auslesen). Ich bin auch ein Fan von MQTT und das wäre durchaus auch ein Weg gewesen, aber ich habe bei meinem anderen direkt angeschlossenen Goodwe-WR schon alle notwendigen Register über das FHEM-Modul „modbusattr“ parametriert und wollte das nicht nochmal alles neu in ein Tasmota-Script umbauen.
Was mich verwirrt hat war, das man im Adapter die IP-Adresse des Ziels (in dem Fall mein RasPi auf dem FHEM läuft) angeben muß. Das bedeutet aber andererseits auch das ich nur mit diesem „Ziel/client“ kommunizieren kann, oder? Es ist also kein Modbus-Server sondern eine Punkt zu Punkt Verbindung? An dieser Stelle fehlen mir ein wenig die topologischen Zusammenhänge. Das ich SerialSend5 verwenden muß hatte ich mir schon gedacht und auch schon versucht, was aber wegen der falschen IP im tcpstart dann natürlich trotzdem nicht funktioniert hat.
Also wieder was gelernt und nochmals Vielen Dank.
Grüße
Bernd
admin
Guten Morgen Bernd,
an und für sich sollte eine Emailbenachrichtigung erfolgen, muß ich mal überprüfen.
Ja das mit der Konfiguration auf der Clientseite RTU/TCP ist so ein Thema,
die Erklärungen sind oft sehr weitläufig / lückenhaft, bzw. nicht wirklich praxisnah.
Oft wäre schon der Hinweis Differenzierung im Bezug Modbus RTU und TCP hilfreich:
sobald TCP im Spiel ist wechselt das Ganz will heissen
was bei RTU Master ist ist bei TCP Client
Wegen dem TCP Socket / Zielclient, das Ganze funktioniert auch ohne strikte IP Zuweisung, also nur
TCPStart 502
Aber bei der Ersteinrichtung ist die strikte Zuweisung hilfreich,
da man sofort in der Konsole eine entsprechende Info erhält <-- zumal oftmals Firewall, Router, Portfordwaring hier mit rein spielt. Nebenbei, nicht nur Du hast etwas gelernt obwohl FHEM sehr verbreitet hatte ich das im Bezug RS485 / Modbus noch nicht auf dem Tisch. VIELEN DANK für Dein Feeback Grüße Markus
Torsten
Hallo,
ich würde gerne mit dem Adapter meine Brauchwasser-Wärmepumpe über die Modbus-Schnittstelle auslesen. Diese unterstützt aber nur 8E1, 8O1 und 8N2 (jeweils 19k2 oder 9k6).
In allen Anleitungen die ich bisher gelesen habe steht aber dass Tasmota nur 8N1 unterstützt.
Ist das wirklich so?
Wäre schade wenn ich ihn umsonst bestelle.
VG
Torsten
admin
Guten Morgen Torsten,
definitiv ist die Aussage Tasmota unterstützt nur 8N1 falsch.
Die Schnittstellenparameter können ganz einfach über die Konsole gesetzt werden
hier die Beschreibung zum Befehlssatz
Im Grunde für EVEN
SerialConfig 8E1 über die Befehlszeile der Konsole eingeben unter ENTER Taste drücken
dann Baudrate 19200 oder 9600 über die Befehlszeile der Konsole eingeben unter ENTER Taste drücken
das wars auch schon
Da Du Modbus schreibst verwendest Du eventuell SML Script
hier wird im Script gleich zu beginn z.B.
>M 1
+1,3,mE1,0,9600,Device,1,1….
also m = modbus gefolgt von Schnittstellenparameter E = Even gesetzt.
VG
Markus
Torsten
Hallo Markus,
vielen Dank für die Antwort.
Zwischenzeitlich habe ich das Ganze jetzt erst mal über eine Modbus-TCP-Bridge auf einem alten Raspberry Pi (1 Mod. B) + RS485-Adapter mit ‚mbusd‘ realisiert. Funktioniert problemlos, ist aber etwas „overkill“.
Sobald ich etwas mehr Zeit habe werde ich mich mal mit SML-Script beschäftigen und dann wahrscheinlich auf den Tasmota-Adapter umrüsten.
Dafür muss aber (wie ich heute feststellen durfte) auch das Wlan im Keller noch etwas optimiert werden.
VG
Torsten
admin
Hallo Torsten,
hm Modbus-TCP-Bridge hört sich so an als sei da am „anderen Ende“ einen ? MQTT Broker … ???
Ja ein Rasp ist ein bisschen „overdressed“ für RS485 TCP Bridge,
nebenbei kannst Du ja einfach auch im Bezug des RS485 WLan Bridge Modul verwenden.
Grüße
Markus
Torsten
Hallo Markus,
nein, am anderen Ende hängt ein evcc auf einem Victron Cerbo-S. Dieser steuert die PV-Überschussladung des Wasserspeichers per Heizstab.
Da aber am Cerbo-S die USB-Ports scheinbar kaum für nicht im Venus-OS vorgesehene Geräte zu verwenden sind, konnte ich den RS485-USB-Adapter dort nicht direkt betreiben (für die Stromversorgung des Raspi reicht der USB-Port allerdings).
Sobald meine Zeit es hergibt und der WLAN-Empfang im Keller verbessert wurde, werde ich mich nochmal mit dem Thema befassen.
VG
Torsten
Torsten
PS: Die E-Mail-Benachrichtigung funktioniert scheinbar weiterhin nicht … jedenfalls habe ich keine bekommen.
admin
ich vermute mal das hing damit zusammen das meine Antwort vor dem Hinzufügen zur Mailinglist war, eingetragen bist Du auf alle Fälle
Torsten
… auch zu dieser Antwort gab es keine Info-Mail 😉
admin
Hallo Torsten,
da war ich mal wieder ein wenig verwirrt,
die Emailbenachrichtigung in der Kommentarfunktion haben wir deaktiviert (hatte da eine Beschwerde seitens eines Benutzers).
ABER einfach kurz im Forum schreiben, da ist die Benachrichtigung aktiviert.
Eine Registrierung für Kunden ist nicht notwendig,
zum Login einfach Email oder Benutzername, sowie Passwort des Kundenkontos verwenden.
Grüße
Markus