LBS: Schreiben von Registern mittels Modbus TCP

[SvenB]

V1.3 ist raus. Gleichzeitig war V1.2 nie richtig im DL-Bereich.
Änderungen V1.3: Gira hat irgendwann in meinen Augen eher heimlich die Schnittstellenbeschreibung von HS3 auf 4 umgestellt. Ich dachte erst, dass es nur ein Naming wäre, aber dabei verbessert sich auch die Baustein-Initialisierung wie es scheint. Da ich meine ganze Entwicklung umgestellt habe hier auch direkt die v1.3 hinterher.

[BadSmiley]

Victron Cerbo das Laden verbieten, ist auch mega mit Svens Baustein:
grafik.png

[SvenB]

Falls jemand einen Wechselrichter Solax X3 Gen 4 überreden möchte den Akku in der Nacht zu laden:

1. Wechselrichter in der Nacht wecken mit 1 und nach wenigen Sekunden 0 auf Register 154 (Sonst läd er in der Nacht nicht den Akku!)
2. Passwort eingeben: Auf Register 0 wird 2014 geschrieben
3. Verbrauchs-Modus setzen mit 3 auf Register 31
4. Charge mode auf Force Charge (1 auf Register 32)

Es gibt dabei mehrere Anleitungen. Manche enthalten ganz hinten die zu schreibenden Register wie https://gbc-solino.cz/wp-content/upl...ic-version.pdf

Und der Solax spricht nur Modbus RTU. Eine Umsetzung von RTU auf TCP braucht ihr noch eine Schnittstelle.
Zu beachten außerdem, dass Solax intern wohl teilweise auf EEPROMs setzt und mir jedem Schreibvorgang dieser altert. Daher vor dem Schreiben noch einen SBC setzen.

Alles ohne Gewähr und eigene Verantwortung. Eine Anmerkung noch: Man sollte sich bei dynamischen Stromtarifen nachrechnen, ob es sich lohnt. Oft muss der Verbrauchs-Strompreis >15ct über dem Ladepreis liegen und das durchgehend. Ist nur selten der Fall.

Solax X3 Gen4.png

[Wallyfan]

Kann mir jemand sagen, wo ich den Baustein herunterladen kann?

[BadSmiley]

Im 1. Beitrag.

[SeWa]

Hallo Sven,

danke für deine Bausteine.
Habe mit Fronius Wechselrichtern auch Überschussladung mit einer go-E Wallbox realisiert.

Bei Fronius ist der Offset der register (-1) welchen ich auch beim Reader eingestellt habe.
Somit kann ich die Register 1:1 aus der Liste verwenden.

Ich wollte den Writer genauso verwenden, leider existiert der Konnector
"10 Zahl 0 Offset, bewegt alle Register in eine oder andere Richtung. In der Regel 0, gern aber auch -1"
nicht....
habe Stunden damit verbracht meinen Fehler (-1) zu finden... 🤦♂️

wäre es möglich beim Writer Baustein auch diesen Konnector einzuführen?

Vielen lieben Dank
Walter

[SvenB]

Also du möchtest einen Eingang für den Offset, wie beim Lese-Baustein?
Ja, kann ich mal machen. Frage ist nur wann. Ich code grad nicht für den HS und verwende die Modbus-Bausteine von mir selber nicht. Daher ist die Motivation "gediegen".

Aufgeschrieben: https://github.com/SvenBunge/hs_modb...riter/issues/5

[MarkusM]

Hallo SvenB,

vorab wünsche ich ein frohes Neues! und Danke Dir für die Modbus-Bausteine!!

Irgendwo scheint bei mir ein Problem aufzutreten, vielleicht kannst du mir weiterhelfen. Oder jemand hatte schon ein ähnliches Problem.

Folgendes Szenario.

1. Modbus Teilnehmer Fronius Wechselrichter
2. Modbus Teilnehmer Heidelberg Energy Control über TCP<->RTU Adapter von Waveshare.

Beim Fronius lese ich mit deinem Baustein nur. Bei der Heidelberg Wallbox habe ich den Reader und Writer im Einsatz. Der Aufbau funktioniert sehr gut solange beide Teilnehmer erreichbar sind. Sobald die Wallbox aber in den Standby geht (per Modbus nicht mehr erreichbar), stellt auch der Reader vom Fronius seinen Dienst ein. Es hilft dann nur noch ein Neustart des HS, sobald die Wallbox wieder erreichbar ist.
Von einer parallel laufenden HomeAssistant Instanz lässt sich der Fronius immer problemlos über Modbus ansteuern.

Die Ideen die ich noch habe sind begrenzt. Ich hab beim Fronius Reader schon den ReconnectAfterEachRead getestet, leider ohne Erfolg.


Grüße
Markus

Hier der TCP Reader vom Fronius.

image.png

[SvenB]

Hey
muss mal in den Code gucken. Glaube aber beim debug schießt er den Baustein im Fehler Fall ab, weil es bessere Fehlermeldungen gibt. Ohne das lässt er ihn am Leben.
Ggf. Bezieht sich das auf alle Bausteine.
Debug in Betrieb auf 0 setzen. Nur auf 1 setzen wenn es Probleme gibt.

[MarkusM]

Servus. Ich mach es mal raus und teste. Meine aber dass ich Debug nur wegen des Problems aktiviert habe. Melde mich.

[MarkusM]

hat leider nichts gebracht den Debug herauszunehmen.
Es scheint so zu sein, dass sich der Fronius Baustein wieder fängt und erneut Werte liefert, sobald die Wallbox wieder aus dem Standby kommt (Auto wird z.B. eingesteckt). Sprich ein Neustart ist jetzt nicht mehr notwendig, aber das Ursprungsproblem ist leider noch da. Hast noch eine Idee was ich ändern könnte?

[MarkusM]

Hallo SvenB,

habe den Fehler vermutlich gefunden. Zumindest legen die zusätzlichen Log-Meldungen die ich reingemacht habe nahe, dass die Leseoperationen bei einem nicht angeschlossenen Teilnehmer pro Register ca. 2Minuten dauern. Der Baustein (Reader) hängt dann vermutlich hier (self.client.read_input_registers(register_addr, reg_fetch_size, unit=unit_id) fest und legt den HSL2.0 Thread lahm. Sofern ich die Abarbeitung der Logik richtig verstanden habe.

Ich schau jetzt mal ob es eine Möglichkeit gibt ein TimeOut zu setzen. Alles auf asynchrone Abarbeitung umzustellen ist mir als Python-Unerfahrener etwas zu viel Aufwand.

Grüße

[SvenB]

Timeout ist da ja schon.

self.client = ModbusTcpClient(ip_address, port, timeout=15, retry_on_empty=True, retry_on_invalid=True,

Das ist aber in meinen Augen das timeout zwischen Request und response. Was du brauchst ist das connect timeout von TCP beim Aufbau. Gute Frage, wie man das setzt. Könnte python global sein.

aber es er bei dir beim lesen hängt ist es komisch. Keep alive hattest du schon ausgeschaltet?

[MarkusM]

ich vermute das liegt an der Konstellation dass ein TCP<->RTU Umsetzer dazwischen hängt. Den Socket kann er öffnen weil dieser nur auf den Umsetzer geht und der werkelt ja munter vor sich hin, auch wenn der RS485-Slave weg ist. Die dahinterliegende RS485 RTU Verbindung ist aber durch den Standby der Wallbox nicht mehr aktiv. Deshalb kommt es es erst beim lesen zum Problem.

Hast Recht, der TimeOut ist vermutlich nicht der Richtige. Außer asynchron fällt mir dann keine andere Lösung ein.....

[SvenB]

Stimmt. Dein China-Unwetter. Kann der keinen Timeout?