76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

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

Vorheriges Thema - Nächstes Thema

TheTrumpeter

Ich habe eine Frage zur Steuerung von unterbrechbaren Verbrauchern...

Ich habe einen unterbrechbaren Verbraucher mit Modus "CAN" definiert, dessen Automatik-Modus ich durch ein anderes Gerät aktivieren lasse, manchmal aber vorübergehend manuell beende:
attr mySolarForecast consumer12 tuya_local_bf54bbb452c7573947v0yv type=other power=500 mode=can on=on off=off asynchron=1 pcurr=cur_power:W:8 etotal=energy:kWh mintime=SunPath swstate=state:on:off auto=solarforecast_auto icon=scene_laundry_room_fem notbefore={sprintf('%02d:%02d', (split ':', main::sunrise_abs('HORIZON=0',30*60))[0], (split ':', main::sunrise_abs('HORIZON=0',30*60))[1])} interruptable=1 locktime=600:300
Die Automatik ist seit gestern Abend aktiv.
Heute um 06:15 wurde der Verbraucher korrekt automatisch eingeschaltet.
Um 06:18 habe ich zuerst den Automatikmodus mittels Schieberegler deaktiviert, danach den Verbraucher mittels Schieberegler ausgeschaltet.
Um 06:28 habe ich den Automatikmodus wieder mittels Schieberegler aktivert.
Jetzt, 06:43, steht da sinngemäß "Überschuss ausreichend, Planungsstatus started, Info von extern umgeschaltet, verbleibende Sperrzeit 0 Sekunden". Der Verbraucher wird aber nicht aktiviert.

Luftentfeuchter (state='off', mode='can', planningstate='started', info='von extern umgeschaltet')
Geplanter Start (consumer12_planned_start)30.07.2026 06:15:06
Geplanter Stopp (consumer12_planned_stop)30.07.2026 20:34:00

Ich habe dieses Verhalten schon öfter beobachtet, aber noch keine Bedienstrategie gefunden, mit der die Automatik wieder sauber übernimmt, sobald ich sie aktiviere.
Wenn ich den Verbraucher nun händisch einschalte, glaube ich, dass die Automatik danach wieder übernimmt. Dabei habe ich aber immer ein mulmiges Gefühl im Bauch, dass sie vielleicht doch nicht "komplett" übernimmt und der Verbraucher dann bei mangelndem Überschuss nicht ausgeschaltet wird.

Ich habe nun mittels Schieberegler eingeschaltet, der Status ist sinngemäß "continued, Info -, verbleibende Sperrzeit 267 Sekunden".
Schaut also so aus, als ob nun die Automatik wieder "voll am Zug" ist.

Eigentlich würde ich erwarten, dass beim (De-) Aktivieren des Automatikmodus SolarForecast die Steuerung unabhängig vom Status davor vollständig abgibt bzw. übernimmt, d.h.:
  • Beim Deaktivieren geschieht danach nichts mehr, es wird weder ein- noch ausgeschaltet (scheint so zu sein)
  • Beim Aktivieren übernimmt SF vollständig, unabhängig vom aktuellen Schaltzustand oder sonstigen Randbedingungen. In meinem aktuellen Fall war der Verbraucher aus, der Überschuss war ausreichend und innerhalb der geplanten Zeit. Daher sollte der Verbraucher eingeschaltet werden. (Der Status wäre streng genommen "started" und nicht "continued", weil die Automatik gerade aktiviert wurde und SF nach dem Aktivieren der Automatik erstmals eingeschaltet hat.) Wäre der Verbraucher "ein" gewesen, müsste SF ihn bei mangelndem Überschuss auch sofort deaktivieren (oder von mir aus noch die Sperrzeit ab Aktivieren der Automatik abwarten).


Wie ist die korrekte Betriebsstrategie für so einen Fall?
Ist es dabei egal ob der Verbraucher beim (De-) Aktivieren der Automatik gerade "ein" oder "aus" ist?
Muss eine etwaige noch nicht abgelaufene Sperrzeit dabei berücksichtigt werden?
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

300P

Ja - ähnliches Verhalten (-> schon immer ) am Ende wird bei mir.

Wenn ich die WaMa per "Fritz-Dect-Geräteschalter" manuell 1 x aus / 1 x ein geschaltet habe.....
->> Nach XYX Min "Restlaufzeit" wird dann die WaMa in einem solchen manuellen Schaltungfall ausgeschaltet. :o
       passiert mit öfters wenn ich die WaMa am Abend vergessen habe zu füllen...... O:-)

Ich drücke bislang dann einfach immer auf "sofortige Neuplanung" am SF-Display ->> nach der manuellen "Wiederinbetriebnahme" durch mich.  ;)
Automatik/Zeitablauf wurde ja allein durch mich unterbrochen / abgeändert
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast| DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP| ESP32_AI_on_the_Edge|ESP32CAM usw.

TheTrumpeter

Zitat von: 300P am 30 Juli 2026, 08:32:30Ich drücke bislang dann einfach immer auf "sofortige Neuplanung" am SF-Display
Guter Hinweis, das kann ich mal probieren. Klappt das auch auf mobile/tablet-Oberfläche?

Zitat von: 300P am 30 Juli 2026, 08:32:30Automatik/Zeitablauf wurde ja allein durch mich unterbrochen / abgeändert
Ich gebe Dir völlig Recht, aber warum macht es einen Unterschied wie viel Zeit zwischen den manuellen Eingriffen vergeht?
Wenn die Waschmaschine lange genug ausreichend Strom zieht, wird die Automatik für den Luftentfeuchter im entsprechenden Raum aktiviert. Bei Überschuss wird dieser dann auch gleich eingeschaltet, wenn nicht entsprechend später.
Irgendwann am nächsten Tag deaktiviere ich die Automatik wieder und schalte das Gerät über den Schieberegler aus.
Die nächste Wäscheladung ein paar Tage später aktiviert dann wieder und es wird sauber geschaltet.

Wenn ich aber zwischendurch mal kurz unterbrechen will, verhält es sich anders/"komisch".
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

DS_Starter

#6753
@TheTrumpeter & 300P,

ZitatHeute um 06:15 wurde der Verbraucher korrekt automatisch eingeschaltet.
Um 06:18 habe ich zuerst den Automatikmodus mittels Schieberegler deaktiviert, danach den Verbraucher mittels Schieberegler ausgeschaltet.
Um 06:28 habe ich den Automatikmodus wieder mittels Schieberegler aktivert.
Jetzt, 06:43, steht da sinngemäß "Überschuss ausreichend, Planungsstatus started, Info von extern umgeschaltet, verbleibende Sperrzeit 0 Sekunden". Der Verbraucher wird aber nicht aktiviert.
.....
Wie ist die korrekte Betriebsstrategie für so einen Fall?
Ist es dabei egal ob der Verbraucher beim (De-) Aktivieren der Automatik gerade "ein" oder "aus" ist?
Muss eine etwaige noch nicht abgelaufene Sperrzeit dabei berücksichtigt werden?

Der Zusammenhang ist systemtechnisch bedingt. Intern wird eine Tabelle mit den automatisch ausgeführten Schaltstatus geführt. Diese Tabelle wird zum Beginn/Ende eines geplanten Zyklus oder einer Neuplanung mit der Realität synchronisiert (deswegen bekommt 300P damit seinen Case geregelt). Durch den Vergleich des Schaltststatus mit dem Tabellenstatus werden die manuellen Schaltvorgänge erkannt.

Warum nicht zwischendurch synchronisieren? Das hat seinen Grund in der historischen Entwicklung der Anfoderungen, z.B.

- die WaMa ist mit dem Autmatikmodus gestartet und es soll einfach ein Wäschestück nachgeladen werden.
  Der User drückt am Schalter der Schaltdose aus, öffnet sie, packt das Stück hinein, schließt sie wieder und
  schaltet die Dose wieder per Schalter ein. Das ist genau der Fall wo die Logik wie gewünscht
  weiterlaufen wird. In diesem Fall soll die Dose nicht! einfach beim SF-Zyklus wieder eingeschaltet werden
  wenn der User mitten bei der Arbeit ist.

  Sinngemäß trifft das auf alles andere auch zu, z.B. eine Pumpe die vllt. gerade mal verstopft ist und
  nachgeschaut wird.


TheTrumpeter war vorbildlich und hat erst die Automatik ausgeschaltet und danach manuell geschaltet. Das ist auch völlig richtig so, es gibt aber einen wesentlichen Punkt. Die Logik funktioniert immer problemlos wenn diese Schaltvorgänge ausgeführt werden:

  Ausgangszustand ein:  Automatik aus -> Switch aus ... Switch ein -> Automatik ein    oder

  Ausgangszustand aus:  Automatik aus -> Switch ein ... Switch aus -> Automatik ein   

oder ohne Automatik Bedienung

  Ausgangszustand ein:  Switch aus ... Switch ein    oder

  Ausgangszustand aus:  Switch ein ... Switch aus

In allen diesen Fällen wird die Automatiklogik völlig problemlos weiterlaufen.
Allen diesen Vorgängen ist gemeinsam, dass der Schaltzustand VOR der manuellen Manipulation gleich dem Schaltzustand NACH der Manipulation ist.

Um bei dem WaMa Beispiel zu bleiben passiert sonst folgendes.
Die Automatik hat die WaMa eingeschaltet, das Gerät läuft. In der internen Tabelle ist der Zustand "ich habe eingeschaltet" hinterlegt. Jetzt schaltet man die Automatik aus, schaltet die WaMa aus, aber NICHT! wieder ein und die Automatik ein.
Dann sagt das interne System "ich habe eingeschaltet", es wurde aber manuell ausgeschaltet (und das Gerät ist auch noch aus) -> dann will es der User wohl so -> Ende.
In diesen Fällen wird die Automatik wieder "einrasten" wenn SF z.B. per Interrupt das Gerät automatisch unterbricht und danach wieder fortsetzt. Dann stimmt der interne Tabellenstatus und die Realität wieder überein.

Zur Lösung kann man wie oben beschrieben handeln und/oder mir fällt ein praktikables Verfahren ein, dass NUR bei der Automatik-Schaltflanke AUS->EIN ein Tabellensynch vorgenommen wird.
Das würde allerdings u.U. auch dazu führen, dass der Verbraucher beim Synch kurz eingeschaltet wird um im nächsten SF-Zyklus wieder ausgeschaltet zu werden. Könnte mir vorstellen, dass sowas auch nicht jeder Anwender schön findet.

LG,
Heiko
 
 

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

Für mich ist alles okay so wie es ist.

Zitat von: TheTrumpeter am 30 Juli 2026, 11:26:09Guter Hinweis, das kann ich mal probieren. Klappt das auch auf mobile/tablet-Oberfläche?

ich mache es derzeit auf einem Iphone17 - da klappt es (Safari)
oder aber - weil ich morgens nach dem Frühstück online Nachrichten lese - auch manchmal auf einem MAC mit Safari - klappt auch.
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast| DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP| ESP32_AI_on_the_Edge|ESP32CAM usw.

TheTrumpeter

Zitat von: DS_Starter am 30 Juli 2026, 18:02:34Schaltzustand VOR der manuellen Manipulation gleich dem Schaltzustand NACH der Manipulation ist.
OK, d.h. ich schalte künftig zuerst die Steckdose aus, dann die Automatik aus, dann die Automatik ein.
Dann sollte SF wieder sauber übernehmen.

(Mit Schaltzustand "ein" ist es bei umgekehrter Bedienung gestern auch so, gewesen: (Steckdose ist durch Automatik ein) Automatik aus, Steckdose aus, Automatik ein, Steckdose ein. Erst nach dem letzten Schritt übernimmt SF wieder, weil der Schaltzustand dem des Automatikmodus vor dessen Deaktivierung entspricht.)
FHEM auf RPi3, THZ (LWZ404SOL), RPII2C & I2C_MCP342x (ADCPiZero), PowerMap, CustomReadings, RPI_GPIO, Twilight, nanoCUL (WMBus für Diehl Wasserzähler & Regenerationszähler für BWT AqaSmart), ESPEasy, TPLinkHS110

peterboeckmann

Hallo Heiko,

Zitat von: DS_Starter am 30 Juli 2026, 18:02:34Zur Lösung kann man wie oben beschrieben handeln und/oder mir fällt ein praktikables Verfahren ein, dass NUR bei der Automatik-Schaltflanke AUS->EIN ein Tabellensynch vorgenommen wird.
Das würde allerdings u.U. auch dazu führen, dass der Verbraucher beim Synch kurz eingeschaltet wird um im nächsten SF-Zyklus wieder ausgeschaltet zu werden. Könnte mir vorstellen, dass sowas auch nicht jeder Anwender schön findet.

Und wenn Du nicht den Schaltzustand an die Tabelle anpasst, sondern den Tabelleninhalt an den aktuellen State des Verbrauchers?

Viele Grüße,
Peter
MQTT,Modbus,HTTPMod,DbLog,LaCrosse,SolarForecast,TelegramBot,Twilight,vitoconnect,withings
fhem,fhempy,debmatic
Debian
RaspberryPi5,HomeMatic,HomeMaticIP,Shelly,JeeLink,SignalDuino,ZWDongle,SONOS,alexa,Hue,tradfri,MobileAlerts,Siemens Home Connect,Roborock S50,Wallbox,Harmony,Tuya Smartlife

DS_Starter

Hallo Peter,

absolut richtig der Hinweis von dir.

Es gibt im Modul inzwischen eine ziemlich ausgefeilte Consumersteuerung. Ich muß mir vor solchen Eingriffen in die Logik genau anschauen welche
Effekte die Änderungen auf die Ablauflogik haben. Deswegen muß ich behutsam vorgehen. Aber das werde ich machen und vielleicht gibt es eine Lösung die ich nur noch nicht herausgearbeitet habe.

LG,
Heiko
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

#6758
Hallo zusammen,

in meinem contrib liegt ein Update der V 2.9.3.
Inhalt:

- Die reset-Funktion 'set ... reset ..' kann Daten in pvCircular suchen, löschen und bearbeiten
- Einbau hint27 und hint28 sowie Überprüfung hint12 abhängig von aiConShuffleMode und aiConShufflePeriod
- NEU: Implementierung einer sequentiellen Energiebilanz-Simulation der PV-Prognose in Abhängigkeit der PV Raw-Prognose, der Verbrauchsprognose, dem eingestellten FeedIn-Limit und der Batterie Ladungsprognose.
  Dadurch wird die Unterstützung einer Nulleinspeisung bzw. eines gesetzten Einspeiselimits in der PV Prognose berücksichtigt.
- NEU: neue Auswahl pvForecastLimited im Attribut 'graphicBeamXContent' zur Anzeige der PV-Prognose unter Berücksichtigung einer gesetzten Einspeiselimitierung im Attribut plantControl->feedinPowerLimit


Die Legacy PV-Prognose kann nun eine Simulation der erwartbaren in Bezug zur möglichen PV-Erzeugung entsprechend den gesetzten Rahmenbedingungen wie Vorhandensein Batterie und deren Ladezustand, progostizierter Hausverbrauch und gesetztes Einspeiselimit bis hin zur Nulleinspeisung vornehmen.
Für die Anzeige im Balkendiagramm gibt es die neue Auswahl 'pvForecastLimited'. Damit kann man sich z.B. die erwartbare und limitierte Prognose in einer Ebene zusammen darstellen und kann die Entwicklung abschätzen.

LG,
Heiko
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