Solar EPEVER EPSOLAR u.ä. [98_ModbusEPEVER] [98_ModbusUPOWER] [98_ModbusIPOWER]

Begonnen von laserrichi, 09 Juni 2020, 20:05:50

Vorheriges Thema - Nächstes Thema

apath0

Danke für deine schnelle Antwort. Hast Du meinen Edit im letzten Post gelesen? Hat sich wohl zeitlich überschnitten ;) Es läuft jetzt jedenfalls!

laserrichi

Ok jetzt hab ich es gelesen :-)
Modul hab ich auch schon upgedated jetzt sollten die % nicht mehr durch 100 geteilt werden
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

apath0

Danke, SOC stimmt jetzt :) Sonst ist mir bisher noch nichts aufgefallen, was nicht funktioniert. Ich hab jetzt den restlichen Tag meine Grafana-Installation angepasst, falls es jemanden interessiert: https://hightower.129a.net.

Vielen Dank nochmal für die Entwicklung des Moduls *Daumen hoch*

Schönen Abend,
Sebi

thymjan

zum IPOWER Modul:
Den Inverter (hab den IP1000-12) kann man ja wohl nicht per Remote ein- und ausschalten.
Wenn der Netzschalter aus ist, ist damit keine ModBus Kommunikation möglich.
Nur für die Kommunikation möchte ich den Inverter aber auch nicht permanent laufen lassen.

Wäre es möglich, dass in diesem Fall (keine Modbus Kommunikation möglich) im konfigurierten Intervall vom Modul Null-Werte ausgegeben werden? (und der InverterState auf off gesetzt wird?)

Ich berechne durch Integration bestimmte Werte. Wenn vom Modul dann keine Werte mehr erzeugt werden, ist die Integration fehlerhaft.

laserrichi

ich wüsste jetzt nicht wie man das machen könnte.

Das einfachste ist wohl das ganze auf disable zu setzen
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

kurt6908

Modul ModbusUPHIPOWER.pm

Hallo laserrichi,

mein Epever UPower Hi Series wurde nun endlich geliefert. Der Inverter läuft erfolgreich.

Ich bin nun also ins Testen des ModbusUPHIPOWER.pm eingestiegen, bis jetzt läuft es ;=)

Kurze Konfig:

Raspi 3
USB-RS 485-Dongle mit CP2106-Chip
RS485A auf Pin7 Sub-D9-Stecker
RS485B auf Pin8 Sub-D9-Stecker

Modbus ist definiert mit:
@115200,8,N,1

ModbusUPHIPOWER mit:
10 600 RTU
(Achtung: Standard-ID ist 10, hatte zunächst 1 erfolglos getestet)

Ich werde mir die Werte mal genauer anschauen und berichten ;=)

Viele Grüße

Kurt

P.S.: Die oben gewünschte Doku der schaltbaren Einträge für den normalen UPower kann ich nicht mehr liefern, der ist bereits abgebaut ... sorry ...
3* Raspberry Pi (2 über LTE/VPN), 5* Cul, 3* FS20, 4* FHT, 6* HM, Somfy, Solarlog, WMBus/EnergyCam, AVM FritzBox, 3* AVM Powerline, Alexa, Tasmota/MQTT, Rademacher DuoFern, EPEver HiPower/ModBus, go-eCharger

kurt6908

Modul ModbusUPHIPOWER.pm

Hallo laserrichi,

hier mal das erste Feedback zum ModbusUPHIPOWER.pm:

B129 Battery 1 Current L
B130 Battery 1 Current H
=> Ist im Reading nur ein Wert
=> Ist immer 0 A (sollte wohl mal negativ und mal positiv sein)

A13 Load Nominal Input Power L
A14 Load Nominal Input Power H
A17 Load Nominal Output Apparent Power L
A18 Load Nominal Output Apparent Power H
A19 Load Nominal Output Active Power L
A20 Load Nominal Output Active Power H
=> Beim ganzen Load-Komplex fehlen die Leistung(Watt)-Angaben
=> Bitte mal checken, ob eventuell bei diesen postiv/negativ-Angaben nicht auch bei anderen Leistungsangaben Werte fehlen (kann ich nicht reproduzieren, da ich keine negativen Input erzeugen kann)
=> wohl auch oben beim "B129 Battery 1 Current L" das Problem

bPvChrgOnOff
=> Der normale UPPower hatte noch die Möglichkeit, mit dem Schalter 'bPvChrgOnOff' den Ladevorgang zu unterbrechen. Beim UPHiPower finde ich einen entsprechenden Schalter nicht. Ist dieser tatsächlich nicht vorhanden?

Viele Grüße

Kurt
3* Raspberry Pi (2 über LTE/VPN), 5* Cul, 3* FS20, 4* FHT, 6* HM, Somfy, Solarlog, WMBus/EnergyCam, AVM FritzBox, 3* AVM Powerline, Alexa, Tasmota/MQTT, Rademacher DuoFern, EPEver HiPower/ModBus, go-eCharger

laserrichi

Hallo Kurt,

Danke fürs feedback
Teste das hier bitte einmal.
Battery sollte jetzt laufen auch mit Vorzeichen -
Ebenso die anderen Werte, da habe ich es auch angepasst.

Den switch für PvChrgOnOff  habe ich mal eingebaut, dokumentiert es er in dem Modbus PDF nicht

Ebenso SysResetOnOff  GridSupplyChrgOnOff

Wenn du diese bitte mal testest ob sie überhaupt vorhanden sind.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

kurt6908

Hallo laserrichi,

vielen Dank für die schnelle Änderung.

Meine Tests:

B129 Battery 1 Current L
B130 Battery 1 Current H
=> BatteryCurrent => FEHLERHAFT
beim Ladevorgang der Batterien, also wenn der Wert postiv ist, passt es
beim Entladevorgang der Batterien, also wenn der Wert negativ sein sollte, ist er falsch
z.B. laut BMS Entladung mit ca. 47 A, laut Reading ca. 606 A

A13 Load Nominal Input Power L
A14 Load Nominal Input Power H
=> UP-LoadNomInPower => i.O. (negativer Wert nicht überprüft)

A17 Load Nominal Output Apparent Power L
A18 Load Nominal Output Apparent Power H
=> UP-LoadNomOutApparentPower => i.O. (negativer Wert nicht überprüft)

A19 Load Nominal Output Active Power L
A20 Load Nominal Output Active Power H
=> UP-LoadNomOutActivePower => i.O. (negativer Wert nicht überprüft)

PvChrgOnOff
=> Schalter erscheint im Reading, jedoch keine Funktion (PVInputPower, BatteryCurrent oder PvChrgStat ändern sich nicht). Ich werde es nochmal vor Ort an der Anlage testen.

Im Log ist mir nach dem Neustart noch folgendes aufgefallen:
Zitat
3: Garage_Inverter: MapConvert called from CreateDataObjects did not find 0 (0) in map 1:Inverter priority, 2:Utility Priority
3: Garage_Inverter: MapConvert called from CreateDataObjects did not find 0 (0) in map 1:Battery Mode, 2:non-Battery Mode
3: Garage_Inverter: MapConvert called from CreateDataObjects did not find 0 (0) in map 768:LithiumBattery, 1024:non-LithiumBattery

Viele Grüße

Kurt
3* Raspberry Pi (2 über LTE/VPN), 5* Cul, 3* FS20, 4* FHT, 6* HM, Somfy, Solarlog, WMBus/EnergyCam, AVM FritzBox, 3* AVM Powerline, Alexa, Tasmota/MQTT, Rademacher DuoFern, EPEver HiPower/ModBus, go-eCharger

laserrichi

ich frage mich gerade ob man die high register überhaupt braucht.
Kannst du bestimmte Batterieströme irgendwie einstellen, so das man dann mal sich die bits ansehen kann von den registern.

hab hier im Anhang mal den Batteriestrom nur auf das low Register gesetzt
Log Meldungen sollten auch weg sein, denn 2 waren verrutscht um 1 und der letzte der ist nicht dokumentiert

Die PvChrgOnOff scheint es dann wohl doch nicht zu geben
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

kurt6908

Modul ModbusUPHIPOWER.pm

Hallo laserrichi,

die Logeinträge sind weg, das funktioniert schon mal.

Batterieströme kann ich nicht einstellen, ich kann nur im tatsächlichen operativen Betrieb die Werte plausibilisieren. Batteriestrom ist abhänging von PV-Einstrahlung und der Last die versorgt wird (Anlage dient zum Laden eine Plug-In mit reinem PV-Strom).

BatteryCurrent:
Jetzt wird ein korrekter negativer und postiver Wert angezeigt, die Werte erscheinen als plausibel.

Ich weiß nicht, was die "high register" bedeuten, aber so wie es jetzt bei BatteryCurrent umgesetzt ist, passt es. Das Reading zeigt an, mit wieviel A die Batterie entweder geladen (postiver Wert) oder entladen (negativer Wert) wird.

Bie den Load-Readings (A13, A14, A17 - A20) kann ich es daher nicht sagen, ob man auf was verzichten kann, da ich auch nicht wüsste, welche Sinn ein negativer Wert bei der Last machen würde.

Aus meiner Sicht könntest Du die anhängende Version auf der ersten Seite veröffentlichen, andere Sachen sind mit noch nicht aufgefallen.

Gruß

Kurt
3* Raspberry Pi (2 über LTE/VPN), 5* Cul, 3* FS20, 4* FHT, 6* HM, Somfy, Solarlog, WMBus/EnergyCam, AVM FritzBox, 3* AVM Powerline, Alexa, Tasmota/MQTT, Rademacher DuoFern, EPEver HiPower/ModBus, go-eCharger

laserrichi

Also Low und High register sind anstatt 16bit eben 32bit Inhalte. Die werden nacheinander gelesen und müssen entsprechend ihrer Reihenfolge richtig zusammengesetzt werden.

also wenn man nur ein register liest und das vorzeichen hat für pos/neg  dann kann das -32768 bis 32767  annehmen
Da es durch 100 geteilt wird wären das -327,68A bis 327,67A
man könnte man das zweite Register als extra Reading einbauen um zu sehen was sich da tut.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

kurt6908

Modul ModbusUPHIPOWER.pm

Hallo laserrichi,

ahhh ... jetzt kapier ich es ... ich dachte low sind die negativen Werte und high die postiven ....  ;D ... doofer User halt ...

Wenn der low-Wert die Werte -327,68A bis 327,67A erreichen kann, dann wären das bei meiner Anlage

Batterie 24 Volt: 7.800 Watt
Last 230 Volt: 75.000 Watt

Da weder an der Batterie noch bei der Last solche Leistungen nötig bzw. benötigt werden, glaube ich, dass diese Range reicht. D.h. die high-Register braucht man dann wohl bei den Stärke/A-Readings bei der Batterie nicht. Bei den Leistungs/W-Readings bei der Last kann ich es nicht sagen, meine Anlage zumindest hat nicht solche Werte.

Folgendes ist mir noch aufgefallen:

Readings im Modul
- UP-LithiumBatteryEnable => aktueller Wert: unbekannt
- UP-LithiumBatteryEnalbe => aktueller Wert: 0

Ich bin wegen dem doppelten Namen incl. Schreibfehler drübergefallen, aber beide Readings finde ich auch nicht in der Protokollbeschreibung. Hier finde ich nur

D19
Lithium battery Parameters
UP-SysDevice_ParaReservel

D19 finde ich aber wiederum nicht im Modul.

Gruß

Kurt

3* Raspberry Pi (2 über LTE/VPN), 5* Cul, 3* FS20, 4* FHT, 6* HM, Somfy, Solarlog, WMBus/EnergyCam, AVM FritzBox, 3* AVM Powerline, Alexa, Tasmota/MQTT, Rademacher DuoFern, EPEver HiPower/ModBus, go-eCharger

laserrichi

Zitat von: kurt6908 am 11 Juli 2022, 10:06:56

Folgendes ist mir noch aufgefallen:

Readings im Modul
- UP-LithiumBatteryEnable => aktueller Wert: unbekannt
- UP-LithiumBatteryEnalbe => aktueller Wert: 0

Ich bin wegen dem doppelten Namen incl. Schreibfehler drübergefallen, aber beide Readings finde ich auch nicht in der Protokollbeschreibung. Hier finde ich nur

D19
Lithium battery Parameters
UP-SysDevice_ParaReservel

D19 finde ich aber wiederum nicht im Modul.

Gruß

Kurt

ja das war ein Schreibfehler den ich korrigiert hatte, und es ist D19 Lithium battery Parameters

Der liefert ja 0 zurück und habe 0 als unbekannt benannt weil man nicht weis was es bedeutet. Denn der sollte ja lt. doku 768 oder 1024 liefern..
Ich kann das auch komplett wieder löschen wenn man das register nicht braucht. Hast du eine lithium dran ?

den alten kannst ja mit deletereading "device" UP-LithiumBatteryEnalbe  schon mal löschen.

Ich kann auch bei allen Readings die das UP mitführen das UP- überall löschen, das hat sich so mitgeschleift beim erstellen, wie dir beliebt.

Gibt ja viele Register die es vermutlich nicht bei allen Geräten der Serie gibt oder mal geplant waren. Chinesen sind da nicht so genau :-)


RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

kurt6908

Hallo laserrichi,

ZitatHast du eine lithium dran ?

Ja, es hängen zwei LiPos dran:
Ich habe gem. Anleitung über das Bedienfeld LFP ausgewählt, andere Einstellungen gehen da beim Batterietyp über das Bedienfeld gar nicht, auch nicht in den Ingeneurparameter.
Die Readings zeigen folgendes:
UP-LithiumBatteryEnable => unbekannt
UP-SysBattType => LFP8S

Aber richtig brauchen tue ich es nicht, man weiß ja was man was eingestellt ist und Änderungen passieren wohl auch selten bzw. über das Bedienfeld.

Wichtiger sind die Parameter, die sich ändern, also Volt, Ampere und Watt und die Schalter (AC on/off), sofern vorhanden.

Zitatch kann auch bei allen Readings die das UP mitführen das UP- überall löschen, das hat sich so mitgeschleift beim erstellen, wie dir beliebt.
Da bin ich leidenschaftslos, solange man ein Mapping zwischen Doku und Modul hat ist der Name egal.

P.S. Den falschen Namen habe ich gelöscht ...

Insoweit läuft dann mal alles ...

Gruß

Kurt
3* Raspberry Pi (2 über LTE/VPN), 5* Cul, 3* FS20, 4* FHT, 6* HM, Somfy, Solarlog, WMBus/EnergyCam, AVM FritzBox, 3* AVM Powerline, Alexa, Tasmota/MQTT, Rademacher DuoFern, EPEver HiPower/ModBus, go-eCharger