ich baue zZ eine Nulleinspeisung mit dem Growatt MIC 600TL-X und Victron Komponenten (Laderegler, Pytes Batterie und Cerbo GX). Als Smart Meter dient eines von APSystems. Die Daten des Meters werden via HTTP request in NodeRed abgerufen.
Das Problem, vor dem ich nun stehe, ist die unzuverlässige Modbuskommunikation zwischen dem Cerbo und dem Growatt. Als Stick verwende ich den Victron eigene RS485 → USB Stick, inkl. Isolationsmodul. In NodeRED selbst benutze ich für die Modbuskommunikation den ‘node-red-contrib-modbus‘. Ich habe anfangs eine Pollrate von bis zu 400ms stabiel zum Laufen bekommen beim Abfragen von zwei Inputregistern. Nach einer Nacht habe ich am nächsten Morgen, nachdem der Wechselrichter über Nacht aus war, bei einer Pollrate von 4s ziemlich häufige Aussetzer und wenige Anfragen, die durch kommen. Der ShineWiFi-X Stick steckt derweilen noch am Gerät.
Vielleicht habt Ihr eine Idee, woran das liegen könnte, das ich anfangs hohe Pollraten stabiel laufen lassen konnte und nun nicht mehr?
Ich habe das Ganze mal mit qModMaster getestet und es lief hervorragend! Ich habe das Programm für 10min laufen lassen und bei 226 Anfragen gab es keinen Fehler.
In dem Cerbo steckt der RS485 Stick von Victron, da überall gesagt wird, ausschließlich diesen Stick zu verwenden, da andere Fabrikate womöglich Probleme verursachen könnten.
Nun kam es mir komisch vor, das die rotr LED des Sticks immer mal wieder heftig rot blinkte. Die Folge: Irgendetwas funkt in dem Datenverkehr meines NodeRED Flows rum.
Mittels ssh 192.168.xxx.xxx@root kam ich auf den Cerbo und konnte rausfinden, was da rumfeuert:
Das sind alles Dienste von Victron, die auf den RS485 Stick zugreifen und nach Modbusgeräten suchen. Kein Wunder, warum die Anfragen aus dem Flow nicht durchkommen. Also hab ich in der Datei “/etc/udev/rules.d/serial-starter.rules” die folgende Zeile auskommentiert:
