76_SMAInverter.pm - Abfrage von SMA Wechselrichter

Begonnen von sct14675, 28 Juli 2016, 11:01:16

Vorheriges Thema - Nächstes Thema

BAfH

Guten Morgen,

danke.
Zitat von: 300P am 02 Januar 2025, 19:26:56attr xyxyxy suppressSleep 1
Ist mir nach genauer Auswertung meiner Logs jetzt auch klar... Manchmal steht man im Wald.
Gruß Thorben
mit sonnige Grüße aus Schönow

Dracolein

Moin zusammen und nachträglich ein frohes neues Jahr 2025.

Ein Learning aus diesem FHEM-Forum vor Jahren war es für mich, die automatischen Firmware-Updates meiner SMA-Geräte zu deaktivieren. Damit fahre ich bisher gut. Inzwischen gibt es für alle meine Geräte neue Firmware-Updates (2x Tripower WR, 1x EV Charger, 1x HM 2.0).

Wie haltet Ihr es damit? An sich laufen die Geräte fehlerfrei und kommunizieren prima mit FHEM, was mir besonders wichtig ist.
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

300P

Moin zurück!

In meinem SMA-Zoo hatte ich 2016/2019 erst auch dieses Verhalten bewußt so eingestellt.
Inzwischen bin ich seit Jahren bei der Fraktion "Automatisches Update".
Trotz gemischter Nutzung bei der Steuerung/Abfrage (Speedwire- und ModBus) bin ich selten bis ganz wenig auf Probleme gestoßen.

Gruß
300P
FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|QNAP|
JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_edge|ESP32CAM

FHEMAN

Moin und frohes Neues! Gerade hinsichtlich Speedwire und Modbus hat sich in den letzten Updates bei meinem Tripower X Modell viel getan. Daher mache ich auch regelmäßig Updates. Allerdings manuell angestoßen. Ein paar Tage kann man ja auf Erfahrungsberichte warten.
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

MadMax

Alles klar, dann halte uns bitte auf dem Laufenden ob sich was ändert :-)
Lenovo M910Q Tiny Debian 12, FHEM 6.3, 2x Siemens Logo 0BA7, Homematic CCU3, Philips HUE, 6x SMA Wechselrichter, BYD HVM, BYD HVS, SMA EVCharger, KEBA Wallbox, 2x HMS800W, Daikin Wärmepumpe über CAN, viele ESPs

Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/MadMax

siggel

Da hab ich doch zum Thema "Update" aus aktuellem Anlass auch direkt eine Frage:

Mein WR (STP10.0SE) hat gegen 19:30 laut Ereignisprotokoll "Update Kommunikation" und "Update Hauptrechner" ausgeführt. Währenddessen sind meine Abfragen im 15s Takt natürlich voll vor die Wand gefahren:
  • Timeouts -> unproblematisch
  • Fehler im SMAInterter.pm im log -> vermutlich unproblematisch
  • Astronomische Werte, z.B. Leistungen wie 80 Mio Watt, Batterie-Prozent 5000 -> zumindest für Plots der Tod  :(

Gibt es hier Best Practice Vorschläge der alten Hasen, die solche Updates evtl. schon öfter hatten, wie sie damit umgehen oder abfangen, dass FHEM Amok läuft?
Oder tatsächlich besser automatische Updates deaktivieren und besser gezielt manuell starten, damit man dann die Abfragen temporär aussetzen kann? Bekommt man da dann trotzdem eine Erinnerung in irgendeiner Form, dass ein Update zur Verfügung steht? Ein Reading dafür ist mir zumindest nicht aufgefallen.
RPi4B, ConBee II, OSRAM/Ledvance Plugs/Switch, Aqara Sensors, IKEA Tradfri Dimmers, Gosund Plugs (Tasmota), Shelly Relays/Plugs/Sensors/Button, D1minis (Tasmota/WLED), Echo Dots, Fire Tablets (FTUI), Indego, Homematic IP CCU3/Thermostats/Sensors, OctoPi3B+, SMA HM2.0/STP10.0-3SE-40, BYD HVS 5.1

300P

Es gibt so etwas ähnliches, was du beschreibst, im Modul SMAEM.
Das ist das attr diffAccept.

Ob so etwas aber einen ,,wild gewordenen WR-Datenlieferanten" komplett bändigen kann ist äußerst fraglich.

Meine Ansicht dazu:
Da wird mehr Energie in etwas versenkt als es bringt. Wie oft passiert wohl so etwas ?

Daten einfach löschen und fertig ist es.😇
Gruß
300P

FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|QNAP|
JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_edge|ESP32CAM

MadMax

Also das Modul überwacht schon Werte die bri Kommunikationsfehler oder wenn der Wechselrichter mist liefert die Ausgabe uns Reading Blocken.
Die Frage ist nur was für Werte genau kamen bei dir.
Ich hatte das noch nicht erlebt bei mir.
Lenovo M910Q Tiny Debian 12, FHEM 6.3, 2x Siemens Logo 0BA7, Homematic CCU3, Philips HUE, 6x SMA Wechselrichter, BYD HVM, BYD HVS, SMA EVCharger, KEBA Wallbox, 2x HMS800W, Daikin Wärmepumpe über CAN, viele ESPs

Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/MadMax

300P

#1793
Zur Info für Heiko:
Heute will die Grafik bei mir mal "besonders genau und zeigen was sie kann" (Screenshot) O:-)

:o
+0.200000000000003 % Anzeigewert Batterieladung (Balkenbreite und Anzahl Nachkommastellen bei der Anzeige)

Gruß
300P



Edit:
Hier noch Daten dazu:

NextHour00 => starttime: 2025-01-15 09:00:00, hourofday: 10, today: 1
              pvapifc: 343, pvaifc: -, pvfc: 343, aihit: 0, confc: 658
              confcEx: 542, DoN: 1, weatherid: 3, wcc: 98, rr1c: 0.00, temp=2.00
              rad1h: 270, sunaz: 137, sunalt: 7
              rrange: 0.00, crange: 100, correff: 0.57/0.00
              soc01: 10.0, soc02: 45.0, soc03: -
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
NextHour01 => starttime: 2025-01-15 10:00:00, hourofday: 11, today: 1
              pvapifc: 477, pvaifc: -, pvfc: 477, aihit: 0, confc: 573
              confcEx: 506, DoN: 1, weatherid: 3, wcc: 97, rr1c: 0.00, temp=2.40
              rad1h: 460, sunaz: 150, sunalt: 13
              rrange: 0.00, crange: 95, correff: 0.46/0.00
              soc01: 10.0, soc02: 45.0, soc03: -
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
NextHour02 => starttime: 2025-01-15 11:00:00, hourofday: 12, today: 1
              pvapifc: 467, pvaifc: 412, pvfc: 412, aihit: 1, confc: 610
              confcEx: 622, DoN: 1, weatherid: 3, wcc: 97, rr1c: 0.00, temp=2.70
              rad1h: 590, sunaz: 164, sunalt: 16
              rrange: 0.00, crange: 95, correff: 0.35/0.00
              soc01: 10.0, soc02: 45.0, soc03: -
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
NextHour03 => starttime: 2025-01-15 12:00:00, hourofday: 13, today: 1
              pvapifc: 669, pvaifc: 857, pvfc: 857, aihit: 1, confc: 807
              confcEx: 381, DoN: 1, weatherid: 3, wcc: 97, rr1c: 0.00, temp=2.80
              rad1h: 630, sunaz: 178, sunalt: 18
              rrange: 0.00, crange: 95, correff: 0.47/0.00
              soc01: 45.0, soc02: 45.2, soc03: -
              rcdchargebat01: 1, rcdchargebat02: 1, rcdchargebat03: -
NextHour04 => starttime: 2025-01-15 13:00:00, hourofday: 14, today: 1
              pvapifc: 465, pvaifc: 470, pvfc: 470, aihit: 1, confc: 874
              confcEx: 449, DoN: 1, weatherid: 3, wcc: 98, rr1c: 0.00, temp=2.90
              rad1h: 610, sunaz: 193, sunalt: 17
              rrange: 0.00, crange: 100, correff: 0.34/0.00
              soc01: 45.0, soc02: 45.0, soc03: -

FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|QNAP|
JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_edge|ESP32CAM

DS_Starter

Moin 300P,

hast vermutlich im falschen Forum gepostet.  ;)
Aber kommt durch die Diff-Anzeige. Muß ich richten. Nachkommastellen begrenzen.

LG
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

300P

Zitat von: DS_Starter am 15 Januar 2025, 09:25:31Moin 300P,

hast vermutlich im falschen Forum gepostet.  ;)


Mist - oh ja - habs grad erst "richtig" bemerkt  ::)  ::)  ::)
FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|QNAP|
JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_edge|ESP32CAM

siggel

Zitat von: MadMax am 15 Januar 2025, 05:42:05Also das Modul überwacht schon Werte die bri Kommunikationsfehler oder wenn der Wechselrichter mist liefert die Ausgabe uns Reading Blocken.
Die Frage ist nur was für Werte genau kamen bei dir.
Ich hatte das noch nicht erlebt bei mir.

Ja, den Fall, dass das Modul neben den genannten Fehlertypen auch Kommunikationsfehler eigenständig erkannt hat, kann ich bestätigen, habe ich in meiner Aufzählung vergessen.
Aber eben auch unerkannte Fehler - wie es auch heute genau 1x wieder geloggt wurde ohne dass gleichzeitig ein Update stattfand:
2025-01-15_12:00:35 StromzaehlerExtension power_battery_charge_in_W: -4294967295
2025-01-15_12:00:35 StromzaehlerExtension power_battery_discharge_in_W: 4294967295
was bis auf Umrechnung kW nach Watt und Vorzeichen genau den Readings von SMAInverter entspricht:
 
my $power_battery_charge_in_W = - 1000 * ::round(ReadingsNum("SMAWechselrichter", "bat_p_charge", 0), 3); # negative (battery receives energy)
my $power_battery_discharge_in_W = 1000 * ::round(ReadingsNum("SMAWechselrichter", "bat_p_discharge", 0), 3);
Zeitgleich im FHEM log (SMAInverter Version 2.29.1):
2025.01.15 12:00:35.885 1: PERL WARNING: Argument "-" isn't numeric in multiplication (*) at ./FHEM/76_SMAInverter.pm line 1371.
Also vermutlich ergibt sich der unplausible Wert daraus, dass Perl dann irgendeinen Default statt des - nimmt? Vielleicht hat ja SMA seit dem gestrigen Update einen Bug, dass es - statt 0 liefert? Aber nur manchmal, denn 99.9% der Zeit läuft es ja fehlerfrei.
RPi4B, ConBee II, OSRAM/Ledvance Plugs/Switch, Aqara Sensors, IKEA Tradfri Dimmers, Gosund Plugs (Tasmota), Shelly Relays/Plugs/Sensors/Button, D1minis (Tasmota/WLED), Echo Dots, Fire Tablets (FTUI), Indego, Homematic IP CCU3/Thermostats/Sensors, OctoPi3B+, SMA HM2.0/STP10.0-3SE-40, BYD HVS 5.1

siggel

#1797
Gelöst, siehe unten

Weitere Auffälligkeit:
device_firmware wird bei mir merkwürdigerweise trotz "get SMAWechselrichter data 2" nicht aktualisiert,
  • Oberfläche des Wechselrichters: 3.5.26.R
  • Reading device_firmware: 3.4.16 R
Wird das evtl. vom Modul nicht mehr verarbeitet, weil da - zumindest in der Oberfläche - ein Punkt vor dem R steht, den das alte Reading nicht hatte, so dass da eine regexp nicht mehr passt?

Lösung:
Hab in die Quellen geschaut und gesehen, dass es an der Art meiner Abfragen liegen wird:
  • Die Firmware Version wird vom Modul nur jeden 50. Request abgefragt (genauso wie ein paar eher statische Batterie-Werte, wie z.B. Kapazität) und das auch nur bei Detail-Level 2
  • Ich frage 4x pro Minute mit Detail-Level 0 ab, alle 6 Stunden einmal mit Detail-Level 2.
  • Dürfte bei mir also sehr selten auftreten, dass 50. Request und Detail-Level 2 aufeinandertreffen.
RPi4B, ConBee II, OSRAM/Ledvance Plugs/Switch, Aqara Sensors, IKEA Tradfri Dimmers, Gosund Plugs (Tasmota), Shelly Relays/Plugs/Sensors/Button, D1minis (Tasmota/WLED), Echo Dots, Fire Tablets (FTUI), Indego, Homematic IP CCU3/Thermostats/Sensors, OctoPi3B+, SMA HM2.0/STP10.0-3SE-40, BYD HVS 5.1

300P

Die Hexadezimalzahl von 4294967295 lautet: ffffffff

Das würde evtl. ja von MadMax im Code abgefangen werden können.

Gruß
300P
FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|QNAP|
JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_edge|ESP32CAM

300P

Da wird MadMax sicherlich noch eine komplette Runde des Datenabrufes mit Verbose = 5 von dir dazu benötigen.....
FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|QNAP|
JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_edge|ESP32CAM