Probleme mit Node Red + Modbus .... wie kann ich die Fehler loggen und auswerten ??

Hallo Cord, Frohe Weihnachten,

die ganzen Tests habe ich diesmal mit einem Node-Red Generator (flow) ausgeführt, damit man das mit Node-Red Kenntnissen besser nachvollziehen kann.

Meine Test mit Modbus RTU an die UVR 610 Modbus liefen bisher sehr erfolgreich, ohne Fehlermeldungen und ohne Abbrüche vom UVR610 über viele Wochen fehlerfrei durch.

Bin total begeistert über die Geschwindigkeit, Stabilität und Robustheit vom UVR610 RTU-Modbus.

Ich habe immer im Sekundentakt 10 verschiedene Werte von einem Zufallsgenerator erzeugt gleichzeitig mit 10 einzelnen Schreibfunktionen (fc-6) auf den Modbus geschrieben

und dann sofort wieder mit einer Multi-Register Abfrage-Lesefunktion (fc-3) ausgelesen.

Das UVR610-Programm hat die Modbus-Eingänge eingelesen und sofort wieder über eine Analog-Funktion an die Modbus-Ausgänge und an die CanBus-Ausgänge weitergegeben.

Ich bekam immer innerhalb einer Sekunde vom UVR610 RTU-Modbus die zehn Zufallszahlen-Werte fehlerfrei zurück, die ich gesendet hatte.

Ich habe mit meinem Batterie-Oszi (galvanisch entkoppelt) den MODBUS direkt angeschaut und die Pegel der einzelnen

Interfaces als auch von UVR610 anschauen und vergleichen können. Die Pegel waren alle ähnlich hoch, keine Ausreisser.

Dann habe ich alle Geschwindigkeiten bis hoch auf 115200 Baud getestet. Kein Problem und keine Signalverzerrungen.

Die 9600 Baud sind völlig ausreichend gewesen. Gleiches Ergebnis wie bei 115200 Baud.

Es gibt noch keinen Grund die Baudrate wegen der Datenmengen zu erhöhen.

Erst wenn ich unter einer Sekunde, im 0,5 oder 0,2 Sekundentakt gesendet habe, dann haben Werte in der Antwort gefehlt,

aber bei allen Busgeschwindigkeiten auch bei 115200 Baud haben dann Werte in der Antwort gefehlt.

Das hat also nichts mit der Busgeschwindigkeit zu tun.

Egal, ich wollte nur mal sehen, wie schnell man den UVR610 RTU-Modbus fehlerfrei abfragen kann.

Später habe ich eher mehr zufällig ähnliche Fehlermeldungen wie du geschrieben hast, auf dem RTU-Modbus produziert.

Node-Red kann man in unterschiedlichen Konstellationen installieren:

- native normal alleine als einziges smart-home-system

- als container einer docker-installation

- als subsystem von iobroker oder HomeAssistant

- virtuelle Maschine oder container in einer proxmox-Umgebung

usw.

Bei meinen Tests habe ich mehrere verschiedene interfaces (mehrere USB-RS485, Raspi-Aufsteckmodul, ESP32-Steckmodul) verwendet

auf dem gleichen RTU-Modbus an dem auch an einem Ende das UVR610-Gerät als Modbus-Slave hängt.

Bei einem Test mit zwei verschieden Node-Red installationen und gleichem flow, hatte ich tatsächlich eine

Kollision von zwei gleichen Sendern(master) die gepollt haben und sich dabei gestört haben produziert.

Dabei kamen ähnliche Fehlermeldungen wie bei dir zustande.

"Modbus Failure On State sending Get More About It By Logging"

Nachdem ich den zweiten Sender (RTU-Server) wieder abgeschaltet hatte, war das Problem sofort beseitigt.

Beim meinem Sender-Server, RTU-Server habe ich den Verbindungstyp RTU-Bufferd verwendet.

Kannst mal überprüfen ob es bei dir in den flows mehr als einen aktiven RTU-Sender gibt?

In den Server-Einstellungen wird immer eine Referenzanzahl angezeigt, wie oft das Objekt verwendet wird.

Wenn man die Anzahl der Sender und Empfänger mit den Schreib und Lese-Objekten abgleicht, könnte man so

auch ein mögliches Problem erkennen.

Bei zb. Geräteadresse 1.

Es darf anscheined immer nur ein RTU-Server(Master) pollen. Alle anderen müssen zuhören(Slave).

Ein paar Screen-Shots von deinen Node-Red Einstellungen (alles was mit RTU zu tun hat) wären auch nicht schlecht.

Bei Timing-Problemen kann man an einigen Stellschrauben drehen, aber dazu später mehr.

Gruß

Jürgen

Hallo Cord,

super, so wie es aussieht hast den Fehler gefunden.

Ich bekomme jetzt auch einen Absturz vom UVR610 fertig.

Hab einen Test gemacht mit dem Modbus-Eingang-11, dem ich z.B die Adresse 71 (grösser 64) zugeordnet habe.

Mit Tapps kann man das ganze kompilieren, das Programm läuft auch im UVR610.

Aber wenn ich über den Modbus einen Schreibbefehl mit Adresse 71 losschicke, dann macht das UVR610 sofort einen Reset und pfeift.

Das kann ich beliebig oft wiederholen.

Ein weiteres Problem ist, wenn ich eine Adresse von einem Modbus-Eingang in einem Schreibbefehl verwende,

der in Tapps noch undefiniert (noch nicht verwendet wurde) dann gibts auch Probleme und eine Fehlermeldung:

msg : error

"Error: Modbus exception 2: Illegal data address (register not supported by device)"

Bei meinen Experimenten hab ich immer den Modbus mit dem angeschlossenen Oszi überwacht.

Im Fehlerfall ist dann die Ausgabe am Modbus-Interface (/dev/ttyUSB0) einfach weggeblieben, es war plötzlich kein Signal mehr da.

Im Node-Red-Debug Monitor sind aber immer noch Modbus-Fehlermeldungen ausgegeben worden.

Nach Korrektur des Fehlers war die Ausgabe am Modbus-Interface (/dev/ttyUSB0) immer noch weg.

Erst nach Neustart von Node-Red kamen wieder Siganale auf dem Modbus.

Bei meinen bisherigen UVR610 Programmen habe ich intuitiv immer automatisch eine Adresszuordnung zum Modbus-Eingang/Ausgang 1:1 gemacht.

Mit 64 Ein- und Ausgängen hat man ja genügend Adressen. Wenn ich keine 1:1 Zuornung mache, dann muss ich zusätzlich auch noch eine Mapping-Liste pflegen.

Im Handbuch steht: "Die Adresse des Moduls wird automatisch vergeben und abhängig von der Eingangsnummer und des Typs hinaufgezählt."

Gruß

Jürgen

Hallo Cord,

den Testfall mit dem Modbus-Eingang-11, dem ich z.B die Adresse 71 (grösser 64) zugeordnet habe,

konnte ich auch mit einem python-script ausserhalb von Node-Red wiederholen.

Gleich nach starten des python-scripts macht das UVR610 sofort einen Reset und pfeift.

Das kann ich mit dem python-script beliebig oft wiederholen.

Also das Modbus-Adressproblem in UVR610 hat also nichts mit Node-Red zu tun.

schreiben (senden) an adresse 10, wert 9100 (Übertragung ok)

DEBUG:pymodbus.transaction:SEND: 0x1 0x6 0x0 0xa 0x23 0x8c 0xb1 0x5d
DEBUG:pymodbus.framer.rtu_framer:Changing state to IDLE - Last Frame End - 1703669783.841062, Current Time stamp - 1703669783.843529
DEBUG:pymodbus.framer.rtu_framer:Waiting for 3.5 char before next send - 4.01 ms
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
WARNING:pymodbus.client.sync:Cleanup recv buffer before send: 0xb 0x1a
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x1 0x83 0x80 0xa1 0x24
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
wert10
DEBUG:pymodbus.transaction:Current transaction state - TRANSACTION_COMPLETE
DEBUG:pymodbus.transaction:Running transaction 13
DEBUG:pymodbus.transaction:Clearing current Frame : - 0x1 0x83 0x80 0xa1 0x24
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x83 0x80 0xa1 0x24


schreiben (senden) an adresse 71, wert 9600 (Übertragung unvollständig, Modbus Error, UVR610 hat Reset gemacht)

                                           hex-47=dez 71
                                                hex-2580=dez-9600
DEBUG:pymodbus.transaction:SEND: 0x1 0x6 0x0 0x47 0x25 0x80 0x22 0xef
DEBUG:pymodbus.framer.rtu_framer:Changing state to IDLE - Last Frame End - 1703669783.883921, Current Time stamp - 1703669783.887592
DEBUG:pymodbus.framer.rtu_framer:Waiting for 3.5 char before next send - 4.01 ms
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
WARNING:pymodbus.client.sync:Cleanup recv buffer before send: 0x2c 0xeb 0xff
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] Incomplete message received, expected at least 2 bytes (0 received))

Das kannst bestimmt auch mit jedem Modbus-Master-Simulator durchführen wenn einen solchen Testfall aufbaust.

Wie schon gesagt, bei mir ist das bisher nicht aufgefallen, weil ich bei meinen UVR610 Programmen immer Adressen unterhalb 64 verwendet habe.

Beim programmieren mit Tapps ist mir schon aufgefallen, dass automatisch das Adressfeld mit einem Wert gefüllt war.

Den hatte ich aber so wie du auch überschrieben.

Wahrscheinlich bleibt der Automatismus der Adressvergabe beim Arbeiten mit Tapps im Adressbereich innerhalb der Grenze bis 64.

Gruß

Jürgen

Hallo Cord,

frohes neues Jahr, wie man bei uns sagt.

Zitat von Troedler77

...

Die Batterien sind per USB Kabel mit den Effekta Hybridwechselrichtern verbunden

Solarassistant.io liest alle Werte ein, sprich von den Wechselrichtern und auch der Batterien.

Diese werden auf der Solarassitantseite grafisch dargestellt und werden zusätzlich auch per MQTT Server zur Verfügung gestellt.

Auf einem zweiten Raspberry Pi läuft Homeassistant mit Node Red.

...

Alles anzeigen

Sind die Effekta Hybridwechselrichter über USB-RS232 an die Batterien angeschlossen?

Das wäre dann BMS-auslesen. Kein CAN-Anschluss von Batterien zu den Effekta Hybridwechselrichtern?

Über welches Daten-Protokoll kommen Daten von Effekta Hybridwechselrichtern zu Solarassistant? (MQTT, Modbus oder RS232?)

Solarassistant liest von Effekta Hybridwechselrichtern und Batterien Daten ein. Hast dann zweimal USB-RS232 an den Batterien angeschlossen?

Einmal USB-RS232 von Batterie zu den Effekta Hybridwechselrichtern und dann nochmal USB-RS232 von Batterie zu Solarassistant?

Kannst vielleicht das Umfeld von den Effekta Hybridwechselrichtern etwas beleuchten, damit mir das ganze etwas klarer wird und ich den danzen Datenfluss verstehen kann? (Fotos oder sonstige Bilder von den Anschlussverbindungen Hybridwechselrichter und Batterien)

Mich interessiern die Effekta Hybridwechselrichter und deren Konnektivitäten auf jedenfall, denn inzwischen gibt es einige Hybridwechselrichter,

aber die Internas stehen nicht ganz vollständig in den Handbüchern.

Gruß

Jürgen