Strange Modbus errors with multiple devices on the bus #16049
Comments
|
Probier mal bitte z.B. 100ms delay. |
|
Schon mit meters:
- name: charger
type: template
template: eastron
usage: charge
modbus: rs485serial
id: 3
device: /dev/ttyUSB0
baudrate: 9600
comset: "8N1"
- name: wp1
type: custom
power:
source: modbus
id: 1
device: /dev/ttyUSB0
baudrate: 9600
comset: "8N1"
delay: 10ms
register:
address: 0x0c # Active power
type: input
decode: float32
energy:
source: modbus
id: 1
device: /dev/ttyUSB0
baudrate: 9600
comset: "8N1"
#delay: 10ms
register:
address: 0x48 # Import active energy
type: input
decode: float32
- name: wp2
type: custom
power:
source: modbus
id: 2
device: /dev/ttyUSB0
baudrate: 9600
comset: "8N1"
delay: 10ms
register:
address: 0x0c # Active power
type: input
decode: float32
energy:
source: modbus
id: 2
device: /dev/ttyUSB0
baudrate: 9600
comset: "8N1"
#delay: 10ms
register:
address: 0x48 # Import active energy
type: input
decode: float32 |
premultiply
added
bug
|
Ich kann auch diese Formel hier beim besten Willen nicht nachvollziehen: https://github.com/evcc-io/modbus/blob/980a0405c373b08e064517bc13ffa9eaa71391dd/rtuclient.go#L287-L300 Mal ganz davon abgesehen, dass man höchstens eine Mindestzeit berechnen kann bis der die Antwort sehr theoretisch vorliegen könnte, wird dabei völlig die unbekannte und vielleicht auch nicht konstante interne Verarbeitungszeit des Modbus-Geräts selbst ausser acht gelassen, die es braucht um die Antwort überhaupt lossenden zu können. Die theoretische Dauer eines Bits auf der Leitung ist |
Kann den Text auf dem Pad nicht raus kopieren. |
Schon klar und genau da steht etwas anderes als hier implementiert ist:
Insbesondere 2. dürfte hier zu den beobachteten Problemen führen, da hier derzeit direkt nach vollständigem Empfang der letzten Antwort sofort die nächste Anfrage auf den Bus getackert wird. Hier muss aber mindestens tChar*3.5 Ruhe sein. |
|
Huh! |
|
Das Characterdelay ist laut PDF zwischen den Characters. Warum fehlt da die Zeit des Zeichens selbst? Weil der Code es anders nutzt? Der PR sollte Upstream eröffnet werden. Wenn er dort nicht gemerged wird können wir das parallel auch tun. |
|
Nvm. Wird anders verwendet. |
|
Na weil das Zeichen selbst eben auch eine nicht vernachlässigbare Übertragungszeit hat. Ich würde hier aber vermuten, dass dieses ganze Delay zwischen senden und empfangen ohnehin völlig egal ist, denn das Slave-Device antwortet ohnehin wann es will. Ich würde daher vorschlagen noch das Zwischendelay entweder ganz zu entfernen oder zumindest auf die reine Char-Übertragungszeit + 2*t3.5 zu beschränken. Ferner würde ich das erstmal bei uns ausprobieren und dann ggf. erst Upstream mergen. Ok? |
|
Gerne lokal probieren. Dafür muss es nicht gemerged werden. |
Describe the bug
Ich möchte 3 Zähler an einem RS485-Bus betreiben. 1x SDM72DMv2 und 2x SDM120-Modbus.
Alle Zähler haben eigene, eindeutige Modbus-ID (1,2,3) und ansonsten selbstverständlich identliche Kommunikationsparameter 9600 8N1. Der Bus ist Spezifikationskonform aufgebaut und korrekt terminiert und funktioniert eigentlich auch einwandfrei - nur nicht mit evcc. Hier gibt es sehr häufig Datenfehler und Timeouts, speziell bei den beiden SDM120, die in der Konfig unterhalb des SDM72 aufgeführt sind. Insbesondere schlägt meist das Lesen des ersten Datensatzes (Power) fehl, während der zweite Datensatz deutlich weniger oft betroffen ist.
Steps to reproduce
Jeder Zähler einzeln kann problemlos und dauerhaft z.B. mit
evcc meter wp1 -rohne jegliche Fehler angesprochen werden.Lediglich die Verwendung im normalen Prozess oder wenn alle Meter zusammen abgefragt werden (
evcc meter) macht sehr häufig (aber nicht immer!) Probleme.Configuration details
Log details
What type of operating system are you running?
Linux
Nightly build
Version
evcc version 0.130.9
The text was updated successfully, but these errors were encountered: