FHEM Forum

In diesem Thread geht es um die Weiterentwicklung des Moduls 98_fronius.pm , die Modulversion im ursprünglichen Thread https://forum.fhem.de/index.php?topic=113850.0 ist verwaist.

Das Modul steht im SVN contrib zur Verfügung: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/98_fronius.pm?format=txt , zur Installation muss es im ./FHEM/ Verzeichnis abgelegt werden.

Hinweis für Nutzer der ursprünglichen Version 98_Fronius.pm : im Dateinamen hat sich das "F"auf ein kleines "f" geändert, damit es den fhem-Konventionen entspricht.
Abhängig von eurem Betriebssystem muss beim Upgrade die alte Version gelöscht werden bzw. wird sie überschrieben.

Ich hänge mich hier mal mit rein.

LG

pah

Danke Fichtennadel,

bin auch hier dabei benutze das Modul und lese mit. ;-)

Gruß,
Stefan

Moin,
ich stelle mich irgendwie zu blöd an und brauche mal bitte Hilfe. Habe das File runtergeladen und nach FHEM kopiert. Dann Neustart und versucht mit

define Fronius_Symo fronius 192.168.30.6
den WR einzubinden. Da kommt dann

ZitatCannot load module fronius

und im Log steht...
PERL WARNING: Bareword found where operator expected at ./FHEM/98_fronius.pm line 8, near "98_fronius"
2024.05.28 16:32:41 1: PERL WARNING: (Missing operator before fronius?)
2024.05.28 16:32:41 1: PERL WARNING: Bareword found where operator expected at ./FHEM/98_fronius.pm line 14, near ")
        window"
2024.05.28 16:32:41 1: PERL WARNING: (Missing operator before window?)
2024.05.28 16:32:41 1: PERL WARNING: Bareword found where operator expected at ./FHEM/98_fronius.pm line 18, near ""search"  href"
2024.05.28 16:32:41 1: PERL WARNING: (Missing operator before href?)
2024.05.28 16:32:41 1: PERL WARNING: Bareword found where operator expected at ./FHEM/98_fronius.pm line 38, near "jQuery"
2024.05.28 16:32:41 1: PERL WARNING: (Missing semicolon on previous line?)
2024.05.28 16:32:41 1: PERL WARNING: String found where operator expected at ./FHEM/98_fronius.pm line 39, near "$(".trac-autofocus""
2024.05.28 16:32:41 1: PERL WARNING: (Missing operator before ".trac-autofocus"?)
2024.05.28 16:32:41 1: PERL WARNING: String found where operator expected at ./FHEM/98_fronius.pm line 40, near "$(".trac-target-new""
2024.05.28 16:32:41 1: PERL WARNING: (Missing operator before ".trac-target-new"?)
2024.05.28 16:32:41 1: PERL WARNING: Bareword found where operator expected at ./FHEM/98_fronius.pm line 41, near "$.ui"
2024.05.28 16:32:41 1: PERL WARNING: (Missing operator before ui?)
2024.05.28 16:32:41 1: PERL WARNING: String found where operator expected at ./FHEM/98_fronius.pm line 42, near "$(".trac-datepicker:not([readonly])""
2024.05.28 16:32:41 1: PERL WARNING: (Missing operator before ".trac-datepicker:not([readonly])"?)
2024.05.28 16:32:41 1: PERL WARNING: Bareword found where operator expected at ./FHEM/98_fronius.pm line 44, near "// Input"
2024.05.28 16:32:41 1: PERL WARNING: (Missing operator before Input?)
2024.05.28 16:32:41 1: reload: Error:Modul 98_fronius deactivated:
 Can't modify glob in predecrement (--) at ./FHEM/98_fronius.pm line 7, near "<"
syntax error at ./FHEM/98_fronius.pm line 8, near "98_fronius"
Unknown regexp modifier "/t" at ./FHEM/98_fronius.pm line 8, at end of line
Unknown regexp modifier "/t" at ./FHEM/98_fronius.pm line 8, at end of line
Unknown regexp modifier "/e" at ./FHEM/98_fronius.pm line 8, at end of line
Not enough arguments for link at ./FHEM/98_fronius.pm line 18, near ""search"  href"
syntax error at ./FHEM/98_fronius.pm line 18, near ""search"  href"
syntax error at ./FHEM/98_fronius.pm line 40, near "$(".trac-target-new""
syntax error at ./FHEM/98_fronius.pm line 41, near "$.ui"
syntax error at ./FHEM/98_fronius.pm line 44, near "// Input current "
./FHEM/98_fronius.pm has too many errors.

2024.05.28 16:32:41 0: Can't modify glob in predecrement (--) at ./FHEM/98_fronius.pm line 7, near "<"
syntax error at ./FHEM/98_fronius.pm line 8, near "98_fronius"
Unknown regexp modifier "/t" at ./FHEM/98_fronius.pm line 8, at end of line
Unknown regexp modifier "/t" at ./FHEM/98_fronius.pm line 8, at end of line
Unknown regexp modifier "/e" at ./FHEM/98_fronius.pm line 8, at end of line
Not enough arguments for link at ./FHEM/98_fronius.pm line 18, near ""search"  href"
syntax error at ./FHEM/98_fronius.pm line 18, near ""search"  href"
syntax error at ./FHEM/98_fronius.pm line 40, near "$(".trac-target-new""
syntax error at ./FHEM/98_fronius.pm line 41, near "$.ui"
syntax error at ./FHEM/98_fronius.pm line 44, near "// Input current "
./FHEM/98_fronius.pm has too many errors.
Könnte mir jemand kurz sagen, was da schief läuft  :-\

Sieht nach html aus, hast Du das angezeigte html Dokument aus dem Link im ersten Posting direkt als 98_fronius.pm abgespeichert?
Das klappt so nicht, nur der Perl-Code darf ins File, nimm bitte diesen Link https://svn.fhem.de/trac/browser/trunk/fhem/contrib/98_fronius.pm?format=txt
Ich passe den Link auch oben an, damit es keine Missverständnisse gibt.

Moin,
vielen Dank, das wars wohl :P

Das Modul läuft soweit. Warte heute Abend noch ab, was passiert, wenn der WR offline geht nach Sonnenuntergang.

Ansonsten... das Modul liefert leider (noch) keine Daten der MPPT, also Spannung, Leistung, Strom und Energie der Strings. Da muss ich derzeit noch das Modul Fronius_MPPT parallel laufen lassen. Ist geplant, diese Daten auch noch zu integrieren?

Die MPPT Werte kommen bei meinem Symo mit den Archivdaten als (Current|Voltage)_DC_String_(1|2)_Values und werden als MPPT(1|2)_DC_(A|V|W) Readings dargestellt.
Laut Fronius API Doku gibt es diese Werte aber nicht aus den Archivdaten für den GEN24/Tauro.

Welches Modell hast Du denn?

Ich hab einen Symo 7.0-3-M.

Hier mal das Listing des Geräts, da kommen nur sehr wenige Archivdaten und keine der Strings:
Internals:
   CFGFN     
   DEF        192.168.30.6
   FUUID      6656bc7e-f33f-497e-393b-dcc1a10d2eff1ebb
   NAME       fronius_Symo
   NOTIFYDEV  global
   NR         294
   NTFY_ORDER 50-fronius_Symo
   STATE      connected
   TYPE       fronius
   eventCount 2986
   READINGS:
     2024-05-29 07:26:22   API_APIVersion  1
     2024-05-29 07:26:22   API_BaseURL     /solar_api/v1/
     2024-05-29 07:26:22   API_CompatibilityRange 1.8-1
     2024-05-29 09:22:03   ArchiveData_EndDate 2024-05-29T09:21:59+02:00
     2024-05-29 09:22:03   ArchiveData_EnergyReal_WAC_Sum_Produced 149.170277777778
     2024-05-29 09:22:03   ArchiveData_PowerReal_PAC_Sum 1778.18874172185
     2024-05-29 09:22:03   ArchiveData_StartDate 2024-05-29T09:17:00+02:00
     2024-05-29 07:26:27   DeviceInfo_Inverter_1_DT 105
     2024-05-29 07:26:27   DeviceInfo_Inverter_1_Serial 31472478
     2024-05-29 09:22:32   Inverter_3P_IAC_L1_Unit A
     2024-05-29 09:22:32   Inverter_3P_IAC_L1_Value 2.79
     2024-05-29 09:22:32   Inverter_3P_IAC_L2_Unit A
     2024-05-29 09:22:32   Inverter_3P_IAC_L2_Value 2.79
     2024-05-29 09:22:32   Inverter_3P_IAC_L3_Unit A
     2024-05-29 09:22:32   Inverter_3P_IAC_L3_Value 2.79
     2024-05-29 09:22:32   Inverter_3P_UAC_L1_Unit V
     2024-05-29 09:22:32   Inverter_3P_UAC_L1_Value 232.6
     2024-05-29 09:22:32   Inverter_3P_UAC_L2_Unit V
     2024-05-29 09:22:32   Inverter_3P_UAC_L2_Value 232.1
     2024-05-29 09:22:32   Inverter_3P_UAC_L3_Unit V
     2024-05-29 09:22:32   Inverter_3P_UAC_L3_Value 232.5
     2024-05-29 09:22:32   Inverter_Common_DAY_ENERGY_Unit Wh
     2024-05-29 09:22:32   Inverter_Common_DAY_ENERGY_Value 5059
     2024-05-29 09:22:32   Inverter_Common_DeviceStatus_ErrorCode 0
     2024-05-29 09:22:32   Inverter_Common_DeviceStatus_LEDColor 2
     2024-05-29 09:22:32   Inverter_Common_DeviceStatus_LEDState 0
     2024-05-29 09:22:32   Inverter_Common_DeviceStatus_MgmtTimerRemainingTime -1
     2024-05-29 09:22:32   Inverter_Common_DeviceStatus_StateToReset false
     2024-05-29 09:22:32   Inverter_Common_DeviceStatus_StatusCode 7
     2024-05-29 09:22:32   Inverter_Common_FAC_Unit Hz
     2024-05-29 09:22:32   Inverter_Common_FAC_Value 49.96
     2024-05-29 09:22:32   Inverter_Common_IAC_Unit A
     2024-05-29 09:22:32   Inverter_Common_IAC_Value 8.37
     2024-05-29 09:22:32   Inverter_Common_IDC_Unit A
     2024-05-29 09:22:32   Inverter_Common_IDC_Value 5.39
     2024-05-29 09:22:32   Inverter_Common_PAC_Unit W
     2024-05-29 09:22:32   Inverter_Common_PAC_Value 1949
     2024-05-29 09:22:32   Inverter_Common_TOTAL_ENERGY_Unit Wh
     2024-05-29 09:22:32   Inverter_Common_TOTAL_ENERGY_Value 14832359
     2024-05-29 09:22:32   Inverter_Common_UAC_Unit V
     2024-05-29 09:22:32   Inverter_Common_UAC_Value 232.6
     2024-05-29 09:22:32   Inverter_Common_UDC_Unit V
     2024-05-29 09:22:32   Inverter_Common_UDC_Value 336.9
     2024-05-29 09:22:32   Inverter_Common_YEAR_ENERGY_Unit Wh
     2024-05-29 09:22:32   Inverter_Common_YEAR_ENERGY_Value 2801519.75
     2024-05-29 09:22:32   Inverter_Cumulation_DAY_ENERGY_Unit Wh
     2024-05-29 09:22:32   Inverter_Cumulation_DAY_ENERGY_Value 5059
     2024-05-29 09:22:32   Inverter_Cumulation_DeviceStatus_ErrorCode 0
     2024-05-29 09:22:32   Inverter_Cumulation_DeviceStatus_LEDColor 2
     2024-05-29 09:22:32   Inverter_Cumulation_DeviceStatus_LEDState 0
     2024-05-29 09:22:32   Inverter_Cumulation_DeviceStatus_MgmtTimerRemainingTime -1
     2024-05-29 09:22:32   Inverter_Cumulation_DeviceStatus_StateToReset false
     2024-05-29 09:22:32   Inverter_Cumulation_DeviceStatus_StatusCode 7
     2024-05-29 09:22:32   Inverter_Cumulation_PAC_Unit W
     2024-05-29 09:22:32   Inverter_Cumulation_PAC_Value 1949
     2024-05-29 09:22:32   Inverter_Cumulation_TOTAL_ENERGY_Unit Wh
     2024-05-29 09:22:32   Inverter_Cumulation_TOTAL_ENERGY_Value 14832359
     2024-05-29 09:22:32   Inverter_Cumulation_YEAR_ENERGY_Unit Wh
     2024-05-29 09:22:32   Inverter_Cumulation_YEAR_ENERGY_Value 2801519.75
     2024-05-29 09:22:32   Inverter_System_DAY_ENERGY_Unit Wh
     2024-05-29 09:22:32   Inverter_System_DAY_ENERGY_Values_1 5059
     2024-05-29 09:22:32   Inverter_System_PAC_Unit W
     2024-05-29 09:22:32   Inverter_System_PAC_Values_1 1949
     2024-05-29 09:22:32   Inverter_System_TOTAL_ENERGY_Unit Wh
     2024-05-29 09:22:32   Inverter_System_TOTAL_ENERGY_Values_1 14832359
     2024-05-29 09:22:32   Inverter_System_YEAR_ENERGY_Unit Wh
     2024-05-29 09:22:32   Inverter_System_YEAR_ENERGY_Values_1 2801519
     2024-05-29 09:22:03   MPPT1_DC_A      2.42
     2024-05-29 09:22:03   MPPT1_DC_V      336.5
     2024-05-29 09:22:03   MPPT1_DC_W      814.33
     2024-05-29 09:22:03   MPPT2_DC_A      2.49
     2024-05-29 09:22:03   MPPT2_DC_V      403.7
     2024-05-29 09:22:03   MPPT2_DC_W      1005.213
     2024-05-29 09:22:34   PowerFlow_Inverters_1_DT 105
     2024-05-29 09:22:34   PowerFlow_Inverters_1_E_Day 5060
     2024-05-29 09:22:34   PowerFlow_Inverters_1_E_Total 14832359
     2024-05-29 09:22:34   PowerFlow_Inverters_1_E_Year 2801520.75
     2024-05-29 09:22:34   PowerFlow_Inverters_1_P 1970
     2024-05-29 09:22:34   PowerFlow_Site_E_Day 5060
     2024-05-29 09:22:34   PowerFlow_Site_E_Total 14832359
     2024-05-29 09:22:34   PowerFlow_Site_E_Year 2801520.75
     2024-05-29 09:22:34   PowerFlow_Site_Meter_Location unknown
     2024-05-29 09:22:34   PowerFlow_Site_Mode produce-only
     2024-05-29 09:22:34   PowerFlow_Site_P_Akku 0
     2024-05-29 09:22:34   PowerFlow_Site_P_Grid 0
     2024-05-29 09:22:34   PowerFlow_Site_P_Load 0
     2024-05-29 09:22:34   PowerFlow_Site_P_PV 1970
     2024-05-29 09:22:34   PowerFlow_Site_rel_Autonomy 0
     2024-05-29 09:22:34   PowerFlow_Site_rel_SelfConsumption 0
     2024-05-29 09:22:34   PowerFlow_Version 12
     2024-05-29 07:26:22   state           connected
   helper:
     RUNNING_REQUEST 0
     CMD_QUEUE:
     VARS:
       FroniusBaseURL /solar_api/v1/
       FroniusIP  192.168.30.6
       ReInitGetAPIVersionInfo 0
       Smart_Inverter 1
       Smart_Meter nA
       Smart_OhmPilot nA
       Smart_SensorCard nA
       Smart_Storage nA
       Smart_StringControl nA
Attributes:
   IntervalRealtimeData 10
   room       4.1_Energie

da sind sie doch, oder meinst du was anderes?

     2024-05-29 09:22:03   MPPT1_DC_A      2.42
     2024-05-29 09:22:03   MPPT1_DC_V      336.5
     2024-05-29 09:22:03   MPPT1_DC_W      814.33
     2024-05-29 09:22:03   MPPT2_DC_A      2.49
     2024-05-29 09:22:03   MPPT2_DC_V      403.7
     2024-05-29 09:22:03   MPPT2_DC_W      1005.213


Verdammt... da waren die bei der ersten Erstellung des Posts noch nicht da und beim Kopieren für das Folgeposting hab ich das übersehen  ::)  Vergiss alles ab guten Morgen... danke für das Modul!

Moin. Ich hätte nach nun mehrtätigem Test eine Anregung für eine Weiterentwicklung des Moduls:

Sobald mein Symo nach Sonnenuntergang abschaltet und die LAN-Schnittstelle deaktiviert (habe ich aus Energiespargründen so im WR konfiguriert), schreibt das Modul das Log mit Meldungen voll, dass der WR nicht erreicht werden kann. Das lässt sich zwar mit verbose 0 unterdrücken, aber schöner wäre es, wenn das Modul erkennt, dass erstmal nichts mehr kommt und die Abfragen unterbindet.

Zitat von: MichaelO am 03 Juni 2024, 08:52:43habe ich aus Energiespargründen so im WR konfiguriert

Erst einmal ist das vom Workflow her ziemlicher Unsinn. Denn wie sollte die Software ohne spezielles Signal erkennen, dass sie jetzt wieder Abfragen durchführen soll?
Zweitens ist das vollkommen unsinnig, wenn der Wechselrichter aus einem angeschlossenen Speicher auch bei Dunkelheit Energie ins Hausnetz einspeisen kann.
Drittens: Was um Himmels Willen soll das denn an Energie einsparen? Und dafür soll jemand erhebliche Programmieraufwände tätigen?

Fazit: Wer so eine Lösung möchte, kann sie problemlos mit den vorhandenen FHEM-Bordmitteln außerhalb des Moduls realisieren.

LG

pah

@ fichtennadel,

vielen Dank, Modul wurde aktualisiert, läuft alles perfekt mit einem Fronius Symo 5.0-3-M und ich lese hier dann gerne mit.

Viele Grüße!

Peter

Zitat von: Prof. Dr. Peter Henning am 03 Juni 2024, 09:44:02Erst einmal ist das vom Workflow her ziemlicher Unsinn. Denn wie sollte die Software ohne spezielles Signal erkennen, dass sie jetzt wieder Abfragen durchführen soll?
Zweitens ist das vollkommen unsinnig, wenn der Wechselrichter aus einem angeschlossenen Speicher auch bei Dunkelheit Energie ins Hausnetz einspeisen kann.
Drittens: Was um Himmels Willen soll das denn an Energie einsparen? Und dafür soll jemand erhebliche Programmieraufwände tätigen?

Fazit: Wer so eine Lösung möchte, kann sie problemlos mit den vorhandenen FHEM-Bordmitteln außerhalb des Moduls realisieren.

Der Herr Professor hat gesprochen, so soll es denn nun sein :-X In der Schule hätte man vielleicht vorsichtig entgegen geworfen bekommen, dass die Antwort zwar lang, aber leider am Thema vorbei ist. Ich fände es angemessen, wenn Antworten auf - aus meiner Sicht - berechtigte Anliegen weniger arrogant rüber kommen, insbesondere dann, wenn die Ausgangs-Postings offensichtlich nicht vernünftig gelesen werden. Nun aber genug der persönlichen Dinge, es soll ja ums Sachliche gehen.

Zunächst zum zweiten Punkt des angeblichen Unsinns: Ich hatte nirgendwo erwähnt, dass am Symo ein Speicher hängt, der nachts etwas einspeisen könnte. Der WR ist ein Fronius Symo 7.0-3-M, da kann man keinen Speicher anhängen. Der WR schaltet somit nach Standby bzw. geht aus, sobald von den Modulen nichts mehr kommt.

Hier kommt dann der dritte Teil des angeblichen Unsinns zum Tragen: Und für diesen Betriebszustand hat der Hersteller einen Nachtmodus geschaffen: "DATCOM Nacht-Modus; steuert den DATCOM- und Display-Betrieb während der Nacht oder bei nicht ausreichend vorhandener DC-Spannung." Und wenn man diesen ausschaltet, dann: "Kein DATCOM-Betrieb in der Nacht, der Wechselrichter braucht keinen ACStrom zur Versorgung des Solar Net." ... und insbesondere "WICHTIG! Ist der DATCOM-Nachtmodus auf ON oder auf AUTO bei angeschlossenen Solar Net Komponenten eingestellt, erhöht sich der Stromverbrauch des Wechselrichters während der Nacht auf rund 7 W." Der Eigenverbrauch in der Nacht wird mit etwa 0.7W angegeben, somit wären es ohne Nachtmodus über 6W Stromverbrauch für quasi nix. Über den Daumen macht das grob 22kWh pro Jahr für die Tonne. Der erhebliche Programmieraufwand wurde demnach für das Gerät durch den Hersteller in Kauf genommen, weil man offensichtlich einen Use-Case gesehen hat, dass es sich lohnt.

Und zuletzt zum ersten Unsinn-Teil: Eine Lösung, die mir sofort einfällt, wäre, dass man im Modul konfigurieren kann, dass man einen Nacht-Modus verwenden möchte. Und dann fragt das Modul einfach in der Nacht - hier liefert fhem ja die passenden Daten für den Zeitraum quasi frei Haus - den WR nicht mehr ab. Das angesprochene "fehlende spezielle Signal" wäre in diesem Fall Sonnenauf- und -untergang, das passiert jeden Tag voll automatisch und ist auch nicht abwählbar. Oder wenn x-Mal eine Erreichbarkeits-Fehlermeldung zwischen Sonnenunter- und -aufgang gekommen ist, wird bis Sonnenaufgang die Abfrage ausgesetzt. Lösungen gäbe es bestimmt viele.

Natürlich kann jetzt jeder, der den Bedarf hat, das Problem individuell in seinem fhem lösen, aber das führt doch irgendwie das Konzept der Module ad absurdum. Da hätte man genau so argumentieren können, als es um die grundsätzliche Modulerstellung ging. Jeden WR kann man auch "problemlos" mit vorhandenen FHEM-Bordmitteln abfragen. Dennoch denke ich, dass das Modul sowas leisten KÖNNTE und davon etliche Nutzer profitieren könnten.

Es ist und bleibt Unsinn, solche Zeitsteuerungen in ein spezialisiertes Gerätemodul aufzunehmen. Dafür gibt es in FHEM genügend Mechanismen.

Darüber hinaus zeigt die Erfahrung von fast 2 Jahrzehnten PV-Betrieb, dass die Situation "zu geringe DC-Spannung" durchaus nicht nur Nachts auftreten kann, sondern z.B. auch bei Sommergewittern. Es bleibt auch hier dem Betreiber überlassen, aus den fehlgeschlagenen Abfragen etwas Sinnvolles zu machen. Aus genau diesem Grund geht Fronius _nicht_ den Weg einer Zeitsteuerung, sondern schaut nach der Gleichspannung.

Es handelt sich übrigen nicht per se um

Zitatberechtigte Anliegen

, schon gar nicht um "Use Cases" wenn man von Modulentwicklern spezielle Änderungen für die Erfüllung der eigenen Bedürfnisse verlangt.

LG

pah

P.S.: Gerne lasse ich mir das "Konzept der Module" erklären. Ich könnte mich revanchieren, indem ich den Unterschied zwischen HTML-Code und Perl-Dateien erläutere.

Zitat von: Prof. Dr. Peter Henning am 10 Juni 2024, 16:03:48... Dafür gibt es in FHEM genügend Mechanismen.

Mein Vorschlag wäre auch, das außerhalb des Moduls zu realisieren, zB mit einem DOIF:
- Trigger auf Sonnenauf/untergang, kann über Parameter verschoben werden, siehe https://fhem.de/commandref_DE.html#SUNRISE_EL
- die gewünschten Interval Attributes auf 0 / >0 setzen
- "set wechselrichtertest RestartInterval" , damit die Timer nach der Änderung neu gestartet werden.

define WRGetOnOff DOIF ([{sunrise('CIVIL',0,'06:00','07:00')}]) (\
    attr wechselrichtertest IntervalRealtimeData 10\
   ,set wechselrichtertest RestartInterval  \
) DOELSEIF ([{sunset('HORIZON=-4',0,'16:00','21:00')}]) (\
    attr wechselrichtertest IntervalRealtimeData 0\
   ,set wechselrichtertest RestartInterval  \
)

Oder man setzt einfach so das Modul auf verbose 0 wenn der WR < X Watt bringt. Und verbose X wenn wieder was kommt.

Zudem könnte man den Intervall anheben im verbose 0 status. Um overhead zu sparen aber man reagiert dann auf das aufwachen des WR zeitnah.

Kann sich ja jeder easy zusammen schustern wie es im beliebt. Optionen dazu sind ja auch schon intern vorhanden.

Fraglich ist auch was mit so Paremetern wie "PowerFlow_Inverters_1_E_Day" passiert. Die stehen ja dann solange auf Wert bis der WR wieder was schickt.
Und je nach gebrauch verzerrt man damit eventuell Trends oder Logs. Sollte man bedenken.

Es empfiehlt sich, die Energie als Integral über die Leistung selbst zu berechnen. Einfach ein Userreading mit "integral".

LG

pah

Nunja, sehe ich nicht ganz so pah.
Kommt im allgemeinen drauf an wie genau man es haben möchte.
Mit einem großen Abfrageinterval wird es doch recht ungenau wenn starke Schwankungen innerhalb der Abtastrate auftreten.
Zumal das Reading bzw. der Wert hier in dem Modul ja schon frei Haus geliefert wird.
Wenn das nicht so wäre bliebe einem ja fast nur die Integral-funktion des Userreadings.
Ob man das dann immer macht um eventuell eine Kontinuität zu erhalten bleibt ja bei jedem selbst.

Ich bin ja nicht von gestern. Natürlich vergleiche ich "selbst integrierte" Werte mit den von der Anlage gelieferten. Abweichungen über den Tag summiert bei 0.2 kWh.

Übrigens sollte man sich nicht in die Tasche lügen: Auch die Anlage führt eine recht primitive Integration durch, um die Energie zu ermitteln.

LG

pah

Hallo Fichtennadel,
erst mal herzlichen Dank für das Modul.
Wäre es möglich die bereitgestellten Temperaturen auszulesen?
Aus dem Dashboard des WR sehe ich
Isolationswiderstand 137.63 MΩ
Temperatur AC-Modul 41.55 °C
Temperatur DC-Modul 40.17 °C
Temperatur Batteriemodul 39.49 °C
Wechselrichter Innentemperatur 51.61 °CEs ist ein Symo-Gen24.
Ich möchte gern wissen ob- und ggf wann dem Teil zu warm wird.

Grüße WDS

Ich bekomme über das Fronius Modbus Modul eine Temperatur vom WR.
Temp_Cabinet__C     52.6    2024-07-31 23:52:31
Temp_Coolant__C     NaN     2024-07-31 23:55:26
Temp_Transformer__C NaN     2024-07-31 23:53:28
Temp_other__C       NaN     2024-07-31 23:52:31

Also nur die Cabinet Temp aber das reicht mir.

Gruß,
Stefan

In der Fronius Doku zur Solar API V1 (link) (https://www.fronius.com/~/downloads/Solar%20Energy/Operating%20Instructions/42,0410,2012.pdf) finde ich Temperaturen nur bei den Batteriewerten und Ohmpilot.

Ich habe selbst keinen Symo-Gen24, kannst Du die Ausgabe von
http://<IP>/solar_api/v1/GetPowerFlowRealtimeData.fcgi
http://<IP>/solar_api/v1/GetActiveDeviceInfo.cgi?DeviceClass=Inverter
http://<IP>/solar_api/v1/GetInverterRealtimeData.cgi?Scope=System
http://<IP>/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=CumulationInverterData
http://<IP>/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=CommonInverterData
http://<IP>/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=3PInverterData
hier posten? (<IP> durch die IP Adresse Deines Wechselrichters im lokalen Netz ersetzen)

Vielleicht kommt doch was und wir können das verwenden.

Noch eine andere Möglichkeit: wenn Du im Browser das Dashboard offen hast, F12 drücken (Entwicklertools) und dort auf Netzwerk und die Requests beobachten bzw. raussuchen, mit denen die Temperatur kommt.

Ansonsten bliebe noch wie von stefanru erwähnt das Modbus Modul.

Ok fangen wir mal an:
http://<IP>/solar_api/v1/GetPowerFlowRealtimeData.fcgi

Body
Data
Inverters
1
Battery_Mode "normal"
DT 1
E_Day null
E_Total 799169.4630555556
E_Year null
P 1884.2720947265625
SOC 100
SecondaryMeters {}
Site
BackupMode false
BatteryStandby true
E_Day null
E_Total 799169.4630555556
E_Year null
Meter_Location "grid"
Mode "bidirectional"
P_Akku 0.42344430088996887
P_Grid -10.7
P_Load -1873.5061767578125
P_PV 1929.5510864257812
rel_Autonomy 100
rel_SelfConsumption 99.43212159412343
Smartloads
Ohmpilots {}
Version "12"
Head
RequestArguments {}
Status
Code 0
Reason ""
UserMessage ""
Timestamp "2024-08-01T13:40:24+00:00"http://<IP>/solar_api/v1/GetActiveDeviceInfo.cgi?DeviceClass=Inverter

Body
Data
1
DT 1
Serial "34579946"
Head
RequestArguments
DeviceClass "Inverter"
Status
Code 0
Reason ""
UserMessage ""
Timestamp "2024-08-01T13:44:43+00:00"http://<IP>/solar_api/v1/GetInverterRealtimeData.cgi?Scope=System

Body
Data
DAY_ENERGY
Unit "Wh"
Values
1 null
PAC
Unit "W"
Values
1 1938.0341796875
TOTAL_ENERGY
Unit "Wh"
Values
1 799328.2516666667
YEAR_ENERGY
Unit "Wh"
Values
1 null
Head
RequestArguments
Scope "System"
Status
Code 0
Reason ""
UserMessage ""
Timestamp "2024-08-01T13:46:06+00:00"http://<IP>/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=CumulationInverterData

Body
Data
DAY_ENERGY
Unit "Wh"
Value null
DeviceStatus
ErrorCode 0
InverterState "Running"
StatusCode 7
PAC
Unit "W"
Value 1946.179443359375
TOTAL_ENERGY
Unit "Wh"
Value 799328.2516666667
YEAR_ENERGY
Unit "Wh"
Value null
Head
RequestArguments
DataCollection "CumulationInverterData"
DeviceId "1"
Scope "Device"
Status
Code 0
Reason ""
UserMessage ""
Timestamp "2024-08-01T13:47:41+00:00"http://<IP>/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=CommonInverterData

Body
Data
DAY_ENERGY
Unit "Wh"
Value null
DeviceStatus
ErrorCode 0
InverterState "Running"
StatusCode 7
FAC
Unit "Hz"
Value 49.994606018066406
IAC
Unit "A"
Value 8.176573038101196
IDC
Unit "A"
Value 2.7048604488372803
IDC_2
Unit "A"
Value 1.4426387548446655
IDC_3
Unit "A"
Value null
IDC_4
Unit "A"
Value null
PAC
Unit "W"
Value 1943.078369140625
SAC
Unit "VA"
Value 1943.10107421875
TOTAL_ENERGY
Unit "Wh"
Value 799328.2516666667
UAC
Unit "V"
Value 238.16015625
UDC
Unit "V"
Value 642.1260986328125
UDC_2
Unit "V"
Value 181.5933074951172
UDC_3
Unit "V"
Value null
UDC_4
Unit "V"
Value null
YEAR_ENERGY
Unit "Wh"
Value null
Head
RequestArguments
DataCollection "CommonInverterData"
DeviceId "1"
Scope "Device"
Status
Code 0
Reason ""
UserMessage ""
Timestamp "2024-08-01T13:48:48+00:00"http://<IP>/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=3PInverterData

Body
Data
IAC_L1
Unit "A"
Value 2.737107276916504
IAC_L2
Unit "A"
Value 2.7354674339294434
IAC_L3
Unit "A"
Value 2.7392072677612305
UAC_L1
Unit "V"
Value 237.71649169921875
UAC_L2
Unit "V"
Value 236.8125457763672
UAC_L3
Unit "V"
Value 237.98141479492188
Head
RequestArguments
DataCollection "3PInverterData"
DeviceId "1"
Scope "Device"
Status
Code 0
Reason ""
UserMessage ""
Timestamp "2024-08-01T13:49:45+00:00"
Grüße WDS

Zitat von: stefanru am 31 Juli 2024, 23:59:05Ich bekomme über das Fronius Modbus Modul eine Temperatur vom WR.
Temp_Cabinet__C    52.6    2024-07-31 23:52:31
Temp_Coolant__C    NaN    2024-07-31 23:55:26
Temp_Transformer__C NaN    2024-07-31 23:53:28
Temp_other__C      NaN    2024-07-31 23:52:31

Also nur die Cabinet Temp aber das reicht mir.

Gruß,
Stefan

Im Fronius Modul ist Storage_0_Controller_Temperature_Cell enthalten.
Bei Vollast 25 Grad in der warmen Garage -nee- das glaube ich nicht.
Die darunter stehende BYD Batterie sagt 53 Grad, das kommt eher hin.
Die Temperaturen aus dem Fronius Modbus Modul sind für mich plausibel.
Isolationswiderstand 137.63 MΩ
Temperatur AC-Modul 41.55 °C
Temperatur DC-Modul 40.17 °C
Temperatur Batteriemodul 39.49 °C
Wechselrichter Innentemperatur 51.61 °C Na ja...

Grüße WDS

Zitat von: dieter114 am 01 August 2024, 15:51:16Ok fangen wir mal an:
http://<IP>/solar_api/v1/...

Ich seh da leider keine Werte für Temperatur, das scheint Fronius im Solar API tatsächlich nicht zur Verfügung zu stellen  :(

Hi dieter114,

kannst du mir sagen wie du im Modbus die anderen Werte bekommst?
Ich gehe davon aus du hast einen Gen24?
Kannst du mir deine Device Description von deinem Fronius Modbus Device schicken?

Danke und Gruß,
Stefan

Zitat von: fichtennadel am 01 August 2024, 16:16:51Ich seh da leider keine Werte für Temperatur, das scheint Fronius im Solar API tatsächlich nicht zur Verfügung zu stellen 

Sieht so aus, in der API-Dokumentation ist die T des WR nicht zu finden.

LG

pah

Edit:Die nüssen irgendwas verändert haben:
Seit heute bekomme ich nicht mal mehr über das Dashboard irgendwelche Temperaturen angezeigt
oder die werden nur angegeben wenn es irgendwie richtig warm wird im Gerät.
Bei uns ist z.Z. Regen und Wolken, der WR läuft also bei 10-15%.
Er hat eine aktive Kühlung daher also recht kalt innen.
Ich beobachte das weiter.

Edit: Die Werte im Dashboard sind wieder da.
Wenn man als "Technician" angemeldet ist, werden in der Darstellung "Erweitert" viel mehr Werte angezeigt!

Grüße WDS

Diese Werte :
Aktuelle Werte
Wechselrichter 
AC-Ausgangsleistung 691.47 W
AC-Frequenz 50.02 Hz
DC-Leistung PV1 1.19 W
DC-Leistung PV2 1.30 W
DC-Spannung PV1 54.60 V
DC-Spannung PV2 58.19 V
DC-Strom PV1 21.87 mA
DC-Strom PV2 22.32 mA
Batterieleistung 729.65 W
Batteriespannung 422.54 V
Batteriestrom 1.73 A
AC-Spannung L1-N 235.76 V
AC-Spannung L2-N 234.81 V
AC-Spannung L3-N 234.29 V
AC-Spannung L1-L2 407.06 V
AC-Spannung L2-L3 406.60 V
AC-Spannung L1-L3 407.19 V
AC-Strom L1 980.98 mA
AC-Strom L2 979.95 mA
AC-Strom L3 983.32 mA
Wirkleistung L1 231.02 W
Wirkleistung L2 229.95 W
Wirkleistung L3 230.50 W
Scheinleistung L1 231.02 VA
Scheinleistung L2 229.95 VA
Scheinleistung L3 230.50 VA
Scheinleistung gesamt 691.47 VA
Blindleistung L1 -268.40 mvar
Blindleistung L2 -211.38 mvar
Blindleistung L3 -725.66 mvar
Blindleistung gesamt -1.21 var
Isolationswiderstand 20.81 MΩ
Temperatur AC-Modul 39.41 °C
Temperatur DC-Modul 37.80 °C
Temperatur Batteriemodul 37.23 °C
Wechselrichter Innentemperatur 51.08 °C
DC Spannung 606.37 V
Güße WDS

Hi WDS,

ah ok ich verstehe,
du hast die Werte vom Webinterface des Wechselrichters unter Erweitert.
Ja da sehe ich die Werte auch.
Das muss aber nicht heißen dass sie per API von Fronius oder per Modbus bereitgestellt werden.
Trotzdem interessant dass die vorhanden sind.

Viele Grüße,
Stefan

Hi Stefan,

die Frage ist nun wie bekommen wir diese Werte dort rausgelesen.
Oder sollte man mal eine Anfrage bei Fronius machen.
Die machen Werbung damit das alle möglichen Daten per API oder Modbus ausgelesen werden können.
Warum also sollten sie die Temperaturen verhindern?

Grüße WDS

Hi WDS,

es gibt bei Fronius eine Beschreibung der Schnittstellen.
Da wollte ich nochmal nachschauen, mir fehlt aber gerade etwas die Zeit.
Hier kann man die Dokumente dazu herunterladen:
https://www.fronius.com/de/solarenergie/installateure-partner/technische-daten/alle-produkte/anlagen-monitoring/offene-schnittstellen/

Gruß,
Stefan

Habe mir auch nochmal die Solar API V1 angeschaut und wie Fichtennadel schon schrieb gibts Temperaturen bei Ohmpilot und Battery.

Es gibt einen Temperaturwert der aber bei Gen24 nicht geliefert wird:
T_AMBIENT integer Ambient temperature
Most inverter like GEN24/Tauro do not provide it. Only
provided by CL, XL and IG500/400.

Mehr bietet die Solar API leider nicht.

Da musst du wohl noch Modbus abfragen. Gibt ja das Modul Fronius_Modbus hier.
Da bekommst du die Temperatur wie von mir vorher beschrieben.
Ich benutze es und bin zufrieden.

Viele Grüße,
Stefan

Zitat von: stefanru am 04 August 2024, 19:49:26Ambient temperature

Das ist NICHT die Temperatur des Wechselrichters ...

pah

Ja ist es nicht und er wird nichtmal geliefert beim Gen24 und Symo.
Somit leider über die die Solar API V1 keine Temperaturen.

Über Modubus gibt es Temp_Cabinet__C die scheint auch zu stimmen.

Gruß,
Stefan

Woran kann es liegen, dass irgendwann nicht mehr alle Werte aktualisiert werden?
Eine Regel ist leider nicht zu erkennen.

Hallo,

ich habe mehrere gen24 und auch bei mir wird MPPT1 und MPPT2 nichts angezeigt.
Über http://xxx.xxx.xxx.xxx/components/cache/readable bekomme ich aber eine liste mit den Informationen für MPPT 1 und 2 ebenso bekomme ich Temperaturen und Iso Widerstand und natürlich noch einiges mehr.

Wäre es nicht möglich die Daten mit in das Modul aufzunehmen aus der abfrage oder was würde da dagegen sprechen?

klar ich könnte mir für die ganzen Wechselrichter auch HTTPMOD abfragen bauen aber praktischer wäre es über das Fronius Modul natürlich schon.

Hier noch ein kleiner Auszug aus den daten:

"DEVICE_TEMPERATURE_AMBIENTEMEAN_F32" : 50.36553955078125,
"ISO_RESISTANCE_MEAN_F32" : 11689314.0,
"MODULE_TEMPERATURE_MEAN_01_F32" : 43.676177978515625,
"MODULE_TEMPERATURE_MEAN_03_F32" : 43.647125244140625,
"MODULE_TEMPERATURE_MEAN_04_F32" : 42.06298828125,
"PV_CURRENT_MEAN_01_F32" : 8.5247402191162109,
"PV_CURRENT_MEAN_02_F32" : 2.811953067779541,
"PV_ENERGYACTIVE_ACTIVE_SUM_01_U64" : 13201711816.0,
"PV_ENERGYACTIVE_ACTIVE_SUM_02_U64" : 7127100168.0,
"PV_POWERACTIVE_MEAN_01_F32" : 3025.414306640625,
"PV_POWERACTIVE_MEAN_02_F32" : 1153.4793701171875,
"PV_VOLTAGE_MEAN_01_F32" : 354.89813232421875,
"PV_VOLTAGE_MEAN_02_F32" : 410.20578002929688,

Gruß Dennis

Zitat von: Blablubblaber am 20 August 2024, 12:42:53was würde da dagegen sprechen?

Die Tatsache, dass es sich um ein "internes API" handelt, das jederzeit geändert werden kann.

Das spricht eindeutig für eine schnelle und flexible Lösung mit HTTPMOD. Ich bin jedenfalls mit meinem HTTPMOD-Device für meinen Fronius_WR sehr zufrieden, weil es mir eine feinere Kontrolle darüber gibt, welche Werte ich wie oft benötige.

LG

pah

Zitat von: Fredi69 am 19 August 2024, 13:16:34Woran kann es liegen, dass irgendwann nicht mehr alle Werte aktualisiert werden?

Schwer zu sagen ohne mehr Infos.
Mit verbose=4 werden im Log die Timer und API Aufrufe protokolliert.
Setz das bitte mal am Device und poste hier dann die Logzeilen vom Device kurz bevor und nachdem die Werte nicht mehr aktualisiert werden, dann wissen wir mehr.

Zitat von: Prof. Dr. Peter Henning am 21 August 2024, 08:57:35

Zitat von: Blablubblaber am 20 August 2024, 12:42:53was würde da dagegen sprechen?

Die Tatsache, dass es sich um ein "internes API" handelt, das jederzeit geändert werden kann.

Das spricht eindeutig für eine schnelle und flexible Lösung mit HTTPMOD. Ich bin jedenfalls mit meinem HTTPMOD-Device für meinen Fronius_WR sehr zufrieden, weil es mir eine feinere Kontrolle darüber gibt, welche Werte ich wie oft benötige.

Sehe ich auch so, im Modul möchte ich nur die offizielle Fronius Solar API gemäß Doku abfragen.

Ich hatte wegen der Temperaturen bei Fronius nachgefragt.
Die Antwort wird Euch nicht begeistern, aber so ist es nunmal:

ZitatGuten Tag ,
Ich habe heute folgende Rückmeldung von unseren Experten erhalten:
Es sind sogar einige Temperaturen im Sunspec Register Map enthalten jedoch wurde hier entschieden diese nicht zu implementieren.
Aufgrund der Tatsache, dass SolarAPI nicht mehr weiterentwickelt wird, erhalten wir definitiv keine Nachbesserung oder die Möglichkeit, die Temperatur auszulesen.
Es bedauert mich, dass unsere Experten Ihnen in dieser Hinsicht keine positive Antworten geben konnten.
Ich wünsche Ihnen eine schöne Woche.

Also wird es so bleiben wie es ist, also auch keine größeren Änderungen am Modul mehr.
Schade....

Grüße Wolfdieter

Danke für die Nachfrage bei Fronius.

Zitat.. dass SolarAPI nicht mehr weiterentwickelt wird ...

Ist nur zu hoffen, dass es zumindest bei "nicht mehr weiterentwickelt" bleibt und sie es nicht auch noch abdrehen, so wie manch anderer Hersteller seine lokalen Schnittstellen und alle in proprietäre Cloud zwingt.

@dieter114:

Nachdem der Kontakt schon hergestellt ist, bitte ich, gleich noch eine Nachfrage zu stellen.

- Wenn das Fronius Solar-API nicht weiter entwickelt wird: Mit welchem Protokoll sollen künftig die Daten des WR durch die Kunden abgefragt werden?

LG

pah

Hallo PAH, die Frage hatte ich schon gestellt.
Hier die Anttwort:

ZitatGuten Tag ,
vielen Dank für Ihre Rückmeldung.
Das bedeutet nicht, dass Solar API in absehbare Zeit nicht mehr funktionieren wird. Stattdessen wird es in diesem Bereich nicht weiterentwickelt oder daran gearbeitet, neue Veränderung oder Verbesserungen vorgenommen, was sonst der Fall war.

Also die API bleibt einfach so wie sie jetzt ist. Na ja.....
Ist es den nicht irgendwie möglich die Daten die auf dem Dashboard unter Erweitert, Wechselrichter
mit dem Techniker Login zu sehen sind, auszulesen?

Grüße Wolfdieter

Na, die Frage, was denn in Zukunft verwendet werden soll, ist damit aber nicht beantwortet.

Das mit dem Techniker-Login halte ich für ziemlich brisant, weil man damit in die Haftung gegenüber dem Netzbetreiber eintritt.

Liest hier jemand mit, der den WR per Modbus abfragt? Angeblich lassen sich damit alle Daten holen.

Wichtig wäre auch, den minimalen Ladestand des Speichers einstellen zu können. Warum? Im Sommer gibt es immer ein Überangebot an PV, da kann man den Speicher auch bis auf einen Rest von 7% leeren. Im Winter aber drohen wegen der dämlichen Energiepolitik Netzausfälle. Wenn man also eine Netzausfallsicherung haben will, sollte die Notstromreserve im Speicher schon etwas mehr als 7% sein. Man müsste also die Notstromreserve 2x pro Jahr ändern. Und das entweder mit dem Techniker-Login, oder per Modbus.

LG

pah

Also ich habe den Speicher auf min 15% eingestellt wegen meiner Notstromversorgung (Envitec Box).
Wenn weniger im Speicher ist läuft das Ganze nicht einmal zwei Stunden bei mir.
Ok: das ist noch der Testbetrieb, ich arbeite dran.
Und im Winter gelten vermutlich andere Kriterien.

Grüße WDS

Zitat von: Prof. Dr. Peter Henning am 30 August 2024, 15:23:30Liest hier jemand mit, der den WR per Modbus abfragt? Angeblich lassen sich damit alle Daten holen.

Wichtig wäre auch, den minimalen Ladestand des Speichers einstellen zu können. Warum? Im Sommer gibt es immer ein Überangebot an PV, da kann man den Speicher auch bis auf einen Rest von 7% leeren. Im Winter aber drohen wegen der dämlichen Energiepolitik Netzausfälle. Wenn man also eine Netzausfallsicherung haben will, sollte die Notstromreserve im Speicher schon etwas mehr als 7% sein. Man müsste also die Notstromreserve 2x pro Jahr ändern. Und das entweder mit dem Techniker-Login, oder per Modbus.

LG

pah

Hallo pah ich habe die Modbus Anschaltung hinbekommen.
Es wird aber "nur" eine Temperatur übertragen: CabinetTemperature 52,5 Grad, das ist schonmal was.
Wichtiger ist die Möglichkeit damit die Batterierestladung einstellen zu können.
Siehe hier: https://forum.fhem.de/index.php?msg=1295473 und
hier: https://forum.fhem.de/index.php?msg=1297928
Genau so anlegen dann gibt es die Möglichkeit mit set <BYD_Runge> BatConfigReserve 15
auf z.b. 15% Restwert einzustellen; oder eben je nach Jahreszeit dynamisch.

Grüße WDS

Hi, ja genau.
Bitte bei https://forum.fhem.de/index.php?msg=1297928 den Post darüber von mir beachten.

Viele Grüße,
Stefan

Ok, wir kapern hier schon wieder das API Thema mit Modbus Dingen.
Aber ich will noch eine Sache anmerken.

Ich habe gerade nochmal alle Temperatur Register an meinem GEN24 Plus ausprobiert.
Die Register sind hier zu finden:
"Die Register Tabellen sind auf der Fronius Homepage zu finden oder direkt über den Link http://www.fronius.com/QR-link/0006 abrufbar."

Hier meine Tests laut dieser Doku.
40110 40111 2 R 0x03 TmpCab Cabinet Temperature float32 ° C
attr BYD_Runge obj-h40109-reading CabinetTemperature
Ergebnis: geht Temperatur kommt

40112 40113 2 R 0x03 TmpSnk Coolant or Heat Sink Temperature float32 ° C
attr BYD_Runge obj-h40111-reading HeatSinkTemperature
Ergebnis: NaN

40114 40115 2 R 0x03 TmpTrns Transformer Temperature float32 ° C
attr BYD_Runge obj-h40113-reading TransformerTemperature
Ergebnis: NaN

40116 40117 2 R 0x03 TmpOt Other Temperature float32 ° C
attr BYD_Runge obj-h40115-reading OtherTemperature
Ergebnis: NaN

40290 40290 1 R 0x03 1_Tmp Temperature int16 C
attr BYD_Runge obj-h40289-reading Temperature
Ergebnis: -0,0

So jetzt aber zurück zum API Thema.

Gruß,
Stefan

Halo Stefan,
das ist richtig aber es kommt nur eine der vier Temperaturen.
Alle anderen sind angelegt aber leer.
Nützt also nichts.

Grüße WDS

Danke für das Beispiel - allerdings sind viele der Readings im ModbusAttr-Device mit absurden Werten besetzt, z.B.

ACFrequency 1418867214222529630043168246954196992.0

und der set-Befehl für die minimale Speicherladung bewirkt: Gar nichts.

Muss ich also selbst noch Arbeit hineinstecken - bei 102 Seiten der Fronius-Modbus-Doku wird das allerdings ne Weile dauern.

Betreffend die Temperatur: Wenn das Ding wirklich in Gefahr ist, hat das möglicherweise mit einem Ausfall der internen Sensoren zu tun. Es macht also wenig Sinn, auf die interne Temperaturmessung zu setzen. Besser wäre, am Kühlkörper (oder am Auslass des Ventilators) einen externen Temperatursensor zu platzieren.

LG

pah

Hi pah,

vielleicht sollten wir dazu mal nen eigenen Thread aufmachen.
Hier gehts ja eigentlich um die Fronius API.
Eventuell passt es hier bei Fronius Modbus besser, auch wenn es da nicht um die BYD Batterie geht.
https://forum.fhem.de/index.php?topic=46685.0

Ich benutze
BatConfigMaxChargeWatt
BatConfigMaxDischargeWatt
BatConfigMaxEnabled
ohne Probleme.

Das mit der Reserve kam später hinzu und ich verwende es nicht da ich mit den settern oben arbeite.
Ich kann es aber gern mal testen.
War hier von Fred_Feuerstein und er sagte es geht bei ihm.
Bei mir steht der richtige Wert "5" da.
Ob ich den übersteuern kann weiß ich nicht, sollte laut Fred gehen.
Hast du es im Fronius WR auf Auto stehen wie ich vorher beschrieben hatte?

Gruß,
Stefan

SO, hab es am Laufen. Fehler lag bei mir, ich hatte das Datenmodell am WR nicht auf "float" umgestellt.

@stefanru: Ja, den Wert BatConfigReserve kann man überschreiben, geht problemlos. Ich verstehe nicht so ganz, wie Du mit BatConfigMaxChargeWatt etc. Deine Anlage steuerst.

Insgesamt habe ich vom Systemverhalten her den Eindruck, dass mit dem ModbusAttr-Modul eine hohe Systemlast erzeugt wird. Das müsste man systematisch vergleichen mit dem API-Zugriff (fronius-Modul und HTTPMOD).

LG

pah

Hi pah,

super, gut das es jetzt geht.
Mit den Parametern steuere ich die Ladung / Entladung.

Im Sommer langt die Baterie locker und ich begrenze die Ladung wenn für den nächsten Tag genügend PV Ertrag vorhergesagt ist auf 80% max.
Also setze ich BatConfigMaxChargeWatt auf 0 wenn 80% erreicht.
Außerdem lade ich auch schon vorher je nach Vorhersage mit weniger Watt um die Batterie zu schonen.

Im Winter möchte ich die Batterie nicht so lange auf 5% haben. Also hole ich vom Forecast Modul den Verbrauch bis zum nächsten Sonnenaufgang und falls die Batterie nicht reicht stoppe ich die Entladung bei 25% mit BatConfigMaxDischargeWatt = 0.
Ich gebe es wieder frei wenn es rechnerisch reicht zum nächsten Morgen.

Das funktioniert sehr gut soweit und die Batterie wird nur gestresst wenn die Vorhersage schlecht ist und steht nie sehr lange bei 100% oder 5% rum.
Das einzige was mir alle 3 - 4 Tage in die Suppe spuckt ist dass die BYD Batterie mit LiFePO4 und der sehr flachen Voltkurve den SOC falsch berechnet und man auf einmal doch bei 100% landet.
Das ist aber nicht tragisch man soll die LiFePO4 ja sowieso alle paar Tage mal auf 100% bringen um den SOC wieder zu kalibrieren.

Gruß,
Stefan

OK, also sollte man das ModBusAttr-Modul mit Interval 0 verwenden, denn die Daten über den SOC bekommt man ja schon mit dem API. Ich muss mal etwas stöbern, um herauszufinden, welchen Datenverkehr das Modul produziert, wenn man _nicht_periodisch abfragt.

Evtl. würde ich das Modul auf eine andere FHEM-Installation auslagern, und in meinem Wechselrichter-Device ein Set-Kommando so umbiegen, dass es auf der externen Installation ein set beim ModBusAttr auslöst.

LG

pah

Hi pah,

mit der Last könntest du Recht haben.
Ich habe einen 4er Raspberry und der ist immer so zwichen 0,5 und 1 an Load.
Also ein Kern ausgelastet.
Bin schon am überlegen einen 5er zu kaufen, aber man kann natürlich auch mal schauen woher die Last kommt.

Ich habe nie getestet ob es von den API Calls, SolarForecast, DWD mit MOSIMIX, Modbus oder BYDBox kommt.
Habe halt alles ziemlich gleichzeitig eingebaut und auch den Raspberry ersetzt.
Wenn ich etwas Zeit habe mache ich mal jeweils eins der Dinge aus und schaue ob ich eine Reduzierung der Last sehe.

Gruß,
Stefan

Ich habe sogar noch einen zweiten Grund, für den WR eine Ansteuerung über Modbus anzustreben. Derzeit übermittele ich beim solaren Überschussladen alle 5 Sekunden die Daten aus dem Wechselrichter an meine Wallbox - und zwar per HTTP. Das belastet FHEM ziemlich. Ich denke hier an ein kleines ausgelagertes System (sagen wir einen Pi Zero), der die Modbus-Sachen übernimmt.

Als Software dafür käme evcc in Frage - vorausgesetzt, ich könnte dem auch übermitteln, die Batteriesteuerung zu machen.

LG

pah

Hi Pah,

ja EVCC ist fein. Nutze ich auch und kann man per MQTT wieder an FHEM anbinden.
Muss aber zugeben ich setze da nichts, sondern hole nur Daten ab.
Laut Doku geht wohl beides: https://docs.evcc.io/docs/reference/configuration/mqtt.
Es ist schön, dass man in FHEM jegliche protokolle mit allen anderen verbinden kann, solange man dabei noch durchblickt und keine Endlosschleifen baut ;-)

Gruß,
Stefan

Zitat von: Prof. Dr. Peter Henning am 03 September 2024, 09:04:56Derzeit übermittele ich beim solaren Überschussladen alle 5 Sekunden die Daten aus dem Wechselrichter an meine Wallbox - und zwar per HTTP. Das belastet FHEM ziemlich.

Mache ich auch, durchschnittlicher Load am RaspPi Model 2 ist aber nur 0.06 ,  das hätte ich für mich jetzt nicht als "ziemlich" klassifiziert.
Meine fhem Instanz macht parallel noch einige andere Sachen ("259 defined entities" laut log). Ich habe aber auch viel mit event-(aggregator|on-change-reading|...) optimiert.

u.U. driften wir hier wirklich ab, aber die Belastung eines Systems hängt doch von vielen Dingen ab.
Ich verwende einen PI4 als "Hauptrechner", die 1Wire Geschichten mache ich mit dem Modul von PAH auf einem externen Pi2.
Seit der Umstellung von OWFS/OWServer auf OWX läuft das Teil mit 0,02% also gerade mal so...
Der PI4 läuft bei "371 defined entities" auch nur mit 0,18%.
Aber die eingentlich Fragen hier sind:

@pah warum alle 10 Sek Daten vom Speicher zur Verarbeitung? Ich mache das alles mit evcc und bin bei 30 Sek Verarbeitungszeit in evcc und "Auslesezeiten" meiner Module von 1 Min oder noch mehr. Ok, es wird bei schnell durchziehenden Wolken auch mal kurz aus dem Speicher zum Auto übertragen, aber in der Gesamtbetrachtung spielt das doch keine große Rolle. Das Auto wird damit prima im PV Modus solar geladen. Ich bin damit jedenfalls zufrieden.

@stefanru versuch einmal freezemon und schalte zusätzlich successive alles aus und wieder an. Dann findest du auch die Probleme, mir hat es jedenfalls gut geholfen.

Grüße aus Norddeutschland
WDS

Zitat von: dieter114 am 17 September 2024, 21:10:06@pah warum alle 10 Sek Daten vom Speicher zur Verarbeitung?

Der Fronius-Wechselrichter benötigt spätestens alle 7 Sekunden neue Daten, sonst stellt er das solare Überschussladen ein.

LG

pah

Hallo in die Runde,

ich hab da mal ne Frage zu den ausgelesenen Daten.
Seit dem Update auf die Version "Installiert: ROW 1.33.7-1 " meines SymoGen24 sind die Werte vom PowerFlow_Inverters_1_E_Total nicht mehr plausibel.
Bis vor dem Update habe ich diesen saldierenden Zähler genutzt um mit dem ElectricityCalculator die erzeugte Solarstrommenge zu berechnen.
Das hat eigentlich gut funktioniert und war auch im Vergleich zum Solarweb von Fronius halbwegs gleich.
Seit dem Update habe ich das Gefühl die rechnen neuerdings die vom WR erzeugte Energie aus dem Speicher in der Nacht dazu.
Jedenfalls habe ich morgens ca 4kWh erzeugten Solarstrom in der Dunkelheit.
Das kann so nicht sein. Wie berechnet Ihr den die erzeugte Solarmenge?
Oder war mein Ansatz von vornherein falsch?

LG WDS

Hi Dieter,

ich benutze für die Solar Erzeugung die Readings PowerFlow_Site_P_PV.
Da ich einen GEnb24 und Symo habe addiere ich sie in einem Inverter Dummy.
Dann benutze ich wie du einen ElectricityCalculator.

Ich hatte 1.33.7.1 nur kurz drauf.
Der Fehler mit dem Zertifikat hat mich genervt und ich habe es gleich weider zurück gerollt.
Seitdem warte ich dass das gefixed wird.

Gruß,
Stefan

Hallo Stefan,
Das Reading PowerFlow_Site_P_PV ist aber eine aktuelle Leistung und kein saldierender Zähler.
Integriertst du die vorher noch auf, oder wie geht das dann mit dem ElectricityCalculator.

LG WDS

Hi Dieter,

du hast recht ich habe mich verlesen im Befüller des Dummie Inverters.

Ich benutze User_Produced_PV von beiden WRs für das befüllen des Solar Werts und den dann im ElectricityCalculator.
Und User_Produced_PV erzeuge ich als userReadings mit
"User_Produced_PV:PowerFlow_Site_P_PV.* integral {ReadingsVal("$name","PowerFlow_Site_P_PV","0")/3600000},"
direkt in den Wechselrichtern.

Gruß,
Stefan

Ich wundere mich ein wenig darüber, dass Ihr dieses "ElectricityCalculator" -Modul benutzt. Das geht einfacher mit dem statistics-Modul.

LG

pah

Hallo pah,
wie bekommst du mit statistics das hier "auf die Schnelle" mal hin?
Ich mache das mit 3 ElectricityCalculatoren und ein paar Dummys

@stefanru: habe das Integral eingefügt, sollte nun endlich fehlerfrei laufen. -Danke

LG WDS

Erkläre ich heute nachmittag, jetzt ist Sport angesagt.

LG

pah

OK, hier die Anleitung.

1. Ein statistics-Device anlegen, wenn nicht schon eines vorhanden ist - es braucht tatsächlich nur eines für die gesamte FHEM-Installation. In der Definition tauchen alle anderen Devices auf, die man auswerten möchte

Zitatdefine global.stat statistcs E..consumption|E..production|Wally|nt5000|sg6000

2. Diesem Device die nötigen Attribute geben:

Zitatattr global.stat deltaReadings energy

weil ich das reading "energy" in den genannten Devices überwachen will. In diese kommagetrennte Liste muss also alles hinein, was ich täglich, monatlich, jährlich aufzeichnen will. Integration, Preisentwicklung etc. muss also im Quelldevice bestimmt werden, das macht das statistics-Device nicht.

Zitatattr global.stat excludedReadings .*(voltage|power)

weil die sonst auch ausgewertet werden.   

ZitatsingularReadings
.*:energy:Delta:(Day|Month|Year)

damit die Daten auch als einzelne Readings und nicht nur als Übersichtszeile angelegt werden.

3. In jedem der bei der Definition von global.stat genannten Devices tauchen dann neue Readings auf, z.B.

ZitatstatEnergy Hour: 0.000 Day: 0.000 Month: 13.703 Year: 661.211 (since: 2024-09-30 )
statEnergyDay 0.000
statEnergyDayLast 4.406
statEnergyLast Hour: 0.000 Day: 4.406 Month: 129.301 Year: - (since: 2024-09-30 )
statEnergyMonth 13.703
statEnergyMonthLast 129.301
statEnergyYear 661.211

sowie natürlich am Jahresende statEnergyYearLast. Im Beispiel - gerade aus meiner Wallbox geholt - sind natürlich ziemlich viele Werte Null, weil ich das Auto da heute noch nicht dran hatte.

Die "Last"-Werte sind natürlich jeweils die aus der letzten Periode.

4. Klar, dass die Werte für die gegenwärtige Periode erst einmal nicht stimmen. Die kann man aber problemlos mit

Zitatset gobal.stat <device> <reading> <period> <value>

manuell auf den richtigen Wert bringen.

LG

pah

Hallo pah,
danke für die umfangreiche Erklärung.
Das probiere ich aus, will endlich einmal das Modul Statistics verstehen....
Aber im Grunde mache ich mit den 3 ElectricityCalculatoren nichts anderes.
Nur der Aufbau ist anders und so wie es aussieht sogar umfangreicher.

LG WDS

Ja, aber ...

Damit hat man für jeden physisch vorhandenen Zähler zwei Devices, mit statistics gibt es die Readings direkt im Zählerdevice

LG

pah

hallo zusammen,

ich habe einen Gen24 und habe noch das alte Modul von Michael Winkler im Einsatz.
Dort hängt sich das "Auslesen" von Zeit zu Zeit auf, welches durch ein modify wieder instand gesetzt wird...

Ist dieses Verhalten mit dem überarbeiteten Modul behoben?

Vielen Dank,
NM

Hallo NewMatic,

bei mir läuft das "neue" Modul seit Monaten bisher ohne Probleme.

LG WDS

Bei mir läuft das Modul bisher auch problemlos mit Fronius Symo 17.5-3-M.
Allerdings bekomme ich seit der Zeitumstellung heute keine Daten mehr für MPPT1* und MPPT2*, letzte Aktualisierung 2024-10-27 02:00:02.
Die anderen Readings laufen wie gewohnt.
defmod vom Device und Restart vom Fronius-Datamanager haben nicht geholfen.

Hat das auch jemand und eine Idee zur Lösung?

Zitat von: capo am 27 Oktober 2024, 12:05:56Bei mir läuft das Modul bisher auch problemlos mit Fronius Symo 17.5-3-M.
Allerdings bekomme ich seit der Zeitumstellung heute keine Daten mehr für MPPT1* und MPPT2*, letzte Aktualisierung 2024-10-27 02:00:02.
Die anderen Readings laufen wie gewohnt.
defmod vom Device und Restart vom Fronius-Datamanager haben nicht geholfen.

Hat das auch jemand und eine Idee zur Lösung?

Bei mir leider genau dasselbe, ich erinnere mich dass dieses Modul seit ich es einsetze (also auch schon unter dem ursprünglichen Ersteller) immer Probleme machte wenn mal wieder Zeitumstellung war. Ich dachte, das sei gefixt, aber leider scheint das nicht der Fall zu sein, denn ich bekomme keine validen Daten für die Werte aus dem "Archiv", interessant sind für mich die Werte Mppt1_DC_W und Mppt2_DC_W um die einzelnen Werte für West und Ost zu erhalten.

hat jemand eine Idee? Vielen Dank!

Ich hatte das Problem letztes Jahr auch am Tag der Zeitumstellung, ich vermute heute wieder und ich bin so wie letztes Jahr aber nicht zu Hause, um den Fehler zu suchen ::)
Letztes Mal war am Folgetag wieder alles ok.

Ich denke, der Datalogger im Fronius bzw die Funktion für die Archivdaten hat ein Problem mit dem heutigen 25 Stundentag.

Stellt bitte kurzzeitig verbose am device auf 5, um die Kommunikation mit dem Fronius im Log zu haben, dann wissen wir mehr.

Zitat von: fichtennadel am 27 Oktober 2024, 14:55:00Ich hatte das Problem letztes Jahr auch am Tag der Zeitumstellung, ich vermute heute wieder und ich bin so wie letztes Jahr aber nicht zu Hause, um den Fehler zu suchen ::)
Letztes Mal war am Folgetag wieder alles ok.

Ich denke, der Datalogger im Fronius bzw die Funktion für die Archivdaten hat ein Problem mit dem heutigen 25 Stundentag.

Stellt bitte kurzzeitig verbose am device auf 5, um die Kommunikation mit dem Fronius im Log zu haben, dann wissen wir mehr.

stimmt, ist wieder alles i.O.

Freut mich, dass es heute wieder ok ist.

Zitat von: fichtennadel am 27 Oktober 2024, 14:55:00Stellt bitte kurzzeitig verbose am device auf 5, um die Kommunikation mit dem Fronius im Log zu haben, dann wissen wir mehr.

Hat jemand verbose level 4 oder 5 Logauszüge von gestern als das Problem auftrat?

Hallo,

sorry leider hab ich kein verbose level 4 aufwärts vom Sonntag, wenn ich das jetzt einstelle bringt es vermutlich nichts mehr, oder?

Was ich beobachtet habe:
- seit Montag sind die Werte wieder da, sie fehlen also nur für den Sonntag in FHEM
- im Fronius Solarweb sind die Werte für Sonntag vorhanden, ich nehme also an, dass sie dem WEchselrichter prinzipiell zur Verfügung stehen.

ok, schade, jetzt bringt's nichts mehr, die Antwort am Sonntag vom WR auf den Request wäre spannend gewesen.

Letztes Jahr konnte ich dann rückwirkend die fehlenden Archivwerte abfragen, nur am Tag der Zeitumstellung auf Winter ging es nicht.

In der Fronius App konnte ich die Werte am Sonntag auch sehen, ich vermute die verwenden zum Senden ans Backend eine andere Funktion.

Nächstes Jahr muss ich mir einen Reminder stellen, dass ich vor der Fahrt in die Herbstferien verbose hochdrehe ;D

Version 0.2 in meinem Contrib (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/98_fronius.pm?format=txt)

Die Version behebt hoffentlich ein Problem mit hin und wieder fehlenden Werten für Storage und Inverter (https://forum.fhem.de/index.php?topic=139793.0).

Es gibt auch einen neuen set Befehl für "GetActiveDeviceInfo", die fehlenden DeviceInfo_* Werte sind zumindest eine der Ursachen für das vereinzelte Ausbleiben der Storage und Inverter Werte.

Falls es doch wieder auftritt: ein "set <device> GetActiveDeviceInfo" kann man versuchen, falls das nicht hilft dann ein "set <device> RestartInterval" und als letzter Ausweg das define neu ausführen ("defmod <device> fronius <ip>").
Und bitte ein Log mit verbose=5

Vielen Dank, lieber fichtennadel! Ich probiere das so bald wie möglich aus :)

Zitat von: fichtennadel am 16 November 2024, 20:22:39Die Version behebt hoffentlich ein Problem mit hin und wieder fehlenden Werten für Storage und Inverter (https://forum.fhem.de/index.php?topic=139793.0).

Gleich mal geholt und gestartet. Momentan kommen alle Werte rein, aber die hatten sich ja eh schon selbst geheilt. Ich habe ein Auge drauf und melde mich, falls was hakt.

Ein riesiges Danke Schön für den schnellen Fix!

Das mit der Kontinuität des Fronius ist so eine Sache:
Mal läuft alles problemlos durch und machmal dauert es ewig lange bis wieder Daten kommen.
Wie schon beschrieben verwende ich nur die Readings PowerFlow_Site_P_PV, PowerFlow_Site_P_Akku
PowerFlow_Site_P_Grid und rechne jede Minute mit UserReadings damit was zusammen.
Die drei Werte werden zuverlässig jede Minute (bisher jedenfalls) erzeugt.
Alle anderen Werte werden oft nur alle 10 Minuten oder noch später erneuert.

LG WDS

Das steht aber so auch in der Dokumentation von Fronius. Einfach mal lesen.

LG

pah

Neue Version 0.3 für stabileren Neustart (https://forum.fhem.de/index.php?topic=139206.msg1330758#msg1330758) im contrib (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/98_fronius.pm)

Zitat von: dieter114 am 05 Dezember 2024, 16:19:08Das mit der Kontinuität des Fronius ist so eine Sache:
Mal läuft alles problemlos durch und machmal dauert es ewig lange bis wieder Daten kommen.
Wie schon beschrieben verwende ich nur die Readings PowerFlow_Site_P_PV, PowerFlow_Site_P_Akku
PowerFlow_Site_P_Grid und rechne jede Minute mit UserReadings damit was zusammen.
Die drei Werte werden zuverlässig jede Minute (bisher jedenfalls) erzeugt.
Alle anderen Werte werden oft nur alle 10 Minuten oder noch später erneuert.

LG WDS

Hallo Dieter
Mein Fronius mag einfach keine Kumulativen Werte hergeben, daher hört sich das mit deinen Berechnungen interessant an.
Kannst du vielleicht deine Userreadings posten?
Dann bräuchte ich das Rad nicht neu zu erfinden.
Vielen Dank
LG
Markus

Hallo Markus,

aber gern doch. Siehe:
https://wiki.fhem.de/wiki/Solaranlage_Komplettbeispiel_Fronius_BYD
das Ding ist von mir.
Eigentlich sollte dort alles drinstehen.
Es hat bisher noch keiner etwas auf Funktionalität darin geprüft.
Freue mich über Rückmeldungen.

LG Wolfdieter

Zitat von: dieter114 am 20 Januar 2025, 11:06:16Es hat bisher noch keiner etwas auf Funktionalität darin geprüft.

Aber doch - ich war nur gesundheitlich lahmgelegt, sonst hätte ich dazu schon diverse Dinge geäußert.

Also mal in Kürze:
1. Man benötigt keineswegs das Technician-Passwort des WR. Es reicht, dass der Installateur die Modbus-Verbindung freischaltet.
2. Wenn Du sowieso HTTPMOD benutzt, erübrigt sich das Fronius-Modul komplett.
3. Vier verschiedene "ElectricityCalculator" ? Das geht viel einfacher über ein einziges statistics Device, das sollte als Anmerkung in den Text.
4. Man benötigt keineswegs evcc, eventuell kann das sogar die Wallbox selber steuern.
5. Bei den ganzen Quellcodes in der Wiki-Seite empfiehlt sich, den Ausklappmechanismus zu nutzen, beispiel hier https://wiki.fhem.de/wiki/GoE_Charger

LG

pah

Hallo Dieter

Vielen Dank, ich werd mich da mal durcharbeiten, bitte rechne aber nicht schon gleich morgen mit feedback, ich hab zur Zeit recht viel um die Ohren, kann eine Weile dauern, bis ich dazu komme.
Allerdings gleich noch eine Frage nach dem drüberfliegen, wie hast du der BYD box die IP assigned? über DHCP oder statisch? Wenn zweites, wie hast du das geschafft?
Bei mir war die Box nicht übers Netzwerk ansprechbar, dann habe ich in ein paar Foren gelesen, dass die Netzwerkverbindung nur für die Fernwartung durch BYD nutzbar ist, worauf ich den switchport ganz schnell disabled habe..... ;)
Wenn das aber bei dir funktioniert, werde ich da vermutlich nochmal einen Anlauf nehmen.

Auf jeden Fall danke für die Doku.

LG
Markus

Zitat von: Paradisebaker am 20 Januar 2025, 19:15:47über DHCP

... aber mit immer derselben Adresse. Das kann man in der FritzBox und anderen DHCP-Servern konfigurieren.

Ich werde demnächst auch meinem Speicher den Durchgriff ins Netz verbieten - das Thema "chinesischer Zugriff auf KRITIS" kommt gerade richtig ins Rollen.

Ob ich das auch für den Wechselrichter mache, hängt von den weiteren Gesetzgebungsvorgängen ab. Ich werde nämlich Fronius nicht gestatten, im Auftrag von wem auch immer meinen WR abzuregeln.

LG

pah

Hallo Pah
Da geb ich dir vollkommen recht.
Nach einer DHCP-Reservierung auf meiner ASA war der nächste Schritt einen ACL-Eintrag zu machen, damit der BYD nicht nach Hause telefonieren darf.
Auch das mit dem Wechselrichter abregeln sehe ich extrem kritisch, damit könnte der Energieprovider dich ja quasi dazu zwingen, seinen Strom zu kaufen, obwohl die Sonne scheint.
Eine Null-Einspeisung könnte ich nachvollziehen, es geht ja um die Netzstabilität.
Aber wenn ich autark sein könnte und dann trotzdem Strom beziehen muss, das geht gar nicht.
LG
Markus

Hallo pah, hallo Markus,

den Zugriff auf den BYD habe ich über die FritzBox DHCP gemacht aber auch gleich die "totale Kindersperre" eingestellt.
Also ist das Teil nur im Intranet zu erreichen.
Zu deinen Anmerkungen
Punkt 1 u. 3 werde ich einfügen - na klar.
Punkt 2: ich lese damit nur die String-Werte aus weil das Fronius Modul sie nicht hergibt.
Das kann aber auch weggelassen werden. Schreibe ich dazu.
Alles Andere über das Fronius Modul. Es ist einfacher als HTTPMOD und für mich schnell genug.
Wenn alles im 60 Sek Takt ausgelesen wird, weicht es völlig.
EVCC benutze ich nun einmal weil ich anders nicht an die Daten des Fahrzeugs herankomme. (KIA PHEV)

Punkt 5 : Wie geht das? Habe kein Template oder irgendwas dazu gefunden.

LG Wolfdieter

Zitat von: Prof. Dr. Peter Henning am 21 Januar 2025, 09:54:28Ob ich das auch für den Wechselrichter mache, hängt von den weiteren Gesetzgebungsvorgängen ab. Ich werde nämlich Fronius nicht gestatten, im Auftrag von wem auch immer meinen WR abzuregeln.

Das sehe ich genauso, bleibt nur die Frage ob ein renomierter Hersteller aus Europa sich auf solche Sachen einlässt.
Letztendlich war das der Grund warum ein Fronius und nicht ein "Chinese" bei mir an der Wnad hängt...
Mit der FritzBox kann eigentlich der Zugriff nach außen recht dezidiert eingestellt werden.
So müßte doch die Freigabe einzelner Ports ausreichen um Daten zu Fronius zu senden, aber alles Andere zu sperren?
Denn die Daten im SolarWeb von Fronius können selbst in der kostenlosen Version als Excel-Tabelle abgefragt werden.
Und wenn sie nur zur Kontrolle der eingenen Messungen dienen.
Darauf jedenfalls möchte ich nicht verzichten.

LG WDS

Zitat von: dieter114 am 21 Januar 2025, 21:52:00Punkt 5 : Wie geht das? Habe kein Template oder irgendwas dazu gefunden.

Sie Dir doch bitte den Quellcode für die Wiki-Seite zum goE-charger an.

LG

pah

Nach update des Fronius geht der Wechselrichter ständig auf status disconnected und gibt nur sporadisch Werte her.
Ich hatte ein update von 1.35.4-1 auf 1.35.8-1 gemacht.
Nach einem fhem shutdown restart ist der WR wieder eine zeitlang erreichbar, dann der gleiche sch....
Ich habe jetzt mal wieder auf 1.35.4-1 zurückgerollt, hat aber auch nichts gebracht.

LG
Markus

Funktioniert denn die Webpage des Wechselrichters selbst noch? Die verwendet auch das API.

LG
Georg

ja, die geht einwandfrei.
Aber evtl hat Fronius was an der API geändert, so dass dein Modul nicht mehr funktioniert?

LG
Markus

Der Fehler ist bekannt aber noch nicht gefixt.
https://forum.fhem.de/index.php?topic=141037.msg1336344#msg1336344

LD WDS

Zitat von: Paradisebaker am 16 März 2025, 20:28:51Aber evtl hat Fronius was an der API geändert, so dass dein Modul nicht mehr funktioniert?

Also auf https://www.fronius.com/de/solarenergie/installateure-partner/technische-daten/alle-produkte/anlagen-monitoring/offene-schnittstellen/fronius-solar-api-json- ist weiterhin nur die V1, dann war es wenn dann eine undokumentierte Änderung.

Eher wird es der Fehler sein, den WDS anspricht.

Aber siehst du Fehlermeldungen im FHEM Log? Evtl auch mal kurzzeitig verbose=4 am Device setzen und dann im Log nachsehen und parallel dazu die Webpage des Wechselrichters beobachten, ob da auch die Fehler auftreten.

Hallo Fichtennadel

Sorry für die späte Antwort, die Chefin hat mich zur Gartenarbeit verdonnert......
Habe folgende Einträge im FHEM log, ich würde jetzt mal annehmen, dass es am http vs. https liegen könnte?
(Die public IP bitte ignorieren, ist eine Besonderheit in meinem LAN, wird nur intern benutzt)

LG
Markus



2025.03.24 18:06:00 3: [GEN24] [fronius_Parse] [GetPowerFlowRealtimeData] ERROR=http://165.114.160.1/solar_api/v1/GetPowerFlowRealtimeData.fcgi: Too many redirects
2025.03.24 18:06:00 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 2203) line 1.
2025.03.24 18:06:00 3: eval: {sprintf("%.0f",(ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1","")>0?ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1",""):0))}
2025.03.24 18:06:02 3: [GEN24] [fronius_Parse] [GetStorageRealtimeData] ERROR=http://165.114.160.1/solar_api/v1/GetStorageRealtimeData.cgi?Scope=System&DeviceId=0: Too many redirects
2025.03.24 18:06:02 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 2213) line 1.
2025.03.24 18:06:02 3: eval: {sprintf("%.0f",(ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1","")>0?ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1",""):0))}
2025.03.24 18:06:04 3: [GEN24] [fronius_Parse] [GetMeterRealtimeData] ERROR=http://165.114.160.1/solar_api/v1/GetMeterRealtimeData.cgi?Scope=System&DeviceId=0: Too many redirects
2025.03.24 18:06:04 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 2224) line 1.
2025.03.24 18:06:04 3: eval: {sprintf("%.0f",(ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1","")>0?ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1",""):0))}
2025.03.24 18:06:06 3: [GEN24] [fronius_Parse] [GetInverterRealtimeData_System] ERROR=http://165.114.160.1/solar_api/v1/GetInverterRealtimeData.cgi?Scope=System: Too many redirects
2025.03.24 18:06:06 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 2234) line 1.
2025.03.24 18:06:06 3: eval: {sprintf("%.0f",(ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1","")>0?ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1",""):0))}
2025.03.24 18:06:06 3: [GEN24] [fronius_Parse] [GetInverterRealtimeData_3P] ERROR=http://165.114.160.1/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=3PInverterData: Too many redirects
2025.03.24 18:06:06 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 2244) line 1.
2025.03.24 18:06:06 3: eval: {sprintf("%.0f",(ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1","")>0?ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1",""):0))}
2025.03.24 18:06:06 3: [GEN24] [fronius_Parse] [GetInverterRealtimeData_Common] ERROR=http://165.114.160.1/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=CommonInverterData: Too many redirects
2025.03.24 18:06:06 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 2254) line 1.
2025.03.24 18:06:06 3: eval: {sprintf("%.0f",(ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1","")>0?ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1",""):0))}
2025.03.24 18:06:06 3: [GEN24] [fronius_Parse] [GetInverterRealtimeData_Cumulation] ERROR=http://165.114.160.1/solar_api/v1/GetInverterRealtimeData.cgi?Scope=Device&DeviceId=1&DataCollection=CumulationInverterData: Too many redirects
2025.03.24 18:06:06 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 2264) line 1.
2025.03.24 18:06:06 3: eval: {sprintf("%.0f",(ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1","")>0?ReadingsVal("GEN24","PowerFlow_TOTAL_ENERGY_Values_1",""):0))}


OK, anscheinend hat meine simple Änderung im 98_fronius.pm funktioniert, ich hab einfach alle http:// , die was mit dem WR zu tun haben könnten, mit https:// ersetzt.
Die readings sind wieder da und der Fronius geht auch nicht mehr auf disconnected, nach einem shutdown restart gibt es auch keine errors mehr im log.

Noch ein update hinterher, nachdem das jetzt so schön funktioniert hat, war ich so mutig, gleich wieder mal auf die neueste 1.35.8-1 zu gehen.
und alles funktioniert immer noch, war also wirklich nur der redirect zu https.
@fichtennadel, für mich funktioniert das jetzt so, aber evtl kannst du für zukünftige Versionen von deinem modul ein attribut "HTTPS" einbauen?
Ich bin mir relativ sicher, dass andere auch noch darüber stolpern.
Hier die Zeilen, wo ich http mit https ersetzt habe:

  # JSON Auswertung
  if ($type eq "GetAPIVersionInfo") {
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . "/solar_api/GetAPIVersion.cgi";
  }
  elsif ($type eq "GetPowerFlowRealtimeData") {
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . $hash->{helper}{VARS}{FroniusBaseURL} . "GetPowerFlowRealtimeData.fcgi";
  }
  elsif ($type eq "GetStorageRealtimeData") {
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . $hash->{helper}{VARS}{FroniusBaseURL} . "GetStorageRealtimeData.cgi?Scope=System&DeviceId=$SendData";
  }
  elsif ($type eq "GetMeterRealtimeData") {
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . $hash->{helper}{VARS}{FroniusBaseURL} . "GetMeterRealtimeData.cgi?Scope=System&DeviceId=$SendData";
  }
  elsif ($type eq "GetActiveDeviceInfo") {
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . $hash->{helper}{VARS}{FroniusBaseURL} . "GetActiveDeviceInfo.cgi?DeviceClass=System";
  }
  elsif ($type eq "GetInverterRealtimeData_System") {
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . $hash->{helper}{VARS}{FroniusBaseURL} . "GetInverterRealtimeData.cgi?Scope=System";
  }
  elsif ($type eq "GetInverterRealtimeData_Cumulation") {
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . $hash->{helper}{VARS}{FroniusBaseURL} . "GetInverterRealtimeData.cgi?Scope=Device&DeviceId=$SendData&DataCollection=CumulationInverterData";
  }
  elsif ($type eq "GetInverterRealtimeData_Common") {
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . $hash->{helper}{VARS}{FroniusBaseURL} . "GetInverterRealtimeData.cgi?Scope=Device&DeviceId=$SendData&DataCollection=CommonInverterData";
  }
  elsif ($type eq "GetInverterRealtimeData_3P") {
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . $hash->{helper}{VARS}{FroniusBaseURL} . "GetInverterRealtimeData.cgi?Scope=Device&DeviceId=$SendData&DataCollection=3PInverterData";
  }
  elsif ($type eq "GetArchiveData") {
    my $today = time;
    my $StartDate = strftime "%Y-%m-%dT%H:%M:00Z", gmtime($today - 300); # Fronius Solar API V1 Doku - "...intervals which can be set between 5 and 30 minutes..."
    my $EndDate = strftime "%Y-%m-%dT%H:%M:00Z", gmtime($today);
    $SendUrl   = "https://" . $hash->{helper}{VARS}{FroniusIP} . $hash->{helper}{VARS}{FroniusBaseURL} . "GetArchiveData.cgi?Scope=System&StartDate=$StartDate&EndDate=$EndDate&Channel=Current_DC_String_1&Channel=Current_DC_String_2&Channel=Voltage_DC_String_1&Channel=Voltage_DC_String_2&Channel=EnergyReal_WAC_Sum_Produced&Channel=EnergyReal_WAC_Minus_Absolute&Channel=EnergyReal_WAC_Plus_Absolute&Channel=PowerReal_PAC_Sum";
  }

LG
Markus

ok, dann ist das mit Sicherheit der redirect http->https, Danke für die Hinweise und Versuche.

Ich erstelle eine Version, mit der https über ein Attribut am Device einschaltbar ist.

Interessanterweise läuft das fronius Modul bei mir noch einwandfrei, obwohl ich mit dem HTTPMOD Modul mit http NICHT mehr auf den WR komme (GEN24)

Zitat von: fichtennadel am 24 März 2025, 19:53:14ok, dann ist das mit Sicherheit der redirect http->https, Danke für die Hinweise und Versuche.

Ich erstelle eine Version, mit der https über ein Attribut am Device einschaltbar ist.

Neue Version 0.4 mit Attribut useHTTPS (0/1) im contrib (https://svn.fhem.de/trac/browser/trunk/fhem/contrib/98_fronius.pm)
Optional kann auch sslargs gesetzt werden, siehe Beschreibung in https://wiki.fhem.de/wiki/HttpUtils

Hi Fichtennadel
Ich habe das grade getestet, funktioniert wie gewollt.
Das neue modul eingespielt, sicherheitshalber mit einem shutdown restart neu eingelesen, per default ist der Fronius ruckzuck auf disconnected gegangen.
Dann das attribute useHTTPS auf 1 gesetzt und sofort war der WR wieder connected !  :)
Super!

Vielen Dank für die schnelle Reaktion, meine Kollegen waren begeistert von dem speed, mit dem hier Lösungen geschaffen werden.

LG
Markus

was mich etwas verwirrt:

- Mein WR = Fronius GEN24 10 mit 1.35.8-1
- Meine "alte" 98_fronius.pm funktioniert einwandfrei noch mit http
- Der Zugriff über HTTPMOD funktioniert weder mit http noch mit https

Vlt. liegts auch nur an den sslArgs bzw. an der sslVersion ?

Standardmäßig verwende ich global -> sslVersion -> TLSv12:!SSLv3

Was macht denn 98_fronius.pm anders als HTTPMOD ?

Spannend, denn im Kern verwenden beide die fhem Funktion HttpUtils_NonblockingGet

Hast du schon mal verbose am httpmod device hochgedreht? Vielleicht lässt sich aus den Logs was rauslesen.

Zitat von: fichtennadel am 27 März 2025, 13:53:51Hast du schon mal verbose am httpmod device hochgedreht? Vielleicht lässt sich aus den Logs was rauslesen.

ich hab mal ein Log im HTTPMOD-Thread gepostet: https://forum.fhem.de/index.php?msg=1338007

hab's gesehen, das ist ein anderes API, das du mit httpmod ansprichst: /components/cache/readable verwendet das 98_fronius nicht, das geht auf /solar_api/v1/

Info-Post zur Zeitumstellung:

Die Fronius API, konkret der ArchiveData Teil, hat leider einen Fehler an den Tagen der Zeitumstellung.
Die ArchiveData Werte werden um eine Stunde zeitversetzt zugeordnet.
Das führt am Tag des Wechsels zur Sommerzeit zu einem Zeitversatz der Werte (zB Abfrage um 15:30 liefert Wert für 14:30), am Wechseltag zur Winterzeit leider zu einem Ausbleiben der Werte (weil der Zeitpunkt aus Sicht des APIs in der Zukunft liegt).
Fronius schreibt auch offen in die Doku, Kap. 5.1.1 (https://www.fronius.com/~/downloads/Solar%20Energy/Operating%20Instructions/42%2C0410%2C2012.pdf): "On days where daylight saving time is changing (begin or end of summertime) a few problems are known regarding time calculation".

Betroffen sind diese Readings des Moduls:

ArchiveData_EnergyReal_WAC_Minus_Absolute
ArchiveData_EnergyReal_WAC_Plus_Absolute
ArchiveData_EnergyReal_WAC_Sum_Produced
ArchiveData_PowerReal_PAC_Sum
MPPT1_DC_A
MPPT1_DC_V
MPPT1_DC_W
MPPT2_DC_A
MPPT2_DC_V
MPPT2_DC_W

Ich hatte diese Frage schon einmal in einem anderen Post gestellt:
Was geht den nun und wie mit der aktuellen Version 1.35.8-1 ?
Fronius Modul mit attribute useHTTPS auf 1 gesetzt oder
Modbus mit entsprechenden Einstellungen?
Ich habe noch die 1.34.6-1 am laufen und will erst umstellen, wenn ich ganz sicher
sein kann das alles Andere dann auch noch läuft.

LG WDS

Ich hab die 1.35.8-1 am Laufen.

fronius liefert folgende Readings:
#   READINGS:
#     2025-04-13 18:06:16   API_APIVersion  1
#     2025-04-13 18:06:16   API_BaseURL     /solar_api/v1/
#     2025-04-13 18:06:16   API_CompatibilityRange 1.8-0
#     2025-04-13 18:05:16   DeviceInfo_Inverter_1_DT 1
#     2025-04-13 18:05:16   DeviceInfo_Inverter_1_Serial 34827905
#     2025-04-13 18:05:16   DeviceInfo_Meter_0_DT -1
#     2025-04-13 18:05:16   DeviceInfo_Meter_0_Serial 1546454445
#     2025-04-13 18:05:16   DeviceInfo_Storage_0_DT -1
#     2025-04-13 18:05:16   DeviceInfo_Storage_0_Serial P030T020Z2212061267     
#     2025-04-13 19:38:10   Inverter_3P_IAC_L1_Unit A
#     2025-04-13 19:38:10   Inverter_3P_IAC_L1_Value 3.5512523651123
#     2025-04-13 19:38:10   Inverter_3P_IAC_L2_Unit A
#     2025-04-13 19:38:10   Inverter_3P_IAC_L2_Value 3.5496346950531
#     2025-04-13 19:38:10   Inverter_3P_IAC_L3_Unit A
#     2025-04-13 19:38:10   Inverter_3P_IAC_L3_Value 3.55136823654175
#     2025-04-13 19:38:10   Inverter_3P_UAC_L1_Unit V
#     2025-04-13 19:38:10   Inverter_3P_UAC_L1_Value 232.173706054688
#     2025-04-13 19:38:10   Inverter_3P_UAC_L2_Unit V
#     2025-04-13 19:38:10   Inverter_3P_UAC_L2_Value 233.537094116211
#     2025-04-13 19:38:10   Inverter_3P_UAC_L3_Unit V
#     2025-04-13 19:38:10   Inverter_3P_UAC_L3_Value 230.233825683594
#     2025-04-13 19:38:10   Inverter_Common_DAY_ENERGY_Unit Wh
#     2025-04-13 19:38:10   Inverter_Common_DAY_ENERGY_Value 0
#     2025-04-13 19:38:10   Inverter_Common_DeviceStatus_ErrorCode 0
#     2025-04-13 19:38:10   Inverter_Common_DeviceStatus_InverterState Running
#     2025-04-13 19:38:10   Inverter_Common_DeviceStatus_StatusCode 7
#     2025-04-13 19:38:10   Inverter_Common_FAC_Unit Hz
#     2025-04-13 19:38:10   Inverter_Common_FAC_Value 49.9869422912598
#     2025-04-13 19:38:10   Inverter_Common_IAC_Unit A
#     2025-04-13 19:38:10   Inverter_Common_IAC_Value 10.6522552967072
#     2025-04-13 19:38:10   Inverter_Common_IDC_2_Unit A
#     2025-04-13 19:38:10   Inverter_Common_IDC_2_Value 0.300971299409866
#     2025-04-13 19:38:10   Inverter_Common_IDC_3_Unit A
#     2025-04-13 19:38:10   Inverter_Common_IDC_3_Value 0
#     2025-04-13 19:38:10   Inverter_Common_IDC_4_Unit A
#     2025-04-13 19:38:10   Inverter_Common_IDC_4_Value 0
#     2025-04-13 19:38:10   Inverter_Common_IDC_Unit A
#     2025-04-13 19:38:10   Inverter_Common_IDC_Value 0.371987193822861
#     2025-04-13 19:38:10   Inverter_Common_MPPT1_Unit W
#     2025-04-13 19:38:10   Inverter_Common_MPPT1_Value 151.217880051409
#     2025-04-13 19:38:10   Inverter_Common_MPPT2_Unit W
#     2025-04-13 19:38:10   Inverter_Common_MPPT2_Value 114.577931191358
#     2025-04-13 19:38:10   Inverter_Common_PAC_Unit W
#     2025-04-13 19:38:10   Inverter_Common_PAC_Value 2471.03857421875
#     2025-04-13 19:38:10   Inverter_Common_SAC_Unit VA
#     2025-04-13 19:38:10   Inverter_Common_SAC_Value 2471.04711914062
#     2025-04-13 19:38:10   Inverter_Common_TOTAL_ENERGY_Unit Wh
#     2025-04-13 19:38:10   Inverter_Common_TOTAL_ENERGY_Value 10934428.045
#     2025-04-13 19:38:10   Inverter_Common_UAC_Unit V
#     2025-04-13 19:38:10   Inverter_Common_UAC_Value 232.649475097656
#     2025-04-13 19:38:10   Inverter_Common_UDC_2_Unit V
#     2025-04-13 19:38:10   Inverter_Common_UDC_2_Value 380.693878173828
#     2025-04-13 19:38:10   Inverter_Common_UDC_3_Unit V
#     2025-04-13 19:38:10   Inverter_Common_UDC_3_Value 0
#     2025-04-13 19:38:10   Inverter_Common_UDC_4_Unit V
#     2025-04-13 19:38:10   Inverter_Common_UDC_4_Value 0
#     2025-04-13 19:38:10   Inverter_Common_UDC_Unit V
#     2025-04-13 19:38:10   Inverter_Common_UDC_Value 406.513671875
#     2025-04-13 19:38:10   Inverter_Common_YEAR_ENERGY_Unit Wh
#     2025-04-13 19:38:10   Inverter_Common_YEAR_ENERGY_Value 0
#     2025-04-13 19:38:10   Inverter_Cumulation_DAY_ENERGY_Unit Wh
#     2025-04-13 19:38:10   Inverter_Cumulation_DAY_ENERGY_Value 0
#     2025-04-13 19:38:10   Inverter_Cumulation_DeviceStatus_ErrorCode 0
#     2025-04-13 19:38:10   Inverter_Cumulation_DeviceStatus_InverterState Running
#     2025-04-13 19:38:10   Inverter_Cumulation_DeviceStatus_StatusCode 7
#     2025-04-13 19:38:10   Inverter_Cumulation_PAC_Unit W
#     2025-04-13 19:38:10   Inverter_Cumulation_PAC_Value 2475.45971679688
#     2025-04-13 19:38:10   Inverter_Cumulation_TOTAL_ENERGY_Unit Wh
#     2025-04-13 19:38:10   Inverter_Cumulation_TOTAL_ENERGY_Value 10934428.045
#     2025-04-13 19:38:10   Inverter_Cumulation_YEAR_ENERGY_Unit Wh
#     2025-04-13 19:38:10   Inverter_Cumulation_YEAR_ENERGY_Value 0
#     2025-04-13 19:38:10   Inverter_System_DAY_ENERGY_Unit Wh
#     2025-04-13 19:38:10   Inverter_System_DAY_ENERGY_Values_1 0
#     2025-04-13 19:38:10   Inverter_System_PAC_Unit W
#     2025-04-13 19:38:10   Inverter_System_PAC_Values_1 2475.45971679688
#     2025-04-13 19:38:10   Inverter_System_TOTAL_ENERGY_Unit Wh
#     2025-04-13 19:38:10   Inverter_System_TOTAL_ENERGY_Values_1 10934428.045
#     2025-04-13 19:38:10   Inverter_System_YEAR_ENERGY_Unit Wh
#     2025-04-13 19:38:10   Inverter_System_YEAR_ENERGY_Values_1 0
#     2025-04-13 19:35:08   MPPT1_DC_W      0
#     2025-04-13 19:35:08   MPPT2_DC_W      0
#     2025-04-13 19:38:10   Meter_0_Current_AC_Phase_1 6.185
#     2025-04-13 19:38:10   Meter_0_Current_AC_Phase_2 -3.104
#     2025-04-13 19:38:10   Meter_0_Current_AC_Phase_3 -3.092
#     2025-04-13 19:38:10   Meter_0_Current_AC_Sum -0.0110000000000006
#     2025-04-13 19:38:10   Meter_0_Details_Manufacturer Fronius
#     2025-04-13 19:38:10   Meter_0_Details_Model Smart Meter TS 65A-3
#     2025-04-13 19:38:10   Meter_0_Details_Serial 1546454445
#     2025-04-13 19:38:10   Meter_0_Enable  1
#     2025-04-13 19:38:10   Meter_0_EnergyReactive_VArAC_Sum_Consumed 150245
#     2025-04-13 19:38:10   Meter_0_EnergyReactive_VArAC_Sum_Produced 3720189
#     2025-04-13 19:38:10   Meter_0_EnergyReal_WAC_Minus_Absolute 5743909
#     2025-04-13 19:38:10   Meter_0_EnergyReal_WAC_Plus_Absolute 2344063
#     2025-04-13 19:38:10   Meter_0_EnergyReal_WAC_Sum_Consumed 2344063
#     2025-04-13 19:38:10   Meter_0_EnergyReal_WAC_Sum_Produced 5743909
#     2025-04-13 19:38:10   Meter_0_Frequency_Phase_Average 49.9
#     2025-04-13 19:38:10   Meter_0_Meter_Location_Current 0
#     2025-04-13 19:38:10   Meter_0_PowerApparent_S_Phase_1 1432.8
#     2025-04-13 19:38:10   Meter_0_PowerApparent_S_Phase_2 718.2
#     2025-04-13 19:38:10   Meter_0_PowerApparent_S_Phase_3 710.5
#     2025-04-13 19:38:10   Meter_0_PowerApparent_S_Sum 2861.6
#     2025-04-13 19:38:10   Meter_0_PowerFactor_Phase_1 0.995
#     2025-04-13 19:38:10   Meter_0_PowerFactor_Phase_2 -0.983
#     2025-04-13 19:38:10   Meter_0_PowerFactor_Phase_3 -0.99
#     2025-04-13 19:38:10   Meter_0_PowerFactor_Sum 0.003
#     2025-04-13 19:38:10   Meter_0_PowerReactive_Q_Phase_1 -49.5
#     2025-04-13 19:38:10   Meter_0_PowerReactive_Q_Phase_2 -79.5
#     2025-04-13 19:38:10   Meter_0_PowerReactive_Q_Phase_3 -105.8
#     2025-04-13 19:38:10   Meter_0_PowerReactive_Q_Sum -234.9
#     2025-04-13 19:38:10   Meter_0_PowerReal_P_Phase_1 1431.9
#     2025-04-13 19:38:10   Meter_0_PowerReal_P_Phase_2 -713.8
#     2025-04-13 19:38:10   Meter_0_PowerReal_P_Phase_3 -702.6
#     2025-04-13 19:38:10   Meter_0_PowerReal_P_Sum 15.4
#     2025-04-13 19:38:10   Meter_0_TimeStamp 1744565889
#     2025-04-13 19:38:10   Meter_0_Visible 1
#     2025-04-13 19:38:10   Meter_0_Voltage_AC_PhaseToPhase_12 402
#     2025-04-13 19:38:10   Meter_0_Voltage_AC_PhaseToPhase_23 404.8
#     2025-04-13 19:38:10   Meter_0_Voltage_AC_PhaseToPhase_31 401.4
#     2025-04-13 19:38:10   Meter_0_Voltage_AC_Phase_1 232.5
#     2025-04-13 19:38:10   Meter_0_Voltage_AC_Phase_2 234.1
#     2025-04-13 19:38:10   Meter_0_Voltage_AC_Phase_3 231
#     2025-04-13 19:38:09   PowerFlow_Inverters_1_Battery_Mode normal
#     2025-04-13 19:38:09   PowerFlow_Inverters_1_DT 1
#     2025-04-13 19:38:09   PowerFlow_Inverters_1_E_Day 0
#     2025-04-13 19:38:09   PowerFlow_Inverters_1_E_Total 10934428.045
#     2025-04-13 19:38:09   PowerFlow_Inverters_1_E_Year 0
#     2025-04-13 19:38:09   PowerFlow_Inverters_1_P 2471.03857421875
#     2025-04-13 19:38:09   PowerFlow_Inverters_1_SOC 87.4
#     2025-04-13 19:38:09   PowerFlow_Site_BackupMode false
#     2025-04-13 19:38:09   PowerFlow_Site_BatteryStandby true
#     2025-04-13 19:38:09   PowerFlow_Site_E_Day 0
#     2025-04-13 19:38:09   PowerFlow_Site_E_Total 10934428.045
#     2025-04-13 19:38:09   PowerFlow_Site_E_Year 0
#     2025-04-13 19:38:09   PowerFlow_Site_Meter_Location grid
#     2025-04-13 19:38:09   PowerFlow_Site_Mode bidirectional
#     2025-04-13 19:38:09   PowerFlow_Site_P_Akku 2311.19897460938
#     2025-04-13 19:38:09   PowerFlow_Site_P_Grid 9.8
#     2025-04-13 19:38:09   PowerFlow_Site_P_Load 2478.87080078125
#     2025-04-13 19:38:09   PowerFlow_Site_P_PV 265.886978149414
#     2025-04-13 19:38:10   PowerFlow_Site_P_PV_Rounded 266
#     2025-04-13 19:38:09   PowerFlow_Site_rel_Autonomy 99.6046587019819
#     2025-04-13 19:38:09   PowerFlow_Site_rel_SelfConsumption 100
#     2025-04-13 19:38:09   PowerFlow_Version 13
#     2025-04-13 19:38:10   Storage_0_Controller_Capacity_Maximum 7680
#     2025-04-13 19:38:10   Storage_0_Controller_Current_DC -7.41770533716843
#     2025-04-13 19:38:10   Storage_0_Controller_DesignedCapacity 7680
#     2025-04-13 19:38:10   Storage_0_Controller_Details_Manufacturer BYD
#     2025-04-13 19:38:10   Storage_0_Controller_Details_Model BYD Battery-Box Premium HV
#     2025-04-13 19:38:10   Storage_0_Controller_Details_Serial P030T020Z2212061267     
#     2025-04-13 19:38:10   Storage_0_Controller_Enable 1
#     2025-04-13 19:38:10   Storage_0_Controller_StateOfCharge_Relative 87.4
#     2025-04-13 19:38:10   Storage_0_Controller_Status_BatteryCell 3
#     2025-04-13 19:38:10   Storage_0_Controller_Temperature_Cell 21
#     2025-04-13 19:38:10   Storage_0_Controller_TimeStamp 1744565887
#     2025-04-13 19:38:10   Storage_0_Controller_Voltage_DC 312.9
#     2025-04-13 19:38:10   User_Energy_Bat_Efficiency 92.783103320442
#     2025-04-13 19:38:09   User_Energy_Bat_in 2186.14389240606
#     2025-04-13 19:38:09   User_Energy_Bat_out 2028.37214642465
#     2025-04-13 19:37:10   User_Energy_Feedin 5743909
#     2025-04-13 19:37:10   User_Energy_Import 2344063
#     2025-04-13 19:38:09   User_Power_Feedin 0
#     2025-04-13 19:38:09   User_Power_Import 9.8
#     2025-04-13 19:38:09   User_Produced_PV 11083.2109816811
#     2025-04-13 08:05:18   state           connected

Modbus:

define BYD_Battery ModbusAttr 1 60 192.168.178.129:502 TCP
#   READINGS:
#     2025-04-13 19:40:10   ACActEnergy     10934.63
#     2025-04-13 19:40:09   ACCurrentPhaseA 3.5
#     2025-04-13 19:40:09   ACCurrentPhaseB 3.5
#     2025-04-13 19:40:09   ACCurrentPhaseC 3.5
#     2025-04-13 19:40:09   ACFrequency     50.0
#     2025-04-13 19:40:09   ACPower         2440
#     2025-04-13 19:40:09   ACVoltagePhaseA 231.2
#     2025-04-13 19:40:09   ACVoltagePhaseB 233.0
#     2025-04-13 19:40:09   ACVoltagePhaseC 231.3
#     2025-04-13 19:40:10   BatConfigMaxChargeWatt 7680.0
#     2025-04-13 19:40:10   BatConfigMaxDischargeWatt 7680.0
#     2025-04-13 19:40:10   BatConfigMaxEnabled none
#     2025-04-13 19:40:10   BatConfigMaxReferenceWatt 7680.0
#     2025-04-13 19:40:10   BatConfigReserve 5
#     2025-04-13 19:40:10   BatConfigReserveFormatted 5 %
#     2025-01-15 09:39:52   BatteryCharge   4 %
#     2025-04-13 19:40:10   BatteryChargeFormatted 86 %
#     2025-04-13 19:40:10   BatteryChargePercent 86.3
#     2025-04-13 19:40:10   BatteryChargeWatt 0.0
#     2025-01-16 08:14:32   BatteryConfigReserveFormatted 0 %
#     2025-04-13 19:40:10   BatteryDischargeWatt 2289.5
#     2025-04-13 19:40:10   BatteryState    discharging
#     2025-04-13 19:40:09   CabinetTemperature 49.0
#     2025-04-13 19:40:10   DCPowerMPPT1    143.1
#     2025-04-13 19:40:10   DCPowerMPPT2    109.2
#     2025-04-13 19:40:10   DCPowerScale    -1
#     2025-04-13 19:40:10   Summe_Entladung 206.0
#     2025-04-13 19:40:10   Summe_Ladung    224.5
#     2025-04-13 08:05:17   state           opened
#     2025-04-13 19:40:09   status          active



Danke grappa24,

dann werde ich bei mir demnächst komplett auf Fronius Modul und Modbus umstellen.
Die "Updatefähigkeit" des SymoGen24 ist mir da doch wichtiger.
Allerdings brauche ich zwei Fronius Module.
Einmal Auslesen aller Daten (alle 60 Sek) und weitergehende Berechnungen daraus
und ein 10 Sek Modul für meine Anzeigen.
Das wiederum könnte ich auch über Modbus machen.
Da hat man die Datenmenge und den Traffic besser im Griff.
Und wenn dann noch Zeit ist das Wiki ändern....

LG WDS

Zitat von: dieter114 am 13 April 2025, 19:19:13HTTPMOD ist ja wohl definitiv nicht mehr möglich.

PArdon, aber das ist Unsinn. Läuft bei mir weiterhin ganz problemlos.

LG

pah

was nicht mehr geht ist die Fronius-interne Schnittstelle:
https://<ip-wr>/components/cache/readable 0über die wir vor dem Fronius-Update auf 1.35.4-1 die folgenden Parameter abgefragt hatten:
BAT_ENERGYACTIVE_ACTIVECHARGE_SUM_01_U64
BAT_ENERGYACTIVE_ACTIVEDISCHARGE_SUM_01_U64


Erstens steht dies so auch nicht in der API-Dokumentation. Wer so etwas verwendet, ist selbst Schuld.
Zweitens lassen sich die genannten Werte problemlos per userReading beschaffen.

In jedem Falle ist es aber eine ärgerliche Irreführung zu behaupten, dass "HTTPMOD ja wohl definitiv nicht mehr möglich" sei.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 15 April 2025, 16:47:53In jedem Falle ist es aber eine ärgerliche Irreführung zu behaupten, dass "HTTPMOD ja wohl definitiv nicht mehr möglich" sei.

Ok - hab`s entfernt

Hier der Vollständigkeit halber nochmal der Punkt aus dem anderen Thread (https://forum.fhem.de/index.php?topic=141037.msg1339285#msg1339285):

Leider liefern GEN24/Tauro keine Werte aus der ArchiveData Gruppe, Zitat aus der Fronius Doku: "GEN24/Tauro does not provide access to history data" (Kapitel 5.1.1)

Betroffen sind diese Readings des Moduls:

ArchiveData_EnergyReal_WAC_Minus_Absolute
ArchiveData_EnergyReal_WAC_Plus_Absolute
ArchiveData_EnergyReal_WAC_Sum_Produced
ArchiveData_PowerReal_PAC_Sum
MPPT1_DC_A
MPPT1_DC_V
MPPT1_DC_W
MPPT2_DC_A
MPPT2_DC_V
MPPT2_DC_W

Hallo zusammen,
ich hab nun folgendes Setup
1. Wechselrichter mit Battery und Primärzähler am Einspeisepunkt
2. Wechselrichter (neu) der ins Hausnetz einspeißt.

Ich hab nun das Phänomen, das der Verbrauch des Hauses, also das Reading PowerFlow_Site_P_Load viel zu hoch ist, wenn der zweite Wechselrichter produziert.
Ich hätte eigentlich erwartet, das dieser Wert sogar negativ ist, wenn der zweite Wechselrichter mehr produziert als das Haus konsumiert.
Dadurch gehen bei mir einige Automatisierung nichtmehr, da kein PV Überschuss mehr vorhanden scheint, wenn das Haus soviel verbraucht. Im SolarWeb wirds aber richtig angezeigt.

Kann es sein das das Modul ein Problem hat, wenn der Verbrauch des Hauses niedriger ist, als die Einspeisung weiterer Wechselrichter?

Hadl

Edit: Der wechselrichter produziert natürlich!

Die Werte kommen so vom Wechselrichter, das Modul rechnet nur bei den MPPT Werten selbst (und auch da nur eine Multiplikation der WR-Werte).

Bei zwei Wechselrichtern müsstest du ja zwei Devices in fhem angelegt haben, wie sind denn die Einzelwerte für PowerFlow_Site_P_Load?
Sind die ArchiveData_EnergyReal* Werte brauchbar?

Bei einem MeterDevice und zwei Wechselrichtern gibt es vielleicht Bedarf selbst noch was zu rechnen, vielleicht übernimmt SolarWeb das im Hintergrund.
Die Last ist ja immer nur rechnerisch die Differenz aus den gemessenen Werten für Erzeugung (am WR) und Einspeisung (am Zähler), aber wie gesagt, gerechnet von Fronius am WR.

Zitat von: Hadl am 05 Mai 2025, 10:41:45Ich hätte eigentlich erwartet, das dieser Wert sogar negativ ist, wenn der zweite Wechselrichter mehr verbraucht als das Haus konsumiert.

Das scheint mir ein wenig wirr - wieso sollte der Wechselrichter etwas verbrauchen?

Und was soll der "Primärzähler" sein? Der Zähler des Netzbetreibers?
Ist der Fronius-WR an ein separates Smartmeter angeschlossen, mit dem er direkt kommuniziert? Das sollte eigentlich so sein, wenn "solarer Überschuss" festgestellt werden kann.
Was für ein Wechselrichter ist der "zweite"?

LG

pah

Zitat von: fichtennadel am 05 Mai 2025, 12:38:01Bei zwei Wechselrichtern müsstest du ja zwei Devices in fhem angelegt haben, wie sind denn die Einzelwerte für PowerFlow_Site_P_Load?
Sind die ArchiveData_EnergyReal* Werte brauchbar?

Der erste Wechselrichter scheint immer den Betrag der Differenz zwischen seiner eigenen Leistung und dem primärzähler auszugeben.
Dadurch wir der Wert entweder groß wenn das Haus viel verbraucht und wenig produziert wird, oder wenn das Haus wenig verbraucht und der zweite Wechselrichter viel produziert.

Die Meter_0_EnergyReal.* Werte sind alle plausibel

Zitat von: fichtennadel am 05 Mai 2025, 12:38:01Die Last ist ja immer nur rechnerisch die Differenz aus den gemessenen Werten für Erzeugung (am WR) und Einspeisung (am Zähler), aber wie gesagt, gerechnet von Fronius am WR.

Genau, und diese Differenz müsste negativ sein wenn mehr eingespeist wird, als er selbst produziert. Auf der Wechselrichter Website sehe ich das auch so, aber in fhem siehts aus als ob ich den Betrag davon sehe.

Zitat von: Prof. Dr. Peter Henning am 05 Mai 2025, 15:35:55

ZitatIch hätte eigentlich erwartet, das dieser Wert sogar negativ ist, wenn der zweite Wechselrichter mehr verbraucht als das Haus konsumiert.

Das scheint mir ein wenig wirr - wieso sollte der Wechselrichter etwas verbrauchen?

Richtig, sollte heißen: "Ich hätte eigentlich erwartet, das dieser Wert sogar negativ ist, wenn der zweite Wechselrichter mehr produziert als das Haus konsumiert."

Zitat von: Prof. Dr. Peter Henning am 05 Mai 2025, 15:35:55Und was soll der "Primärzähler" sein? Der Zähler des Netzbetreibers?
Ist der Fronius-WR an ein separates Smartmeter angeschlossen, mit dem er direkt kommuniziert? Das sollte eigentlich so sein, wenn "solarer Überschuss" festgestellt werden kann.
Was für ein Wechselrichter ist der "zweite"?

Primärzähler ist der Fronius Smartmeter der direkt hinter dem Zähler des Netzbetreibers sitzt und damit das gleiche zählt.
Dieser Smartmeter hängt am ersten Wechselrichter, genauso wie der Akku.
Der zweite Wechselrichter ist auch ein Fronius, aber als reiner Produzent ohne Smartmeter oder Akku.

Kannst du ein Beispiel für die Werte von PowerFlow_Site_P_* für die beiden Wechselrichter zu einem Zeitpunkt posten?

Eigentlich sollte sich die Last aus (WR1.PowerFlow_Site_P_PV+WR2.PowerFlow_Site_P_PV)-PowerFlow_Site_P_Grid ergeben, vorausgesetzt die Einzelwerte sind korrekt.

Spannend ist, wie Fronius den PowerFlow_Site_P_Grid Wert auf den beiden WR bestimmt.

Hier mal ein Beispielzeitpunkt von jetzt
1. WR
PowerFlow_Site_P_Akku: -15
PowerFlow_Site_P_Grid: -12947
PowerFlow_Site_P_Load: 7962
PowerFlow_Site_P_PV: 5100


2. WR
PowerFlow_Site_P_Akku: 0
PowerFlow_Site_P_Grid: 0
PowerFlow_Site_P_Load: 0
PowerFlow_Site_P_PV: 8457


In wirklichkeit ists so:
Produktion: 5100 + 8457= 13557
Einspeisung und Akku laden: 12947 + 15 = 12962
Verbrauch Haus: 13557- 12962 (- Eigenverbrauch WR's) ~ 595
Der erste Wechselrichter sollte als "Rest im Haus" (PowerFlow_Site_P_Load) sehen: 5100 - 15 - 12947 (- Eigenverbrauch) ~ -7862



Hab jetzt den Code nochmal genauer angeschaut und bin zur Überzeugung gekommen das irgendwo ein Vorzeichen verloren geht. Ich hab die Stelle auch gefunden.

Hier wird der Betrag gebildet. Wenn ich das wegnehme, aber die Vorzeichenänderung an die ich mich schon gewöhnt habe lasse, dann funktioniert alles wieder!
        if ($reading eq "PowerFlow_Site_P_Load") {
          if ( $value + 0 eq $value) {
            if ($value < 0) {$value = $value * -1}
          }       
        }
Ohne Betragbildung, aber mit Vorzeichenänderung
        if ($reading eq "PowerFlow_Site_P_Load") {
          if ( $value + 0 eq $value) {
            $value = $value * -1;
          }       
        }

Damit hat dann der 1. WR:
PowerFlow_Site_P_Load: -7962

Ok, jetzt wird es klarer, was hier wo läuft. Ich finde die Konstellation potenziell interessant, weil ich in 3 Jahren meine Altanlage aufbohren und ebenfalls mit dann neuem Fronius-WR und Speicher ausstatten werde. Die soll dann mit der jetzt neuen 2. Anlage (Fronius-WR und Speicher) möglichst optimal zusammenwirken.

Für das Modul ergäbe sich damit die Möglichkeit, eine Art Master-Slave- Kombination zu bilden, bei der alle relevanten Daten an einer Stelle gesammelt werden.

Lg

pah

Zitat von: Hadl am 07 Mai 2025, 10:36:35Hab jetzt den Code nochmal genauer angeschaut und bin zur Überzeugung gekommen das irgendwo ein Vorzeichen verloren geht. Ich hab die Stelle auch gefunden.

Hier wird der Betrag gebildet. Wenn ich das wegnehme, aber die Vorzeichenänderung an die ich mich schon gewöhnt habe lasse, dann funktioniert alles wieder!

Code Auswählen Erweitern

        if ($reading eq "PowerFlow_Site_P_Load") {
          if ( $value + 0 eq $value) {
            if ($value < 0) {$value = $value * -1}
          }      
        }
Ohne Betragbildung, aber mit Vorzeichenänderung

Code Auswählen Erweitern

        if ($reading eq "PowerFlow_Site_P_Load") {
          if ( $value + 0 eq $value) {
            $value = $value * -1;
          }      
        }

Damit hat dann der 1. WR:
PowerFlow_Site_P_Load: -7962

Die Stelle ist noch aus der ursprünglichen Version von michael.winkler. Ich kann das schon ändern, kann aber sein, dass sich dann jemand meldet, der das wieder andersrum möchte, weil es schon jahrelang so ist und verwendet/erwartet wird.

Und eigentlich kann eine Last ja nicht negativ sein, der Wert an der Stelle ist aber auch unabhängig vom Vorzeichen falsch, weil er auf Ebene der beiden WR gerechnet werden muss.

Unabhängig von der Änderung im Modul wirst Du das voerst über eine Rechnung über beide WR mit Userreadings lösen müssen.

Die "Master-Slave-Kombination" von pah ist eine gute Idee, das sehe ich mir getrennt an, ist aber eine größere Änderung im Modul.

Hallo Fichtennade,
ja, ich sehe das so wie du. Der Wert ist mit zwei Wechselrichtern eh nichtmehr wirklich zu gebrauchen, wobei ich eigentlich keinen Usecase sehe wo man den Betrag braucht. Wenn man den Wert immer mit "-1" multipliziert würde es für mich auf jeden Fall mehr Sinn machen.

Das Master-Slave Problem hab ich aktuell u.a. mit dem SolarForecast Modul gelöst, dort kann man mehrere Wechselrichter angeben, aber auch wo der Zähler und der Akku ist. Er rechnet dann auch selbstständig vernünftige Werte aus. Nur im Fall von Wolken merkt man schon, das zwischen den beiden Abfragen an die Wechselrichter ein Zeitversatz ist und manchmal daher die Rechnungen nicht passen.

Gibt es eine Möglichkeit die Abfragen zu syncronisieren?

Zitat von: Hadl am 07 Mai 2025, 17:26:37Wenn man den Wert immer mit "-1" multipliziert würde es für mich auf jeden Fall mehr Sinn machen.

V0.5 im Contrib (https://svn.fhem.de/fhem/trunk/fhem/contrib/98_fronius.pm)

Zitat von: Hadl am 07 Mai 2025, 17:26:37Gibt es eine Möglichkeit die Abfragen zu syncronisieren?

Ich habe noch keine gefunden, es sind ja nicht mal die Werte eines WRs zwingend in sich konsistent, siehe Fronius Doku "Because data has multiple asynchronous origins it is a matter of fact that the sum of all powers (grid, load and generate) will differ from zero" (https://www.fronius.com/~/downloads/Solar%20Energy/Operating%20Instructions/42%2C0410%2C2012.pdf , Kapitel 4.11)

Ich verwende für die "schnellen" Steuerungen (zB Reaktion auf Wolken) den PowerFlow_Site_P_Grid Wert (Überschuss ins Netz ja/nein oder aktuell verfügbarer Überschuss für Wallbox) und für Statistiken bzw. "langsame" Steuerungen (Mittelwert o.ä.) die ArchiveData Werte.

Also ich versuche das Syncen über ein Notify und bin damit ziemlich zufrieden.
   
WR1:PowerFlow_Site_P_PV.* set WR2 GetPowerFlowData

Gruß,
Stefan

Ich hab gerade mal meine Events beobachtet. Die beiden Fronius Abfragen scheinen nahezu zeitgleich zu erfolgen und überlagern sich sogar im Event Monitor
Nur der notify den ich probiert habe macht bei jedem der drei Werte schon eine Berechnung und nicht erst wenn alle drei da sind. Und es ist nicht immer gleich welcher der letzte der drei ist.
Damit krieg ich immer falsche Einträge kurz darauf gefolgt von einem besseren. Die SolarForecast ist wohl zeitlich weiter versetzt und sieht meistens bessere Werte.

defmod notify_StromverbrauchHaus notify (Fronius_Symo1:Inverter_Common_PAC_Value|Fronius_Symo1:PowerFlow_Site_P_Grid|Fronius_Symo2:Inverter_Common_PAC_Value):.*\
  {\
  my $val=\
    ReadingsVal('Fronius_Symo1', 'Inverter_Common_PAC_Value', '0') + \
    ReadingsVal('Fronius_Symo1', 'PowerFlow_Site_P_Grid', '0') + \
    ReadingsVal('Fronius_Symo2', 'Inverter_Common_PAC_Value', '0') \
    ;;;;\
  { fhem "setreading notify_StromverbrauchHaus StromverbrauchHaus $val" }\
}

Hmmm, und wenn du die Berechnung in einem UserReading in einem der beiden Devices machst?
Oder in einem 3ten Dummy Device dass du per notify triggerst wenn die Abfragen beider WR durch sind?

Gruß,
Stefan

Solche Rechnungen sollten erstens in einer ausgelagerten Perl-Routine erfolgen. Die kann man zwar in einem userReading einbinden - wartbar sollte sie aber nicht im Device sein, sondern mit einem ordentlichen Code-Editor.

Zweitens ist auch hier ein Master-Slave-Konzept zu bevorzugen: Eines der WR-Devices löst (gerne über ein userReading) die ganze Kette anderer Abfragen aus. Bei mir ist das die Abfrage von http://xxx/solar_api/v1/GetPowerFlowRealtimeData.fcgi, da ich weiterhin lieber über HTTPMOD auf den WR zugreife.

Wenn man das in dem Modul überarbeitet, sollte deshalb ein Attribut "externalPowerFunction" (oder so) eingeführt werden, das als Wert einen Funktionsnamen erhält, der unmittelbar nach dieser Abfrage aufgerufen wird.

LG

pah

Guten Morgen in die Runde, ich betreibe hier einen Fronius Symo Gen24 WR zusammen mit einem BYD-HVS 10.2 Speicher. Zunächst einmal ein riesen Dankeschön an fichtennadel, dass Du hier ein solches Modul für den Fronius bereit stellst. Die Masse an Readings stellt bislang etwas eine Herausforderung für mich dar und ich versuche mich da zurecht zu finden.  ;D
Bislang habe ich für die reale PV-Erzeugung den aufsteigenden Zähler aus dem Reading PowerFlow_Site_E_Total verwendet (das schien mir irgendwie schlüssig). Im SolarForecast-Modul habe ich dann festgestellt, dass die reale PV Erzeugung aber nicht zu stimmen scheint, weil das Reading irgendwie nicht richtig hochzählt solange morgens zunächst meine Batterie geladen wird. Im SolarForecast Thread wurde dann vermutet und der Hinweis gegeben, dass das von mir verwendete Reading wahrscheinlich nicht stimmt.

Deshalb möchte ich gerne mal hier in die Runde fragen welches Reading ihr hier so für die reale PV Erzeugung verwendet?

Hier meine Definition von setupInverterDev01 auf der Basis des fronius devices: SymGen24 pv=PowerFlow_Site_P_PV:W etotal=User_Produced_PV:kWh capacity=10000 strings=suedwest,nordost

Ich verwende das Modul gar nicht, weil die Abfrage über HTTPMOD etwas flexibler ist. Aber auch da ist die real produzierte solare Energie unzuverlässig. Also berechne ich sie per userReading
energy_PV2:power_load.* integral {ReadingsVal("$NAME","power_PV2",0)/3600},
LG

pah

Zitat von: grappa24 am 11 Mai 2025, 09:20:30Hier meine Definition von setupInverterDev01 auf der Basis des fronius devices:

Code Auswählen Erweitern

SymGen24 pv=PowerFlow_Site_P_PV:W etotal=User_Produced_PV:kWh capacity=10000 strings=suedwest,nordost

Vielen Dank. Ich habe heute morgen auch noch etwas rumgeschmökert und dabei im Wiki einen Beitrag zu Fronius und BYD gefunden. Ich nehme an, dass du das Reading User_Produced_PV auch aus diesem Beispiel hast und das Reading mittels Userreading generierst?
User_Produced_PV:PowerFlow_Site_P_PV.* integral {ReadingsVal("$name","PowerFlow_Site_P_PV","0")/3600000}

Zitat von: Prof. Dr. Peter Henning am 11 Mai 2025, 09:21:40Ich verwende das Modul gar nicht, weil die Abfrage über HTTPMOD etwas flexibler ist. Aber auch da ist die real produzierte solare Energie unzuverlässig. Also berechne ich sie per userReading

Code Auswählen Erweitern

energy_PV2:power_load.* integral {ReadingsVal("$NAME","power_PV2",0)/3600},

Auch hierfür vielen Dank. Die Abfrage mittels HTTPMOD ist auch interessant. Hast du deine HTTPMOD Konfiguration schonmal irgendwo gepostet oder könntest du sie mal zeigen? Ich wüsste jetzt spontan gar nicht wie ich da ansetzen soll.

Zitat von: Wolle02 am 11 Mai 2025, 10:01:01Ich nehme an, dass du das Reading User_Produced_PV auch aus diesem Beispiel hast und das Reading mittels Userreading generierst?

Code Auswählen Erweitern

User_Produced_PV:PowerFlow_Site_P_PV.* integral {ReadingsVal("$name","PowerFlow_Site_P_PV","0")/3600000}

genau so ist es - hatte schon ganz vergessen, dass es sich um ein Userreading handelt  ;)

Zitat von: Wolle02 am 11 Mai 2025, 10:01:01Hast du deine HTTPMOD Konfiguration schonmal irgendwo gepostet oder könntest du sie mal zeigen? Ich wüsste jetzt spontan gar nicht wie ich da ansetzen soll.

Klar doch. Wollte ich schon länger ins Wiki stellen.

https://wiki.fhem.de/wiki/Fronius_Wechselrichter

LG

pah

Zitat von: Wolle02 am 11 Mai 2025, 07:14:39... Zunächst einmal ein riesen Dankeschön an fichtennadel, dass Du hier ein solches Modul für den Fronius bereit stellst. ...

Gerne, aber damit ich da nicht mit falschen Lorbeeren geschmückt werde: das meiste hat der ursprüngliche Modulauthor michael.winkler bereitgestellt.
Ich habe nur die Weiterentwicklung/Wartung übernommen, da er sich auf Rückfragen nicht mehr gemeldet hat.

Zitat von: Wolle02 am 11 Mai 2025, 07:14:39Bislang habe ich für die reale PV-Erzeugung den aufsteigenden Zähler aus dem Reading PowerFlow_Site_E_Total verwendet (das schien mir irgendwie schlüssig). Im SolarForecast-Modul habe ich dann festgestellt, dass die reale PV Erzeugung aber nicht zu stimmen scheint, weil das Reading irgendwie nicht richtig hochzählt solange morgens zunächst meine Batterie geladen wird. Im SolarForecast Thread wurde dann vermutet und der Hinweis gegeben, dass das von mir verwendete Reading wahrscheinlich nicht stimmt.
Deshalb möchte ich gerne mal hier in die Runde fragen welches Reading ihr hier so für die reale PV Erzeugung verwendet?

Je nach Anwendungsfall: für Durchschnittswerte über 5 Minuten verwende ich ArchiveData_PowerReal_PAC_Sum, für "Echtzeitwerte" PowerFlow_Site_P_PV , beides indirekt über UserReadings (damit ich bei Bedarf die Quelle anpassen kann, ohne alle lesenden Zugriffe ändern zu müssen).

Zitat von: fichtennadel am 11 Mai 2025, 19:15:30Je nach Anwendungsfall: für Durchschnittswerte über 5 Minuten verwende ich ArchiveData_PowerReal_PAC_Sum, für "Echtzeitwerte" PowerFlow_Site_P_PV , beides indirekt über UserReadings (damit ich bei Bedarf die Quelle anpassen kann, ohne alle lesenden Zugriffe ändern zu müssen).

Danke. Ich habe zwischenzeitlich auf das Userreading von Grappa24 umgestellt und damit sieht das Ganze schon deutlich besser aus.
In den Wikieintrag von pah lese ich mich grade ein.
Viele Wege führen nach Rom (wenn nicht sogar alle [frei nach Asterix]).

Zitat von: Wolle02 am 11 Mai 2025, 19:35:06Ich habe zwischenzeitlich auf das Userreading von Grappa24 umgestellt und damit sieht das Ganze schon deutlich besser aus.

Ich hab das auch nur dankenswerterweise übernommen  ;)

Ab der Version 1.52.4 des Moduls 76_SolarForecast wird zwischen pvIn und pvOut unterschieden

ZitatpvIn    Ein Reading, welches die aktuelle DC PV-Eingangsleistung in W liefert (Summe aller angeschlossenen Strings).
  Es wird ein positiver numerischer Wert erwartet.
 
pvOut    Ein Reading, welches die aktuelle Leistung aus PV-Erzeugung, die an das Hausnetz oder öffentliche Netz
  geliefert wird, bereitstellt. Es wird ein positiver numerischer Wert erwartet.

Ich verwende dazu die folgenden Werte aus dem Fronius-Modul:

pvOut=PowerFlow_Site_P_PV

pvIn=Inverter_Common_IDC_Value * Inverter_Common_UDC_Value + Inverter_Common_IDC2_Value * Inverter_Common_UDC2_Value

Macht das Sinn, gibts es ggf. Alternativen?

Im Übrigen ist bei mir pvIn ca. 1-2 Watt größer als pVOut (SymGen24 10, 11 kWp, 2 Strings)

Zitat von: grappa24 am 19 Mai 2025, 10:00:36Macht das Sinn, gibts es ggf. Alternativen?

Eher fraglich, weil Strom und Spannung wahrscheinlich nicht zur gleichen Zeit gemessen werden. Ist aber als Schätzwert akzeptierbar. Ich verwende für so etwas einen geeichten Strahlungssensor.

LG

pah

Alles eine Frage der Anforderungen, als Näherung ok, besser wird's mit dem Fronius API jedenfalls nicht werden.
Es gibt aktuelle DC Werte nur bei CommonInverterData, die Ausgangsleistung P_PV kommt aus PowerFlow, damit ist schon systembedingt ein zeitlicher Versatz über die dafür notwendigen zwei API Requests.

Auf der Suche nach der "korrekten" Ausgangsleistung:
Was ist denn der Unterschied zwischen PowerFlow_Site_P_PV und Inverter_Common_PAC_Value?

Wenn ich Common_PAC verwende, komme ich auf einen Wandlungsverlust von ca 2.5%
Bei Verwendung von PowerFlow_Site_P_PV dagegen auf 0.03%  :-\

Es ist mir nicht so ganz klar, mit welchem anderen Wert dieses Datum verglichen wird. PAC ist die Wechselstromleistung des Inverters - die kann ja auch aus dem Batteriespeicher kommen.

Zitat von: grappa24 am 19 Mai 2025, 15:18:47PowerFlow_Site_P_PV dagegen auf 0.03%

Das ist ziemlich unwahrscheinlich, nicht einmal die optimistischen Angaben der Hersteller geben solche Werte her. Typische Herstellerangaben bewegen sich auf dem Niveau von 2,5 - 3%.

Das ist allerdings auch in die Tasche gelogen, weil die gegenwärtigen Batteriespeicher Verluste von etwa 10% aufweisen. Wenn also solare Energie direkt über den WR eingespeist oder verwendet wird, kann man bei den modernen Wechselrichtern von 97,5% Wirkungsgrad ausgehen. Wenn die Energie aber erst in den Speicher geschoben und später daraus bezogen wird, sinkt das auf 88%.

Und weil ich gerade mal wieder einen Blog-Beitrag dazu geschrieben habe: Im vergangenen Jahr 2024 hat sich die installierte Batteriespeicherkapazität in Deutschland um etwa 50% erhöht und beträgt inzwischen rund 19 GWh. Klingt viel, und wir haben noch 40 GWh an Pumpspeicherkraftwerken. Allerdings beträgt der Jahresverbrauch in Deutschland etwa 464 TWh = 464.000 GWh. Damit ist klar, dass die gesamte Speicherkapazität in Deutschland ausreicht, um uns etwas mehr als eine Stunde lang mit Energie zu versorgen. Rechnet bitte selbst aus, was das bedeutet.

LG

pah

Und noch ein Nachtrag: Die elektrochemischen Speicher sind kaum weiter verbesserbar. Man muss berücksichtigen, dass darin Ionen in einem Elektrolyten mechanisch gegen Widerstand bewegt werden.

@pah hat natürlich Recht, der PAC Wert liefert NICHT die AC-Leistung abzüglich der Wandlungsverluste.

Ich fürchte fast, dass Fronius die nicht offenlegt  :( . Kann man die Wandlungsverluste ggf irgendwie aus den gelieferten Daten berechnen?

Zitat von: Prof. Dr. Peter Henning am 09 Mai 2025, 05:36:31...hier ein Master-Slave-Konzept zu bevorzugen: Eines der WR-Devices löst (gerne über ein userReading) die ganze Kette anderer Abfragen aus. Bei mir ist das die Abfrage von http://xxx/solar_api/v1/GetPowerFlowRealtimeData.fcgi, da ich weiterhin lieber über HTTPMOD auf den WR zugreife.

Hallo Peter, ich möchte gerne nochmal auf den Vorschlag zurückkommen, da ich noch keine Möglichkeit gefunden habe einigermaßen zeitnahe Werte zu verwenden. Eine Minute dazwischen ist einfach zu lange und mehrere Events machen zu viel "Müll".

Wie kann ich denn als Trigger den erfolgreichen Update (alle Events bearbeitet) eines WR nutzen, um dann den zweiten WR auszulesen und dann Berechnungen zu starten? Bzw. beide gleichzeitig auszulesen, und dann auf das Ende beider Vorgänge warten?

Ich hab bei manchen Modulen gesehen, das diese, warscheinlich am Ende, einen "updated Timestamp" in ein Reading schreiben. Das wäre doch auch hier ne Lösung. Man müsste halt nur sicherstellen das der wirklich als letztes kommt. In einem Notify mit Trigger auf beide Timestamps könnten man dann vergleichen ob die Timestamps nahe genug beieinander liegen und dann die Rechnungen machen.