76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

DS_Starter

Ah, guter Hinweis.  :)  Jetzt wo du es sagst sehe ich es auch (nutze Notepad++).
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

tomcat.x

Damit habe mich mir jetzt eine Frage verdient oder? Und wenn ich sage, dass es noch (16?) weitere Zeilen damit gibt, vielleicht eine 2.  ;D
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DS_Starter

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

tomcat.x

Hallo Heiko,

hier meine Frage. Ich habe einige solcher Einträge im Log:

The calculated Energy consumption of the house is negative. This appears to be an error and is not saved. Check Readings _PVreal, _GridFeedIn, _GridConsumption, _BatIn_XX, _BatOut_XX of hour >24<
Da wollte ich jetzt mal versuchen, ob ich die weg bekomme. Vermutlich nur unterschiedliche Intervalle bei der Datenlieferung.

Meine eigentliche Frage bezieht sich aber auf die BatIn und BatOut Werte. Die sind bei mir immer 0. Woraus bzw wie werden die denn berechnet?

Viele Grüße
Thomas
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DS_Starter

ZitatMeine eigentliche Frage bezieht sich aber auf die BatIn und BatOut Werte. Die sind bei mir immer 0. Woraus bzw wie werden die denn berechnet?


Diese Werte werden pro Stunde berechnet und liest die Angaben aus den Schlüsselreadings (Batterie) intotal und outtotal. Es sind also Differenzen da intotal und outtotal stetig hochzählen sollten.
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

DS_Starter

#3470
Hier nochmal zum Wide Character Fehler:

ZitatKann das Zeichen '...' den Wide-Character-Fehler verursachen?
Ein normaler ASCII-Ziffern-8 (Codepunkt U+0038) löst keinen Wide-Character-Fehler aus, denn er liegt im Bereich 0–255 und passt in ein einzelnes Byte.

Der gezeigte Ausdruck nutzt jedoch typografische Anführungszeichen:

* Die Zeichen ' und ' sind nicht das einfache ASCII-Apostroph (0x27), sondern Unicode-Codepunkte U+2018 (LEFT SINGLE QUOTATION MARK) und U+2019 (RIGHT SINGLE QUOTATION MARK).

* Diese Codepunkte liegen weit über 255 und werden in UTF-8 als Mehr-Byte-Sequenz kodiert.

Solche Zeichen in einem als Unicode-String markierten Perl-Scalar, der ohne UTF-8-Ausgabe-Layer (binmode) ausgegeben wird, führen genau zum ,,Wide character in print"-Fehler.

Jetzt haben wir es.  Im Modul habe ich natürlich alle Vorkommen eliminiert.
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

tomcat.x

Zitat von: DS_Starter am 07 Juli 2025, 16:15:16Es sind also Differenzen da intotal und outtotal stetig hochzählen sollten.

Ah, ok. Die habe ich nicht. Nur pin und pout. Also  intotal und outtotal habe ich nicht nur nicht definiert, sondern die werden so auch nicht fertig geliefert. Aber ich schaue noch mal, Wäre schon interessant.
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DS_Starter

Das wäre für die Energiesummenbildung relevant. Sonst fehlen diese Anteile. Wenn outtotal fehlt, kann dein Hausverbrauch negativ werden da:

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung

bzw. Wiki. Da steht es drin wie gerechnet wird.
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

tomcat.x

Zitat von: DS_Starter am 07 Juli 2025, 16:18:55sondern Unicode-Codepunkte U+2018 (LEFT SINGLE QUOTATION MARK) und U+2019 (RIGHT SINGLE QUOTATION MARK

Ja, wenn man das in den Hex-Editor richtig einfügt (als Unicode), dann sieht man das auch so und nicht 91 und 92 wie oben geschrieben. Ich glaube, meine 2. Frage muss ich mir dann noch aufheben.  :-[
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DS_Starter

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

tomcat.x

Na gut, auch wenn ich eher intotal und outtotal definieren müsste, die Batterie liefert die nämlich laut MQTT Explorer doch.

Also es geht um die Verbrauchersteuerung. Zum einen hatte ich da mal in der Liste der Verbraucher auf die Uhr geklickt. Das "Klick für sofortige Einplanung" hatte ich aber wohl falsch verstanden. Ich dachte "sofortige Einplanung" startet die Berechnung noch mal neu, mit den aktuellen Werten. Die Spülmaschine ist aber direkt angegangen. Gibt es dann einen Unterschied zum einfachen Einschalten über den Schieberegler? Gemacht hatte ich das, weil ich vorher den Automatikmodus erst eingeschaltet hatte. Bei dem ist mir aufgefallen, dass alle Verbraucher laut Log eingeplant werde, auch solche mit "Automatik aus". Macht das Sinn? Nehmen die anderen Geräten dann nicht den Slot weg obwohl sie gar nicht gestartet werden könnten?
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

tomcat.x

Zitat von: DS_Starter am 07 Juli 2025, 16:31:04Das wäre für die Energiesummenbildung relevant. Sonst fehlen diese Anteile. Wenn outtotal fehlt, kann dein Hausverbrauch negativ werden da

Ok, sind definiert. Die Batterie liefert die Werte aber auf Tagesbasis. Passt das zu "Sollte des Reading die Vorgabe eines stetig aufsteigenden Zählers verletzen ..." oder bekomme ich dann jede Nacht einen Eintrag im Log?
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

DS_Starter

Ja es gibt Unterschiede zwischen den Methoden:

- consumerImmediatePlanning (Soforteinplanung): Es wird das sofortige Einschalten des Verbrauchers zur aktuellen Zeit eingeplant. Eventuell im consumerXX Attribut gesetzte Schlüssel notbefore, notafter bzw. mode werden nicht beachtet -> D.h. der Verbraucher wird ab der aktuelen Zeit eingeplant und auch eingeschaltet sofern die Elemente PV-Überschuß und andere Festlegunge im Consumer erfüllt sind.

Diese Methode wird auch beim Click auf das Uhrensymbol angewendet.

- consumerNewPlanning: Es wird die vorhandene Planung des angegebenen Verbrauchers gelöscht. Die Neuplanung wird unter Berücksichtigung der im consumerXX Attribut gesetzten Parameter sofort vorgenommen. -> hier wird die Einplanungszeit wieder optimiert gesucht. Die Einplanung wird sofort vorgenommen, aber der Start des Zeitfensters kann z.B. erst in 3 Stunden sein.

ZitatGibt es dann einen Unterschied zum einfachen Einschalten über den Schieberegler?
Ja, der Schieberegeler ist keine Einplanung und unterliegt auch nicht der Modulsteuerung. Er ist im Prinzip identisch zu einem manuellen Schalten des Gerätes. Im Status des Consumers wird dann auch "von extern umgeschaltet erscheinen".

ZitatBei dem ist mir aufgefallen, dass alle Verbraucher laut Log eingeplant werde, auch solche mit "Automatik aus". Macht das Sinn?
Ja, macht Sinn. Die Automatik kann man für weiterführende Steuerungsaufgaben nutzen, z.B. eine Chain aufbauen. Man lässt alle Consumer planen, setzt aber alle außer den ersten auf Automatik=off. Ist der erste Consumer fertig, wird der nächste mit Automatik=on freigeschaltet und arbeitet seine Einplanung ab usw.

ZitatNehmen die anderen Geräten dann nicht den Slot weg obwohl sie gar nicht gestartet werden könnten?
In gewisser Weise schon. Deswegen sollte man dauerhaft auch nur die Consumer planen lassen die man auch steuern lassen will. Macht ja sonst wenig Sinn. Alle anderen kann man mit type=noSchedule definieren zur Anzeige und manuellen Schalten.
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

DS_Starter

ZitatDie Batterie liefert die Werte aber auf Tagesbasis. Passt das zu "Sollte des Reading die Vorgabe eines stetig aufsteigenden Zählers verletzen ..." oder bekomme ich dann jede Nacht einen Eintrag im Log?
Das kommt ein bisschen auf das Zeitregime an. SF registriert den Anfangszustand zu Beginn jeder Stunde. Wenn die Bat vorher zur Stunde 0 auf 0 setzt kommt keine Meldung, sonst vllt. eine mit verbose 3.
Ich würde SF mit verbose 2 laufen lassen sobald alles zur Zufriedenheit eingerichtet ist.
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

tomcat.x

Zitat von: DS_Starter am 07 Juli 2025, 17:11:46Deswegen sollte man dauerhaft auch nur die Consumer planen lassen die man auch steuern lassen will.
Schon klar. Aber es werden ja explizit Gerätetypen wie Waschmaschine, Trockner und Spülmaschine angeboten. Und die laufen (zumindest bei uns) nicht täglich. Und bei einem BKW reicht der Überschuss dann nicht immer gleich für alle Geräte. Würde mich eh mal interessieren, wie viele Nutzer hier was richtiges auf dem Dach haben oder so wie ich um "jede Wattstunde" kämpfen müssen.

Zitat von: DS_Starter am 07 Juli 2025, 17:17:32Das kommt ein bisschen auf das Zeitregime an.
Ok, mit Kenntnis der Logik kann man den Zeitpunkt der Nullung ja manuell vorziehen, damit keine Meldung kommt.

Zitat von: DS_Starter am 07 Juli 2025, 17:17:32Ich würde SF mit verbose 2 laufen lassen sobald alles zur Zufriedenheit eingerichtet ist.
Bei den vielen Optionen, die SolarForecast bietet, komme ich da nie hin ;-) Außerdem schraube ich ja ständig an der Hardware. Da liegt schon wieder ein Wechselrichter mit ein paar kleinen Panels im Keller.
FHEM: 6.3 auf Raspi 4B, Raspbian (noch Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.10), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo