Neue Versionen und Support zum Modbus-Modul

Begonnen von StefanStrobel, 20 August 2017, 12:11:08

Vorheriges Thema - Nächstes Thema

thomasg

Moin.

Sagt mal ich überlege mir einen Sungrow Stringwechselrichter zu kaufen SG15RT ... Der hat glaube nur Lananschluss über das winet dongel. Wisst Ihr zufällig ob die Modbus Anbindung stabil läuft? Würde den gerne über fhem ansteuern .. auslesen und ggf. auch künftig die Signale von der Steuerbox weiterleiten. Also bspw. Ausgangsleistung auf 50% reduzieren etc.

Ich würde auch gerne die zählerdaten meines ir Lesekopfs per Modbus an den Wechselrichter weiterleiten sodass ich kein zusätzliches smartmeter installieren muss. Geht das?

Lieben dank
Fhem + knx + 1wire auf raspi 2

tobmaster1985

Modbus TCP über den WiNet-S läuft stabil, aber der liefert nicht alle Register, die der Wechselrichter hat.

Die SGxxRT sind doch reine PV-Wechselrichter, ohne Batterie. Afaik hat der gar kein Messgerät nötig, was die Momentanleistung ermittelt.

Unabhängig davon, müsste es theoretisch mit dem Modbus Modul im Slave-Modus möglich sein ein Smartmeter zu simulieren, wenn der EVU Zähler die passenden Werte liefert.

Mein SH10RT fragt zwar nicht viele Werte vom DTSU666 ab, aber das sind schon mehr, als mein kastrierter Logarex Zähler über die optische Schnittstelle liefert.

thomasg

Danke Dir für die Info.  Da hast Du recht, dass der Stringwechselrichter kein Hybrid ist und keine Batterie hat - dafür auch keine Zählerinfos notwendig sind.

Ich dachte nur, ich brauche da zumindest eine Lösung, wenn nach dem neuen Solarspitzengesetz irgendwann mal vom Netzbetreiber die Anlagen von der Ferne runtergeregelt werden. Da brauche ich dann "nur" die Möglichkeit ihm über Modbus zu sagen, bitte nur bspw. 10 kwp. maximal ins netz einspeisen. ich habe verstanden, das kann ich ihm per fhem und modbus irgendwie mitteilen, richtig?

gleichzeitig möchte ich einen kleinen parallel gekoppelten ac gespeisten batteriespeicher (marstek venus c 5kwh bspw) betreiben.dem kann ich dann die zählerdaten per mqtt mitteilen - das habe ich an anderer stelle schon gelesen.

Schöne Grüße
Fhem + knx + 1wire auf raspi 2

Prof. Dr. Peter Henning

Zur Klarstellung:

1. Auch Hybridwechselrichter sind String-Wechselrichter. Strings sind nämlich die gruppenweise in Reihe geschalteten Solarmodule, jeder String wird von einem eigenen Maximum Power Point (MPP) Tracker überwacht und sein Strom so gesteuert, dass die maximale Leistung entnommen wird. Beispielsweise fasst man jeweils Gruppen gleich ausgerichteter Module zu einem String zusammen.

2. Ins Netz werden nicht "x kwp" eingespeist. Erstens heißt es kW, und zweitens bezeichnet das "p" die (theoretische) maximale Leistung der Gesamtheit Solarmodule (ggf. in einem String). Eine Abregelung beeinflusst die internen MPP-Tracker, und nicht die Spitzenleistung von x kWp.

3. Warum um Himmels Willen sollte man einen AC-gekoppelten Speicher installieren, wenn man sowieso einen neuen Wechselrichter kauft? Ein solcher AC-gekoppelter Speicher hat wieder einen eigenen Gleich- und Wechselrichter, die Umwandlungsverluste sind also doppelt so groß wie bei einem DC-gekoppelten Speicher.

LG

pah


tobmaster1985

Ein weiterer Nachteil der AC-Kopplung: bei Netzausfall ist dann auch alles aus.

Die SHxxRT laden auch bei Netzausfall den Akku aus den PV Strings.

Aber hier geht's ja eigentlich um Modbus Modul.
Fragen zu den Sungrow WR sind dort vielleicht besser aufgehoben: https://forum.fhem.de/index.php?topic=115597

thomasg

#1340
Zitat von: Prof. Dr. Peter Henning am 08 Juni 2025, 10:39:263. Warum um Himmels Willen sollte man einen AC-gekoppelten Speicher installieren, wenn man sowieso einen neuen Wechselrichter kauft?

Da ich keine notstrom/usv Funktion benötige und ich einen recht geringen Nachtstrombedarf habe, den ich mir einem Akku überbrücken möchte hatte ich diesen Gedanken. Vorteile aus meiner Sicht:

- Wechselrichter deutlich günstiger (SG15RT derzeit ca 500 Euro)
- deutlich geringerer Standby-Stromverbrauch des Wechselrichters
- standalone AC Akku 5 kWh für ca 1200 Euro ebenfalls recht günstig
- im Winter kann die standalone Batterie einfach vom Netz genommen werden, um unnötige Standbyverluste zu reduzieren

Natürlich hast du mit den Umwandlungsverlusten Recht.

Fhem + knx + 1wire auf raspi 2

StefanStrobel

Hallo zusammen,

ich habe mal wieder Zeit gehabt, das Modbus-Modul zu erweitern. So gibt es nun mit setGroup die Möglichkeit mehrere Register bei einem set-Befehl gleichzeitig zu schreiben. Die umfangreichste Änderung ist aber eine neue alternative Syntax für die Objekte. Statt jeden Parameter in einem eigenen Attribut zu setzen, kann man nun Attribute wie obj-h100 verwenden und dann als Wert den Namen des Readings sowie eine kommagetrennte Liste der Parameter setzen.
Beispiel:
attr master obj-h100 Temp_Wasser_Ein, type=signed short tenth
Für Parameter, deren Werte ein Komma enthalten, klappt das natürlich nicht. Die kann man wie bisher als eigene Attribute schreiben.
Beispiel:
attr master obj-h770 Temp_Soll, type=signed short tenth, max=32, min=10, set=1
attr master obj-h770-hint 8,10,20,25,28,29,30,30.5,31,31.5,32

das geht auch für dev-Attribute und Typ-Definitionen:
attr master dev-type-VT_R4 format=%.1f, len=2, revRegs=1, unpack=f>
attr master dev-h combine=5, defLen=2, defPoll=1, defRevRegs=1, write=16

zum Testen ein der neue set-Befehl upgradeAttributes nützlich:
 this puts the attributes in the new compact format introduced 2025 and also tries to apply types to objects instead of repeated unpack, len and similar attributes.
 This feature is still experimental. Use only if you have backed up your configuration.         

Das ganze ist noch als Beta zu betrachten. Bitte sichert also Eure Konfiguration vor dem Testen.
Das Modul benötigt auch die aktuellen HTTPMOD-Utils (utils.pm in lib\FHEM\HTTPMOD). Die werden schon per update verteilt.

Gruss
   Stefan

StefanStrobel

Zitat von: Tomk am 06 April 2025, 10:02:57Hallo zusammen,
ich versuche function code 16 mit ModbusAttr im Master Mode zu nutzen. Ich werde aus der Beschreibung nicht ganz schlau...

Wenn ich "dev-h-write 16" nutze wird doch wahrscheinlich immer FC16 zur Abfrage aller Holdings genutzt, oder? Ich habe allerdings auch Holding mit fc6 welche ich abfrage. Kann ich fc 16 auch für die Abfrage spezieller Holding Register nutzen?

"Some slave devices might need function code 16 for writing holding registers. In this case dev-h-write can be set to 16.
Example: attr MBTest dev-h-write 16"

Falls die Frage noch offen ist:
Man unterscheidet bei Modbus Lesen und Schreiben sowie 4 verschiedene Objekt-Typen. Function code 3 liest Holding-Register, Function Code 6 schreibt ein einzelnes Holding-Register und Function Code 16 schreibt ein und mehrere Holding-Register.
Das Modbus-Modul berücksichtigt das. Zum Lesen kann nie 6 oder 16 verwendet werden und zum Schreiben nie 3.
Beim Schreiben eines einzelnen Holding-Registers hat man aber die Wahl. Das geht sowohl mit 6 als auch mit 16, aber manche Geräte wollen generell 16.

Gruß
  Stefan


Tomk

Danke Stefan, erstmal vielen Dank für die Überarbeitung. Ich werde es die nächsten Tage mal testen.

Mein Problem bleibt wahrscheinlich zum Teil bestehen, da bei meinem Wechselrichter Fc6 und fc16 parallel mit gleichen Registeradressen genutzt werden. Ich habe gesehen, dass das Modbus Modul abhängig von der Anzahl der Bytes automatisch zwischen fc6 und 16 wechselt. Das heisst manche Adressen können nur für fc 6 oder 16 definiert werden, richtig? Ist aber nicht so dramatisch, da ich auf einige Werte verzichten kann.

StefanStrobel

Hallo Tomk,

nicht die Adresse ist entscheidend, sondern die Anzahl Register.
FC6 schreibt genau ein Holding-Register. FC16 schreibt ein oder mehrere Holding-Register.

Gruss
   Stefan

Tomk

Hallo Stefan,

was mich bei der Beschreibung meines WR irritiert ist das für FC6 anderer Registerinhalt definiert ist als für FC16 (0x10).
siehe hier: Protokoll

Auf Seite 50 ist von "Write Single register" und dem FC6 die Rede und auf Seite 66 von FC16 (0x10). Beide Register fangen mit 0x0 an und haben unterschiedlichen Inhalt: FC6 - 0x0 --> "Unlock PW"  und FC16 0x0 --> "RTC-Seconds".

Vielleicht hat man sich auch nicht an den Modbus Standard gehalten, aber derzeit sehe ich keine Möglichkeit in diesem Modul selbst zu wählen oder die holding objects unterschiedlich zu definieren, richtig?

Tomk

Zitat von: StefanStrobel am 14 Juni 2025, 17:56:11...
Das ganze ist noch als Beta zu betrachten. Bitte sichert also Eure Konfiguration vor dem Testen.
Das Modul benötigt auch die aktuellen HTTPMOD-Utils (utils.pm in lib\FHEM\HTTPMOD). Die werden schon per update verteilt.

Gruss
  Stefan

Besten Dank nochmal für deine Bemühungen!

Ich habe es geschafft mal mit dem Test zu beginnen:
- sieht so aus als läuft erstmal alles wie zuvor
- beim Versuch eine "setGroup" zu Bilden scheint das Modul die Readings vorzubefüllen. Hierzu werden vermutlich die Register einzeln von FC6 abgefragt, kann das sein?
- Somit kommt es in meinem Fall zu falschen Werten für das Schreiben mit FC16 (siehe meinen vorigen Post). Ist aber nur eine Vermutung
- im folgenden die Fehlermeldung "set value is not numeric and textArg not specified for h130 in FormatSetVal" kommt. h130 ist scheinbar leer
- Warum werden in der "CreateSetGroupHash" andere holdings (h0,28,29,36...) abgefragt als die die ich für die Set group angegeben (
    Line 8: attr Qcells obj-h124-setGroup 1
    Line 12: attr Qcells obj-h125-setGroup 1
    Line 16: attr Qcells obj-h126-setGroup 1
    Line 20: attr Qcells obj-h128-setGroup 1
    Line 23: attr Qcells obj-h130-setGroup 1
    Line 27: attr Qcells obj-h136-setGroup 1
) habe? Siehe log unten...

2025.06.19 08:09:56 4: Qcells: set called with RC_ModbusPowerControl (h124) setVal = 0
....
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash called for h124 len 1 RC_ModbusPowerControl, group 1
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h0 len 1 QC_UnlockPw
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h28 len 1 QC_System_on_off
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h29 len 1 QC_dont-use
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h36 len 1 QC_BatMaxChargeCurrent_Write
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h97 len 1 QC_WriteSelfUseMinBatSoC
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h124 len 1 RC_ModbusPowerControl
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash try to add h124 len 1 RC_ModbusPowerControl to setGroup 1
2025.06.19 08:09:56 5: Qcells: formatSetVal rawVal is 0
2025.06.19 08:09:56 5: Qcells: formatSetVal packed hex 30 with n to hex 0000
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash packed value + 0000
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h125 len 1 RC_TargetSetType
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash try to add h125 len 1 RC_TargetSetType to setGroup 1
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash gap from 124 is 0
2025.06.19 08:09:56 5: Qcells: formatSetVal rawVal is 33
2025.06.19 08:09:56 5: Qcells: formatSetVal packed hex 3333 with n to hex 0021
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash packed value 0000 + 0021
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h126 len 2 RC_ActivePower
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash try to add h126 len 2 RC_ActivePower to setGroup 1
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash gap from 124 is 0
2025.06.19 08:09:56 5: Qcells: formatSetVal rawVal is 0
2025.06.19 08:09:56 5: Qcells: formatSetVal packed hex 30 with n to hex 0000
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash packed value 00000021 + 0000
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h128 len 2 RC_ReactivePower
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash try to add h128 len 2 RC_ReactivePower to setGroup 1
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash gap from 124 is 2
2025.06.19 08:09:56 5: Qcells: formatSetVal rawVal is 1
2025.06.19 08:09:56 5: Qcells: formatSetVal packed hex 31 with n to hex 0001
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash packed value 0000002100000000 + 0001
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash check h130 len 1 RC_TimeOfDuration
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash try to add h130 len 1 RC_TimeOfDuration to setGroup 1
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash gap from 124 is 2
2025.06.19 08:09:56 3: Qcells: set value is not numeric and textArg not specified for h130 in FormatSetVal
2025.06.19 08:09:56 5: Qcells: CreateSetGroupHash got error from FormatSetVal and returns
2025.06.19 08:09:56 5: Qcells: formatSetVal rawVal is 0
2025.06.19 08:09:56 5: Qcells: formatSetVal packed hex 30 with n to hex 0000
2025.06.19 08:09:56 4: Qcells: DoRequest called from SetLDFn created new request, read buffer empty, request: id 1, write fc 6 h124, len 1, value 0000, master device Qcells, reading RC_ModbusPowerControl (set RC_ModbusPowerControl)

StefanStrobel

Halo Tomk,

Meldungen mit Level 5 sind Debug-Meldungen. In dem Fall siehst Du dass das Modul eine Schleife über alle definierten Register macht um zu sehen, ob sie zur Gruppe gehören. Also alles in Ordnung. Ab h124 gehören die Register dann zur Gruppe. Modbus-Requests werden hier noch keine erzeugt.
Um den Schreib-Request für 124-136 dann gemeinsam durchzuführen, müssen für die Register auch Werte existieren. Die kommen aus dem bisherigen Wert der zugehörigen Readings. Die solltest Du also vorher auf sinnvolle Werte setzen, wenn die Objekte später zusammen geschrieben werden sollen.

Aber warum möchtest Du überhaupt die Register 124 bis 136 gemeinsam schreiben?

Zum Thema FC6 vs FC16:
nachdem ich die verlinkte Doku angesehen habe, verstehe ich Dein Problem. In diesem Fall kannst Du overrideFCWrite auch je Objekt festlegen, ob fc16 oder fc6 verwendet werden soll.
Das hilft aber nichts wenn Du z.B. Holding-Register 0 in zwei verschiedenen Interpretationen einmal mit FC6 und ein anderes mal mit FC16 beschreiben möchtest - da hat der Hersteller meiner Meinung nach Mist gebaut. Ein Holding-Register mit einer bestimmten Nummer sollte nicht verschiedene Bedeutungen haben, je nachdem ob es mit 6 oder 16 beschrieben oder mit 3 gelesen wird...
Dann bleibt eigentlich nur den Zugriff auf das Modul in mehrere Fhem-Devices aufzuteilen. In einem definierst Du dann die Objekte so wie sie mit FC6 zu beschreiben sind und im anderem so wie sie mit FC16 interpretiert werden. Wenn Du per Modbus-TCP darauf zugreifst, sollte das kein Problem sein.
Vielleicht brauchst Du aber auch nicht alle Holding-Register und kommst mit einem Fhem-Device aus.

Gruss
   Stefan