Grundsätzliches zu den PWM-Schaltern ab SAE2.0.4 (beta)

[ShareForAll]

Den Betrieb der SAE Version 1.6.20 habe ich mit den Installationsbeschreibungen hinbekommen, so dass ich derzeit einen 3kW-Heizstab bei entsprechend eingestelltem PV-Überschuss Schwellwert im SunnyPortal zuschalten kann. (GPIO 4 ("wPi"). Die HW-Ansteuerung ist PWM-fähig (über Halbleiterrelais..), so dass ich neugierig die SAE 2.0.4 (beta) ausprobiert habe, mit der "Vorstellung", dass je nach PV-Überschuss eine entsprechend geeigneter PWM-Tastgrad automatisch eingestellt wird... Fragen:

1. Ein gewählter Tastgrad-Bereich im SAE zwischen 0% und 100% wird auch tatsächlich nur in dem Zeitfenster ausgeführt, dass man unter "Schaltzeiten" definiert, richtig? Also außerhalb des Zeitfensters sollte der Tastgrad praktisch immer = 0% sein (="Aus")? (Bei meinen Versuchen, wurde ein Min-Tastgrad von z.B. 10% auch außerhalb des Zeitfensters ausgeführt.... vermutlich Konfigfehler meinerseits?) ich habe mich an die Beschreibung der "manuellen Installation" und an den Infos unter https://github.com/camueller/SmartApplianceEnabler/blob/2.0/doc/PwmSwitch_DE.md orientiert.
2. Kann man bei den Schalten vom Typ "PWM" irgendwie konfigurieren, welche "Stufen" zwischen Min.- und Max-Tastgrad vom System gewählt werden und auch in welchen Zeitabständen der Tastgrad neu ermittelt/ gewählt wird
   Ich bin momentan zur 1.6.20 zurückgekehrt. Dabei genügt es doch, wenn man

• den MQTT-Broker dauerhaft deaktiviert (über webmin zwei mosquitto services) und
• den pigpiod.service deaktiviert
• im SAE wieder die "wPi"-GPIO zu wählen?
  Ich hoffe, ich habe nicht zuviel geschrieben und falls das alles schon anderswo beantwortet wurde, dann habe ich nicht gründlich genug gesucht und ein Admin möge bitte diesen Post löschen... Danke.

[camueller]

Ein gewählter Tastgrad-Bereich im SAE zwischen 0% und 100% wird auch tatsächlich nur in dem Zeitfenster ausgeführt, dass man unter "Schaltzeiten" definiert, richtig?

Ja, das gilt so für alle Schalter.

Bei meinen Versuchen, wurde ein Min-Tastgrad von z.B. 10% auch außerhalb des Zeitfensters ausgeführt...

Hast Du ein Log?

Kann man bei den Schalten vom Typ "PWM" irgendwie konfigurieren, welche "Stufen" zwischen Min.- und Max-Tastgrad vom System gewählt werden und auch in welchen Zeitabständen der Tastgrad neu ermittelt/ gewählt wird

Bei PWM gibt es keine "Stufen" - es ist stufenlos! Der Tastgrad wird immer dann gesetzt, wenn der SHM die Leistungsaufnahme ändern möchte. Das passiert frühestens 60s nach der letzten Änderung.

Ich bin momentan zur 1.6.20 zurückgekehrt. Dabei genügt es doch, wenn man
den MQTT-Broker dauerhaft deaktiviert (über webmin zwei mosquitto services) und
den pigpiod.service deaktiviert
im SAE wieder die "wPi"-GPIO zu wählen?

Den MQTT-Broker kannst Du laufen lassen, der wird bei SAE 1.6 einfach ignoriert. Auch den pigpiod.service kannst Du einfach weiterhin laufen lassen - er wird ebenfalls ignoriert. Die GPIO-Nummern sind natürlich anders. Ich würde einfach eine Appliances.xml für SAE 1.6 verwenden und eine für SAE 2.0. Du musst dann nur die jeweilige Version platzieren zusammen mit der entsprechenden SmartApplianceEnabler*.war-Datei.

Ich finde es gut, dass Du PWM testest - meines Wissens hat noch niemand diese Funktionalität im Einsatz. Ich selbst habe das nur mit einem Servo getestet. Wenn Dir was auffällt oder Du Fragen hast, dann melde Dich - ich versuche, zeitnah zu antworten und ggf. auch Code-Anpassungen zeitnah zu machen.

P.S.: Du bist Robin und hattest mich auch schon per Email kontaktiert, korrekt?

[ShareForAll]

a) Ich versuche demnächst das "Problem" zu reproduzieren und dann auch an einen brauchbaren Logfile-Ausschnitt zu denken...
b) Bei "Stufen" habe ich mich missverständlich ausgedrückt: Ich dachte mehr an eine "optionale" Zusatz-Konfigdatei, in die man die "Tastgrade" vorgeben könnte, die dann vom SHM verwendet werden sollten (und nur die!), also eine "Quasi-Stufenschaltung" durch diskret vorgegebene Tastgrade, von denen sich der SHM den passenden wählt... z.B. Min-Tastgrad: 20%, Max-Tastgrad: 100% und in der Konfigdatei definiert man z.B. 40%, 60%, 80%... solange die Kriterien (definierter PV-Überschussanteil im SunnyPotrtal für das Device) für den nächsthöheren Tastgrad nicht erfüllt sind, bleibt man beim gegenwärtigen... aber wenn alle 60s eine Neubewertung der PV-Überschusssituation durch den SHM erfolgt und dann der Tastgrad eben auch in einzelnen, kleinen Prozentschritten angepasst wird, dann ist das Ganze eben noch dynamischer... Was wäre Deine theoretische Erwartung bei dem Bsp:
4kW-Wirkleistungbegrenzung für Einspeisung, 10%-PV-Überschuss beim "Schieberegler" im SunnyPortal definiert, so dass also erst ab 4,4kW der PWM-Schalter aktiviert wird ("Schwelle") (MIn-Tastgrad sei 0% und Max-Tastgrad sei 100%, wobei 100% 3000W entsprechen). Welcher Tastgrad würde/ sollte im Logfile auftauchen, wenn z.B. 4,5kW PV-Ertrag anliegen? 100W über der Schwelle von 4,4kW, sollte dann ein tastgrad zwischen 3% und 4% gesetzt werden? Oder beziehen sich die 10% beim PV-Überschuss auf den Verbraucher, also erst wenn mind. 300W (bei meinem Bsp.) oberhalb der 4kW liegen, wird der PWM-Schalter aktiv, also bei 4,3kW und dann würde der SHM mit einem Tastgrad von 10% beginnen...?
c) zu Deiner P.S.-Frage: korrekt!

[camueller]

Wenn Du Stufen willst, kannst Du den Stufenschalter verwenden.

[ShareForAll]

Heute nochmal ein Versuch mit SAE 2.0.4 gestartet (von GPIO Nummer 4 (unter 1.6.20) auf 23 umgestellt, sae 2.0.4.war neu gestartet):
Anbei screenshots vom SAE-Status und der SAE-Konfig eines Device mit Schaltertyp "PWM"; auch das logfile aus /tmp beigefügt (einmal das komplette Log und einmal mit grep "F-15012020-000000000001-00" nur zu dem einen (bis jetzt) tatsächlich konfigurierten Device 01).
Beobachtungen:

1. Im Sunnyportal ist das konfigurierte Zeitfenster (07:50 - 16:00h) nicht bei der zugehörigen Device-Zeitleiste eingetragen. (siehe screenshot)
2. im log finde ich keine offensichtlichen Fehler (Einschätzung als absoluter Laie natürlich!)
3. selbst ein kleiner Tastgrad scheint nicht gesetzt zu werden... vllt. will der SHM auch zuerst den Batteriespeicher aufladen und es ist gar kein "Fehler"....?
   Fehlen irgendwelche Service-Meldungen im Log, die bei einem Device mit Schalter "PWM" auftauchen müssten?

rolling-2022-06-25.log
2022.06.25_tmp-Log.txt
?

[ShareForAll]

Da ich leider nicht richtig mit der SAE 2.0.4. umgehen kann (Schaltertyp "PWM") wollte ich wieder auf die 1.6.20 zurück, aber leider habe ich wohl 'was "zerkonfiguriert": Jetzt kann ich den "systemctl restart smartapplianceenabler.service" nicht mehr erfolgreich ausführen:

sae@raspberrypi:~ $ systemctl status smartapplianceenabler.service
● smartapplianceenabler.service - Smart Appliance Enabler
Loaded: loaded (/lib/systemd/system/smartapplianceenabler.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2022-06-25 15:28:21 CEST; 2min 11s ago
Process: 332 ExecStart=/opt/sae/smartapplianceenabler start (code=exited, status=203/EXEC)
Leider kein Image vom letzten funktionierenden Zustand vorhanden (ist auch mein Fehler, ich weiß...)
Danke für Tipps.

[camueller]

Die Appliances.xml von SAE 2.0 passt nicht für den SAE 1.6. Poste mal die Datei hier (die IDs kannst nur anonymisieren), dann modifiziere ich die Datei so, dass sie für den SAE 1.6 passt.

[ShareForAll]

Danke für das rasche Unterstützungsangebot! Ich habe den Raspi mit der automatischen Standardinstallation (1.6.20) von https://github.com/camueller/SmartApplianceEnabler/blob/master/doc/Installation_DE.md neu aufgesetzt, so dass ich jetzt wieder einen funktionierenden 1.6.20 Stand habe mit Schaltertyp "GPIO"... Nachdem ich ein Sicherungsimage von diesem Stand angelegt habe (und die beiden Konfigdateien "Appliances.xml" + "Device2EM.xml", wage ich mich dann vllt. 'mal wieder an die 2.0.4 (oder höher, wenn/ sobald verfügbar)...
Die logfiles von der 2.0.4 im letzten Post sind nicht brauchbar im Hinblick auf die Frage, ob etwas falsch konfiguriert war ?
Trotz aller Ungeschicklichkeiten meinserseits: Das SAE-Projekt kann man nur ausdrücklich loben, wenn man sich überlegt, wieviele PV-Anlagen damit besser/ effizienter genutzt werden könn(t)en!! Vor allem in diesen Zeiten, in denen Energie deutlich teurer geworden ist....

[camueller]

Die logfiles von der 2.0.4 im letzten Post sind nicht brauchbar im Hinblick auf die Frage, ob etwas falsch konfiguriert war ?

Dem Log-File zufolge hattest Du einen PWM-Schalter konfiguriert, aber dieser hat nie irgendwelche Schaltbefehle erhalten.
Andere (technische) Fehler sind im Log nicht enthalten.

[ShareForAll]

2.0.4._rolling-2022-07-02.log.zip
Ich habe nochmal einen Versuch unternommen, um mit der SAE-Version 2.0.4 den Schaltertyp "PWM" für den Devicetyp "Heizung" zu testen:
Anbei als *.zip das zugehörige "rolling-Log": Beobachtungen:

• Wenn das definierte Zeitfenster für das Device erreicht ist und genügend PV-Ertrag vorhanden, dann blinkt - wie erwartet - die Ampel gelb, ABER offenbar sendet der SHM2.0 keinen Einschaltbefehl, da der Tastgrad bei 0 bleibt (im Log finde ich kein Einschaltkommando)
• Bei manuellem Klick auf die Ampel, um das Device einzuschalten, führt dies dazu, dass die Ampel weiterhin gelb blinkt -> kein Einschaltbefehl wird geschickt
• der SAE Service läuft aber (sonst würde ich keine Ampel-Anzeige haben, richtig?); "systemctl status smartapplianceenabler.service" bringt auch eine "active (running)" Rückmeldung (sehe im Log keine Fehler, aber von der Loginterpretation verstehe ich auch so gut wie nichts...)
• Eventuell wichtig: im Sunnyportal wird für das Device kein Zeitfenster in Form eines farbigen Balkens angezeigt (auch nach mehreren Stunden Laufzeit der SAE 2.0.4 version). Kann es sein, dass solange im SunnyPortal kein Zeitfenster angezeigt wird, der SHM auch nie das Device einschalten wird? Bei der SAE-Version 1.6.20 wird nach kurzer Zeit dieses "Zeitfenster" im Portal angezeigt und auch dann auch geschaltet, wenn Zeitfenster und PV-Ertrag "passen".
  Hat jemand ein Device mit Schaltertyp "PWM" (bei 2.0.4) und Device-Typ "Heizung", wo der definierte Zeitbereich auch im SunnyPortal angezeigt wird?
  Danke für Hinweise & Tipps.

[camueller]

Vorraussetzung für einen Einschaltbefehtl ist, dass der SAE überhaupt Bedarf (also Timeframes) an den SHM meldet - siehe https://github.com/camueller/SmartApplianceEnabler/blob/master/doc/QA_DE.md . Tut er das überhaupt? Das wäre das erste, was zu prüfen ist. Was das Sunny Portal anzeigt ist für die Fehlersuche nicht relevant.

[ShareForAll]

Bin wieder am Testen des Schaltertyps "PWM" mit der 2.0.4:

• unter "http://:8080/semp" werden Timeframes für den aktuellen Tag + die Zeitfenster der beiden nachfolgenden tage angezeigt; trotzdem, obwohl ich z.B. innerhalb Zeitfenster bin und Min.Tastgrad 10% und Max.Tastgrad 100% definiere + Angabe der Min.Leistungsaufnahme = 300W und Max.Leistungsaufnahme = 3000W blinkt die SAE Ampel beharrlich gelb und lässt sich auch nicht manuell einschalten (in Ampel auf Fläche klicken, die dann grün werden sollte...); anbei das tagesaktuelle rolling-log:
  2.0.4_rolling-2022-07-10.log.zip

• wenn ich in der 2.0.4 auf Schaltertyp GPIO umstelle, kann ich den 3kW Verbraucher über die Ampel manuell einschalten - da scheint alles OK zu sein

• Muss bei den Einstellungen etwas beim MQTT Broker beachtet werden: bei mir steht hier (als default?): Host: 127.0.0.1, Port 1883 - ich habe unter https://github.com/camueller/SmartApplianceEnabler/blob/master/doc/Control_DE.md keine Info zum PWM Schaltertyp gefunden; man kann/ muss beim MQTT Broker einen Benutzernamen und Passwort angeben?

Danke für Geduld und Nachsicht :-)

[camueller]

Aktuell bin ich im Urlaub, aber danach werde ich den Pwm-Schalter und auch den Stufenschalter nochmal testen. Bis Ende Juli wird es eine neue Version 2.0.5 geben, wo diese Dinge hoffentlich gefixt sind.

[ShareForAll]

Bin wieder am Testen des Schaltertyps "PWM", nun mit der 2.0.5:

• obwohl ich z.B. innerhalb des PWM-Schalter Zeitfensters bin und Min.Tastgrad 5% und Max.Tastgrad 100% definiere + Angabe der Min.Leistungsaufnahme = 150W und Max.Leistungsaufnahme = 3000W blinkt die SAE Ampel beharrlich gelb und lässt sich auch nicht manuell einschalten (in Ampel auf Fläche klicken, die dann grün werden sollte...); anbei die rolling-logs von gestern (mit Wechsel von 1.6.20 nach 2.0.5) und heute:
  rolling-2022-07-23.zip
  rolling-2022-07-24.zip
  Obwohl also innerhalb des Zeitfensters ein Min.Tastgrad von 5% definiert wurde, habe ich im Log nur Einträge gefunden mit 0W gesetzter Leistung (während längerer Phase mit reichlich Sonnenschein...)
  2022-07-24 11:13:46,391 INFO [MQTT Call: F-150xxxxx-000000000001-00-PwmSwitch-2] d.a.s.c.PwmSwitch [PwmSwitch.java:167] F-15012020-000000000001-00: Setting power to 0W
  2022-07-24 11:13:46,391 INFO [MQTT Call: F-150xxxxx-000000000001-00-PwmSwitch-2] d.a.s.c.PwmSwitch [PwmSwitch.java:181] F-15012020-000000000001-00: Setting GPIO 23 duty cycle to 200
  [ duty cycle mit Wert "200" entspricht 5% von 4000 - das wäre wohl iO, da bei mir bei 100% Tastgrad wohl ein range von 4000 definiert wird:
  2022-07-23 19:11:20,195 DEBUG [http-nio-8080-exec-1] d.a.s.c.PwmSwitch [PwmSwitch.java:112] F-15012020-000000000001-00: using GPIO 23 with pwmFrequency=50 minDutyCycle=0.0 maxDutyCycle=100.0 range=4000 ]

• Muss bei den Einstellungen etwas beim MQTT Broker beachtet werden: bei mir steht hier (als default?): Host: 127.0.0.1, Port 1883 - ich habe unter https://github.com/camueller/SmartApplianceEnabler/blob/master/doc/Control_DE.md keine Info zum PWM Schaltertyp gefunden; man kann/ muss beim MQTT Broker einen Benutzernamen und Passwort angeben?

[camueller]

Am PWM-Schalter hat sich für 2.0.5 nichts geändert, nur den Stufenschalter habe ich gefixt.

Den PWM-Schlater hatte ich aber schon zuvor getestet - das geht ja auch nur mit dem Raspberry Pi. Du musst aber einen GPIO verwenden, der PWM-fähig ist. Ich habe für die Tests GPIO 17 verwendet, wobei ich die Tests mit einem Modellbau-Servo gemacht habe.

Zum Testen von PWM-Schalter und auch Stufenschalter solltest Du curl verwenden, um den Befehl genauso an den SAE zu schicken, wie es der SHM tut:

 curl -X POST -d '<EM2Device xmlns="http://www.sma.de/communication/schema/SEMP/v1"><DeviceControl><DeviceId>F-00000001-000000000001-00</DeviceId><On>true</On><RecommendedPowerConsumption>1000</RecommendedPowerConsumption></DeviceControl></EM2Device>' --header 'Content-Type: application/xml' http://raspberrypi:8080/semp

Die DeviceID, Leistung und URL musst Du natürlich anpassen ...

Solange der MQTT-Broker auf dem Raspberry Pi mit Port 1883 läuft, musst Du nichts im SAE konfigurieren - das sind ja die Standardwerte. Auch Username/Passwort sind normalerweise nicht notwendig.

[ShareForAll]

Test mit 2.0.5:

• das angepasste curl-Kommando funktioniert und wenn ich anschließend das Tageslogfile ("rolling...") mit grep "F-xxxxxxxx-000000000001-00" /tmp/rolling-2022-07-30.log | grep -i "Setting power" durchsuche, finde ich auch den entsprechenden Eintrag
• verwendet wird GPIO 18 ("BCM")
• unter http://raspi-URL:8080/semp gibt es drei Zeitrahmen im Abschnitt PlanningRequest (aktueller Tag/ Zeitrahmen + die beiden nachfolgenden Tage)
• "Herausforderung": Ich finde den Fehler nicht, da es kein automatisches Setzen der Leistung gibt... (trotz Sonnenschein...) nur mit Deinem curl-Kommando klappt es... nach dem Starten des 2.0.5.war-files (sudo systemctl restart smartapplianceenabler.service) und MQTT-Broker Restart läuft der SMA Service (check mit systemctl status smartapplianceenabler.service); die "Ampel" blinkt vielversprechend "gelb";
• die Suche mit grep "F-xxxxxxxx-000000000001-00" /tmp/rolling-2022-07-30.log | grep -i "error" ergibt nur Suchtreffer der Art "2022-07-30 14:38:56,305 DEBUG [http-nio-8080-exec-4] d.a.s.s.w.SempController [SempController.java:342] F-xxxxxxxx-000000000001-00: DeviceStatus{eMSignalsAccepted=true, status=Off, errorCode=null}" ....also das scheint nicht verdächtig zu sein...
• Hat noch jemand einen Tipp (außer "lass es einfach sein...")? Danke.
  rolling-2022-07-30.zip

[camueller]

Ich habe mal einen Ausschnitt aus Deinem Log extrahiert, der sich auf die Abfrage durch den SHM bezieht:

2022-07-30 14:33:55,168 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:89] Device info/status/planning requested.
2022-07-30 14:33:55,169 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:162] F-xxxxxxxx-000000000001-00: DeviceInfo{characteristics=Characteristics{maxPowerConsumption=3000, minPowerConsumption=null, minOnTime=840, maxOnTime=21800, minOffTime=870, maxOffTime=null}, capabilities=Capabilities{currentPowerMethod=Estimation, absoluteTimestamps=false, interruptionsAllowed=true, optionalEnergy=true}}
2022-07-30 14:33:55,189 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:333] F-xxxxxxxx-000000000001-00: Reporting device status from control
2022-07-30 14:33:55,190 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:342] F-xxxxxxxx-000000000001-00: DeviceStatus{eMSignalsAccepted=true, status=Off, errorCode=null}
2022-07-30 14:33:55,190 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:352] F-xxxxxxxx-000000000001-00: Reporting power info from device characteristics.
2022-07-30 14:33:55,190 WARN [Timer-0] d.a.s.c.MeterReportingSwitch [MeterReportingSwitch.java:170] F-xxxxxxxx-000000000006-00: Meter not set.
2022-07-30 14:33:55,191 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:362] F-xxxxxxxx-000000000001-00: PowerInfo{averagePower=0, minPower=null, maxPower=null, timestamp=0, averagingInterval=60}
2022-07-30 14:33:55,192 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:432] F-xxxxxxxx-000000000001-00: Timeframe created: 0s-5764s:0s/5764s
2022-07-30 14:33:55,193 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:384] F-xxxxxxxx-000000000001-00: Timeframe added to PlanningRequest: 0s-5764s:0s/5764s
2022-07-30 14:33:55,193 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:432] F-xxxxxxxx-000000000001-00: Timeframe created: 61864s-92164s:0s/24600s
2022-07-30 14:33:55,194 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:384] F-xxxxxxxx-000000000001-00: Timeframe added to PlanningRequest: 61864s-92164s:0s/24600s
2022-07-30 14:33:55,195 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:432] F-xxxxxxxx-000000000001-00: Timeframe created: 148264s-178564s:0s/24600s
2022-07-30 14:33:55,196 DEBUG [http-nio-8080-exec-10] d.a.s.s.w.SempController [SempController.java:384] F-xxxxxxxx-000000000001-00: Timeframe added to PlanningRequest: 148264s-178564s:0s/24600s

Was mir aufgefallen ist:

• für das Gerät ist keine Min. Leistungsaufnahme konfiguriert (muss aber angegeben werden, auch wenn von der Web-Oberfläche aktuell noch nicht erzwungen)
• minOnTime / maxOnTime / minOffTime / maxOffTime solltest Du estmal nicht setzen - das macht für den SHM alles kompilzierter. Wenn alles funktioniert, kannst Du solche Feinheiten konfigurieren
• Du hast keinen Zähler konifguriert, das solltest Du aber für Verbraucher mit variabler Leistungsaufnahme auf jeden Fall tun, damit der SAE die aktuelle Leistungsaufnahme an den SHM melden kann

Solange Du diese Punkte nicht behoben hast, solltest Du Dich nicht wundern, wenn es nicht funktioniert.

[ShareForAll]

Vielen Dank für die rasche Rückmeldung!

• Muss dann passend zur Min- Leistungsaufnahme auch ein entsprechender Min-Tastgrad angegeben werden? (ich habe mir das so vorgestellt, dass der SHM insbesondere bei "Mischwetterlage" (Wechsel von Sonne und Wolken..) zwischen 100% und 0% Tastgrad selbst dynamisch wählen kann/ soll... (max. Freiheitsgrad für Einstellung zwischen 0 und 100%)
• Zum Zähler: Oh, das war mir in der Tat nicht bewusst, dass man hier etwas angeben muss. Ich habe gehofft, es funktioniert so, wenn man keinen Zähler angibt: Der SAE setzt den Tastgrad und weiß auch wie lange welche Leistung eingestellt ist, so dass er die Leistungsaufnahme durch den Verbraucher einigermaßen "überschlagsmäßig berechnen" kann und diese "Schätzung" an den SHM übermittelt. Ich muss mir also noch einen Zähler kaufen? (In meinem Fall handelt es sich um einen Heizstab ohne irgendeine Zählereinrichtung...)
• Was mir noch aufgefallen ist: Wenn auch unter raspi:8080/semp die Zeitfenster angezeigt werden, dann ist es bei mir trotzdem so, dass auch nach längerer Wartezeit (> einige Stunden) das Zeitfenster für den nächsten Tag im SunnyPortal nicht angezeigt wird... bedeutet das, dass der SHM den Planning Request vom SAE nicht mibekommt?.... oder ist das Nicht-Anzeigen des Zeitfensters im Portal ein Nebeneffekt von den Punkten, die Du aufgezählt hast?
  Vielen Dank für die Hinweise!!

[ShareForAll]

Vielen Dank für die neue Testversion und die ganzen Infos!
Am 2023.02.20 hatte ich Deine "erste" Fix-Versison 2.2.1 im Test ("dutycycle (dc) shall be 0 when power set to 0" - so habe ich es genannt, falls richtig verstanden; Thema war, dass dc ungleich 0 war nach Parameteränderung außerhalb des Zeitfensters ) - Der Fix funktioniert auch bei mir. Beobachtung (allerdings) bei dieser Version: Kurzform: Die vom SAE gesetzten DutyCycle Werte sind "schön" dynamisch, allerdings sind immer wieder Werte auch außerhalb des Bereiches, der durch Deine Formel
dutyCycle = power/maxPower * (maxDutyCycle-minDutyCycle)/100 * range
definiert sein sollte;
Meine Vorgaben im SAE:
minPowerConsumption: 150
maxPowerConsumption: 3000
minDutyCycle: 20
maxDutyCycle 85

Die DutyCycle-"Grenzwerte" sollten nach der Formel lauten:
dutycycle (max) = 3000/3000 * (85-20)/100 * 5000 = 3250
dutycycle (min) = 150/3000 * (85-20)/100 * 5000 = 162,5
Also ich habe es so verstanden, dass der SAE dann nur dutycycle Werte setzen sollte, die irgendwo zwischen 162,5 und 3250 liegen.
Ich habe aber mit " grep "F-15012020-000000000001-00" /tmp/rolling-2023-02-20.log | grep -i "Setting GPIO 18 duty cycle to" " z.B. folgende Werte gefunden: 0 , 4250 , 4126 , 3509 (über den Tag hinweg, auch andere Werte größer 3250..) (Tageslogfile am Ende)

Am 2023.02.22 hatte ich Deine "zweite" Fix-Versison 2.2.1 im Test ("keep_current_power_when_SHM-powerrequest_is_missing" - so habe ich es verstanden). Die Methode, um das zu überprüfen habe ich noch nicht verstanden, aber auch hier die Beobachtung, dass immer wieder 'mal DutyCycle vom SAE gesetzt werden, die eigentlich außerhalb des durch die Formel definierten Wertebereiches liegen:
Meine Vorgaben im SAE: (bereits am 2023.02.21 spät abends gesetzt, also im Tagelogfile vom 21.02.'23 enthalten...)
minPowerConsumption: 600
maxPowerConsumption: 3000
minDutyCycle: 8
maxDutyCycle 85
Die DutyCycle-"Grenzwerte" sollten nach der Formel lauten:
dutycycle (max) = 3850
dutycycle (min) = 770
Ich habe aber mit " grep "F-15012020-000000000001-00" /tmp/rolling-2023-02-22.log | grep -i "Setting GPIO 18 duty cycle to" " z.B. folgende Werte gefunden: 0 , 4250 , 3911, 4126, 4003 (über den Tag hinweg, auch andere Werte größer 3850..) (Tageslogfile vom 21.02. + 22.02.'23 am Ende); Der größte vorkommende Wert ist 4250, was 85% von 5000 entspricht, aber nach der Formel sollte doch maximal 3850 vom SAE gesetzt werden (am PWM PIN GPIO18, in meinem Fall), oder irre ich mich schon wieder? [Aber das ist eher etwas "akademisch", da es nach wie vor im Betrieb tagsüber (im definierten Zeitfenster) gut funktioniert... ich wollte nur überprüfen, ob ich Deine Ausführungen verstanden habe...]
rolling-2023-02-20.zip
rolling-2023-02-21.zip
rolling-2023-02-22.zip

[camueller]

Also ich habe es so verstanden, dass der SAE dann nur dutycycle Werte setzen sollte, die irgendwo zwischen 162,5 und 3250 liegen.

Deine Erwartungshaltung ist korrekt. Es gab einen Fehler in der Implementierung der verwendeten Formel. Den habe ich gerade gefixt.

Hier ist eine Test-Version mit dem Fix: https://drive.google.com/file/d/1jtMMhsPoQ4-h_BVChcjViRwMOSmLgSpY/view?usp=share_link

[camueller]

@ShareForAll Hattest Du schon Gelegenheit, die Test-Version auszuprobieren?

[ShareForAll]

Vielen Dank für die Fix_Version (ich nenne sie "corrected_duty_cycle_calculation") und Deine Nachfrage!!. [da die Fix-Testversionen alle ebenfalls 2.2.1 als (sichtbare) Versionsnummer haben, muss ich sie immer gleich in der eigenen Ablage umbenennen, sonst komme ich durcheinander... , hab' kein "Profi-Versionsmanagement"-System.. :-) ]
Also was das Einhalten der "Formel-Grenzwerte" für den vom SAE gesetzten DutyCycle anbelangt sieht es sehr gut aus: Bsp:
Am 27.02.'23, ca. 21:08h im SAE definiert:
minPowerConsumption: 550
maxPowerConsumption: 3000
minDutyCycle: 14
maxDutyCycle: 91
Grenzwerte nach der Formel oben:

1. DC_(max): 3850 (=77% vom range 5000 und damit sollte das beim Verbraucher bedeuten: 77% von P_max (3000W) = 2310W, die in der Praxis als gemessenes Maximum (durch S0-Zähler) auftauchen sollten
2. DC_(min): 705,83 (=14% vom range 5000 und damit sollte das beim Verbraucher bedeuten: 14% von P_max (3000W) = 423,5W, die in der Praxis als gemessenes Minimum auftauchen sollten (wenn status=on)

Log-Auswertung vom 28.02.'23: (log am Ende des Posts attached):
a) "received control request"-Werte bewegen sich zwischen 550W und 3000W --OK!! Super!
b) "setting power"-Werte bewegen sich zwischen 550W und 3000W --OK!! Super!
c) grep nach "d.a.s.m.S0ElectricityMeter" + "power": Werte beim S0-Zähler: zwischen 435W und 2441W, also jeweils ziemlich nahe an den Grenzwerten. Man muss die Formel kennen, damit man versteht, dass z.B. maxDC von 91% eben später im Betrieb nicht 91% von P_max bedeuten, sondern DC-range abhängig in diesem Bsp 77% bedeutet (dass bei mir das Praxis-Maximum etwas über dem Theorie-Maximum liegt, liegt vermutlich am S0-Zähler bzw. an meiner Elektronik, die den SAE-DutyCycle auf das ansteuernde Halbleiterrelais schaltet....)

Allerdings habe ich am 04.03. innerhalb des Zeitfensters vom "Zeitplan" (gegen 10:16h) andere SAE-Werte definiert (zum Testen):
minPowerConsumption: 550
maxPowerConsumption: 3000
minDutyCycle: 40
maxDutyCycle: 80
Log-Interpretation vom 04.03.'23: (log am Ende des Posts attached) (soweit ich das richtig verstehe)
Die Grenzwerte werden (aus meiner Sicht) gut eingehalten (also "setting ... duty cycle to" zwischen den Formel-Grenzwerten),
aber der grep mit
grep "F-15012020-000000000001-00" /tmp/rolling-2023-03-04.log | grep -i "status=on" liefert nur Treffer vor der Änderung, soll heißen, dass der status nach 10:16h immer lautet: "status=off". Also irgendwie werden DC-Werte gesetzt, aber das device ist ab 10:16h dauerhaft deaktiviert und
grep "F-15012020-000000000001-00" /tmp/rolling-2023-03-04.log | grep -i "d.a.s.m.PulseEnergyMeter" liefert ab der Parameteränderung im SAE gegen 10:16h nur noch energy=0
Siehe zwei screenshot-Beispiele von der semp-Protokoll Ansicht im Browser:

Aber ansonsten ist das PWM-Feature wirklich klasse!
Viele Grüße!
rolling-2023-02-28.zip
rolling-2023-03-04.zip

[camueller]

Auffällig an Deinem Log ist, dass nach dem Ändern der Konfiguration nicht einie einzige MQTT-Nachricht gesendet/empfangen wurde (zumindest sind keine Einträge im Log). So etwas kann eigentlich nicht sein: Wenn der MQTT-Server nicht erreichbar wäre, müste das Log voll von Fehlern sein.

Ich habe das gerade mal hier nachgestellt: Konfiguration geändert (was ja eine Neu-Initialisierung bedeutet) und danach werden ganz normal die MQTT-Nachrichten verschickt und empfangen.

[ShareForAll]

1. Das oben von Dir als MQTT-Server Problem identifizierte Thema konnte ich ebenfalls nicht mehr reproduzieren...

2. Bin heute (2023.03.26) auf die SAE-Version 2.2.2 umgestiegen.
   Ich habe 'mal nach "mqtt call" im Tageslog gefiltert, kurz nach dem Versionswechsel:
   Ich kann das freilich nicht beurteilen, aber die meisten Zeilen wirken wie gedoppelt: Inhaltlich Ähnliches/ Gleiches erscheint nur wenige Millisekunden später nochmal....
   Es geht bei mir nur um einen Verbraucher mit PWM-Schalter, aber es gibt z.B. "EnergyRequest-0" und "EnergyRequest-3" Unterscheidung... Sieht das soweit für Dich i.O. aus?

2023-03-26 14:59:20,178 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:197] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 0
2023-03-26 14:59:21,524 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-0] d.a.s.m.S0ElectricityMeter [S0ElectricityMeter.java:109] F-15012020-000000000001-00: Stop energy meter ...
2023-03-26 14:59:21,525 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-0] d.a.s.m.PulseEnergyMeter [PulseEnergyMeter.java:63] F-15012020-000000000001-00: Stop energy counter: pulses=0
2023-03-26 15:01:48,445 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-1] d.a.s.c.PwmSwitch [PwmSwitch.java:197] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 0
2023-03-26 15:01:48,451 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-1] d.a.s.c.PwmSwitch [PwmSwitch.java:197] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 0
2023-03-26 15:01:49,555 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-0] d.a.s.m.S0ElectricityMeter [S0ElectricityMeter.java:109] F-15012020-000000000001-00: Stop energy meter ...
2023-03-26 15:01:49,557 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-3] d.a.s.m.S0ElectricityMeter [S0ElectricityMeter.java:109] F-15012020-000000000001-00: Stop energy meter ...
2023-03-26 15:01:49,557 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-0] d.a.s.m.PulseEnergyMeter [PulseEnergyMeter.java:63] F-15012020-000000000001-00: Stop energy counter: pulses=0
2023-03-26 15:01:49,558 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-3] d.a.s.m.PulseEnergyMeter [PulseEnergyMeter.java:63] F-15012020-000000000001-00: Stop energy counter: pulses=0

Anbei noch das Tageslog nach Umstieg auf SAE 2.2.2:
rolling-2023-03-26.zip
Danke.

[camueller]

Ich kann das freilich nicht beurteilen, aber die meisten Zeilen wirken wie gedoppelt: Inhaltlich Ähnliches/ Gleiches erscheint nur wenige Millisekunden später nochmal....

Komisch finde ich vor allem, dass auch der PWM-Schalter 2 mal aufgerufen wird:

2023-03-26 15:01:48,445 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-1] d.a.s.c.PwmSwitch [PwmSwitch.java:197] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 0
2023-03-26 15:01:48,451 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-1] d.a.s.c.PwmSwitch [PwmSwitch.java:197] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 0

Kannst Du Deinen MQTT-Broker mal restarten? Falls das Problem immer noch auftritt, mach mir bitte nochmal ein Log verfügbar.

[ShareForAll]

Danke fürs Draufschauen!
Habe zwei Mal (um 16:43h und 1650h) den MQTT-Broker über die Webmin "Bootup and Shutdown"-Seite neu gestartet und wieder nach "mqtt call" gefiltert, ab 16:50h folgende Meldungen (auch bereits außerhalb des definierten täglichen Aktivitätszeitfensters: 08:45h - 16:30h). Da wimmelt es geradezu nur so von/ vor MQTT Meldungen, obwohl es nur um einen Verbraucher geht.... Wow! Mehrere EnergyRequest-Nummern (2, 1, 5 , 0, 4) und eine Appliance Nummer... , aber PWMSwitch kommt nicht mehr doppelt aufeinanderfolgend vor (in dem Ausschnitt hier sogar gar nicht...). Unten nochmal das heutige Tageslogfile (aktualisiert), falls es eventuell interessante Informationen enthält (für jemanden, der das interpretieren kann...).

2023-03-26 16:50:45,252 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-2] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Meter
2023-03-26 16:50:45,257 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-2] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Control
2023-03-26 16:50:45,261 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-2] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/EVChargerStateChanged
2023-03-26 16:50:45,263 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Meter
2023-03-26 16:50:45,270 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Control
2023-03-26 16:50:45,275 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/EVChargerStateChanged
2023-03-26 16:50:45,347 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-5] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Meter
2023-03-26 16:50:45,358 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-5] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Control
2023-03-26 16:50:45,372 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-5] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/EVChargerStateChanged
2023-03-26 16:50:45,383 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-0] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Meter
2023-03-26 16:50:45,364 DEBUG [MQTT Call: F-15012020-000000000001-00-PwmSwitch-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-PwmSwitch: Messages subscribed: topic=sae/F-15012020-000000000001-00/Control/set
2023-03-26 16:50:45,398 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-0] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Control
2023-03-26 16:50:45,404 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-0] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/EVChargerStateChanged
2023-03-26 16:50:45,429 DEBUG [MQTT Call: F-15012020-000000000001-00-Appliance-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-Appliance: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/WrappedControlSwitchOnDetected
2023-03-26 16:50:45,439 DEBUG [MQTT Call: F-15012020-000000000001-00-Appliance-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-Appliance: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/WrappedControlSwitchOffDetected
2023-03-26 16:50:45,444 DEBUG [MQTT Call: F-15012020-000000000001-00-Appliance-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-Appliance: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/EnableRuntimeRequest
2023-03-26 16:50:45,451 DEBUG [MQTT Call: F-15012020-000000000001-00-Appliance-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-Appliance: Messages subscribed: topic=sae/F-15012020-000000000001-00/Meter
2023-03-26 16:50:45,458 DEBUG [MQTT Call: F-15012020-000000000001-00-Appliance-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-Appliance: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/EVChargerStateChanged
2023-03-26 16:50:45,523 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-4] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Meter
2023-03-26 16:50:45,526 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-4] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Control
2023-03-26 16:50:45,462 DEBUG [MQTT Call: F-15012020-000000000001-00-Appliance-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-Appliance: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/DisableRuntimeRequest
2023-03-26 16:50:45,540 DEBUG [MQTT Call: F-15012020-000000000001-00-Appliance-1] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-Appliance: Messages subscribed: topic=sae/F-15012020-000000000001-00/WrappedControl
2023-03-26 16:50:45,535 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-4] d.a.s.m.MqttClient [MqttClient.java:307] F-15012020-000000000001-00-MQTT-EnergyRequest: Messages subscribed: topic=sae/F-15012020-000000000001-00/Event/EVChargerStateChanged

rolling-2023-03-26.zip

[andi5783]

Du könntest mal den MQTT Broker stoppen und die dort ggf. vorhandenen Daten löschen. Vielleicht sind dort noch MQTT Nachrichten unterwegs die mit retain markiert sind

[camueller]

Ich habe leider vergessen zu schreiben, dass Du nach dem Neustart des MQTT-Broker auch den SAE neu starten solltest!

Ansonsten passiert in dem Log nach 16:50 nicht viel ...

[ShareForAll]

1. Wechsel von 2.3.0 auf 2.3.1 am 12.11.2023; Alles scheinbar i.O.

2. Am 13.11.'23 habe ich festgestellt, dass anscheinend ab Beginn des konfigurierten Zeitfensters für den PWM-Schaltertyp das Einschaltkommando erfolgt ist:
   Suche im unten angehängten Tageslogfile vom 13.11.2023 nach
   "grep "F-15012020-000000000001-00" /tmp/rolling-2023-11-13.log | grep -i "c.PwmSwitch""
   liefert mit Zeilen davor...:

2023-11-13 08:44:12,411 WARN [Timer-0] d.a.s.c.MeterReportingSwitch [MeterReportingSwitch.java:179] F-15012020-000000000007-00: No meter values received (yet).
2023-11-13 08:44:12,475 DEBUG [http-nio-8080-exec-2] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2023-11-13 08:44:12,507 WARN [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:221] F-15012020-000000000001-00: Forcing queue update with ignored timeframe interval start time
2023-11-13 08:44:12,508 DEBUG [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:224] F-15012020-000000000001-00: Current Queue:
2023-11-13 08:44:12,509 DEBUG [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-15012020-000000000001-00: QUEUED/2023-11-13T08:45:00/2023-11-13T16:00:00::ENABLED/_Wh/16000Wh
2023-11-13 08:44:12,510 DEBUG [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-15012020-000000000001-00: QUEUED/2023-11-14T08:45:00/2023-11-14T16:00:00::ENABLED/_Wh/16000Wh
2023-11-13 08:44:12,512 DEBUG [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:403] F-15012020-000000000001-00: Activate timeframe interval: QUEUED/2023-11-13T08:45:00/2023-11-13T16:00:00::ENABLED/_Wh/16000Wh
2023-11-13 08:44:12,515 DEBUG [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:295] F-15012020-000000000001-00: Updated queue:
2023-11-13 08:44:12,516 DEBUG [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-15012020-000000000001-00: ACTIVE/2023-11-13T08:45:00/2023-11-13T16:00:00::ENABLED/_Wh/16000Wh
2023-11-13 08:44:12,518 DEBUG [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-15012020-000000000001-00: QUEUED/2023-11-14T08:45:00/2023-11-14T16:00:00::ENABLED/_Wh/16000Wh
2023-11-13 08:44:12,518 DEBUG [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:301] F-15012020-000000000001-00: Notifying TimeframeIntervalChangedListener Appliance F-15012020-000000000001-00
2023-11-13 08:44:12,521 DEBUG [http-nio-8080-exec-2] d.a.s.m.S0ElectricityMeter [S0ElectricityMeter.java:115] F-15012020-000000000001-00: Reset energy meter ...
2023-11-13 08:44:12,523 DEBUG [http-nio-8080-exec-2] d.a.s.m.PulseEnergyMeter [PulseEnergyMeter.java:68] F-15012020-000000000001-00: Reset energy counter
2023-11-13 08:44:12,524 DEBUG [http-nio-8080-exec-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:301] F-15012020-000000000001-00: Notifying TimeframeIntervalChangedListener EnergyRequest ENABLED/_Wh/16000Wh
2023-11-13 08:44:12,528 DEBUG [http-nio-8080-exec-2] d.a.s.a.Appliance [Appliance.java:441] F-15012020-000000000001-00: Setting appliance state to ON
2023-11-13 08:44:12,533 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 3000W
2023-11-13 08:44:12,535 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 4350
2023-11-13 08:44:12,546 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-0] d.a.s.m.S0ElectricityMeter [S0ElectricityMeter.java:103] F-15012020-000000000001-00: Start energy meter ...
2023-11-13 08:44:12,547 DEBUG [MQTT Call: F-15012020-000000000001-00-EnergyRequest-0] d.a.s.m.PulseEnergyMeter [PulseEnergyMeter.java:58] F-15012020-000000000001-00: Start energy counter
2023-11-13 08:44:12,745 DEBUG [nioEventLoopGroup-2-2] d.a.s.m.S0ElectricityMeter [S0ElectricityMeter.java:200] F-15012020-000000000001-00: S0 impulse detected on GPIO 17
2023-11-13 08:44:12,749 DEBUG [nioEventLoopGroup-2-2] d.a.s.m.PulseEnergyMeter [PulseEnergyMeter.java:49] F-15012020-000000000001-00: energy=5.0E-4kWh started=true pulses=1 pulses/kWh=2000

Es kann keine "gültige Anforderung" um 08:44h aufgrund Sonnenschein gewesen sein (trübes Regenwetter den ganzen Tag).
Ist per Default bei der 2.3.1 etwas aktiviert, so dass (vermutlich mit meiner Fehlbedienung) das konfigurierte Zeitfenster wie eine "Schaltuhr" sofort den PWM-Schalter umlegt...?
Danke für Tipps, was ich vllt. falsch eingestellt haben könnte, aber ich habe eigentlich nur die neue Version aktiviert und die Konfigdateien nicht angefasst/ verändert...

Anbei noch die Tageslogfiles vom SAE 2.3.1 am 12+13.11.2023
rolling-2023-11-12.zip
rolling-2023-11-13.zip
Bin danach wieder auf 2.3.0, da wirkt alles wieder "vertraut" und kein Einschalten trotz trübem Wetter....
Ich komme momentan nicht darauf, was ich beim Aktivieren des neuen *.war files angerichtet haben könnte...

VG

[camueller]

Der Fehler ist bei Beheben eines anderen Fehlers entstanden, allerdings muss ich mir noch eine Lösung überlegen :-)

[camueller]

Ich habe das gerade mal nachgestellt: Der SAE 2.3.1 verhält sich meiner Meinung nach auch beim PWM-Schalter korrekt.

Kann es sein, dass Du im Zeitplan als min. Energie nichts eingetragen hast? Da muss 0 stehen.

[ShareForAll]

Ja, das war es. Die "0" bei Min.Energie stand nicht drin, obwohl ich sie beim Wechseln von 2.3.0 auf 2.3.1 nicht rausgenommen habe. Die Konfig wird beim Verwenden einer aktuelleren *.war Version eigentlich genau übernommen, oder? Aber egal, vielen Dank für den Hinweis und die Lösung!! Ich hätte noch eine(n) Vorschlag/ Anregung: Den Fall, dass man das Min.Energie Feld leer lässt und was das dann bedeutet:
"Zeitschaltuhr bis zum Erreichen von Max.Energie oder Zeitfensterende", richtig? z.B.:

[camueller]

Ja, die Konfig-Dateien werden nur bei strukturellen Änderungen "migriert", was hier aber nicht der Fall war.
Allerdings gab es in der 2.3.1 einen Bugfix, der dazu führt, dass die Min. Energie jetzt wirklich so interpretiert wird, wie in der Dokumentation angegeben. Deshalb kam es bei Dir zu dem Fehler, obwohl die Konfig-Dateien unverändert waren.

[ShareForAll]

Ich verwende den SAE 2.3.1 und im Wesentlichen funktioniert der PWM-Schalter bei mir:
Min-Leistung (500W), Max-Leistung (3000W), Min-Tastgrad (7%), Max-Tastgrad (94%) werden jeweils gemäß der Berechnungsformel angewendet [DutyCycle = P/P_max * (DC_max - DC_min)/100 * 5000]

Beobachtungen:

1. Bei meinem PWM-Schalter sieht man im logfile allerdings, dass mit ganz seltenen Ausnahmen eigentlich immer nur die beiden Maximalwerte der Duty Cycle Spanne gesetzt werden und das zeitlich nur ein oder zwei Minuten auseinander:
   Max-DC für 1-2 Minuten, dann
   Min-DC für 1-2 Minuten, dann
   Max-DC für 1-2 Minuten, dann
   ...usw.
   Dabei gab es (heute am 16.05.'24) länger gleichbleibend sonnige Phasen, so dass das - glaube ich - keine Reaktion auf Wechsel von Wolken und Sonne darstellt....
   Ich habe bei den Eigenschaften noch definiert:
   Unterbrechungen erlaubt:
   Min-Einschaltdauer: 360s (wenn eingeschaltet, dann mind. drei Minuten)
   Min-Ausschaltdauer: 120s (wenn aus, dann bitte zwei Minuten aus bleiben...)

Max-Einschaltdauer und Max-Ausschaltdauer habe ich jeweils "leer" gelassen. (jetzt wo ich das schreibe, ahne ich schon, dass man wohl besser alle Felder definieren sollte?) Wenn ich aber z.B. für Max-Ausschaltdauer einen Wert (z.B. 3600s) setze, dann bedeutet das doch, dass nach dieser Zeit der PWM-Schalter auf alle Fälle wieder eingeschaltet wird, selbst z.B. bei Regen, korrekt? Oder soll man einfach Max-Zeiten setzen, die länger als z.B. das tägliche Zeitfenster sind, dann muss der SAE den PWM-Schalter nicht zwangsweise trotz bewölktem Wetter einschalten?

Ausschnitt vom heutigen Log:

2024-05-16 10:53:14,208 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 3000W
2024-05-16 10:53:14,209 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 4350
2024-05-16 10:54:13,441 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 500W
2024-05-16 10:54:13,442 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 725
2024-05-16 10:55:15,522 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 3000W
2024-05-16 10:55:15,523 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 4350
2024-05-16 10:59:13,300 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 500W
2024-05-16 10:59:13,301 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 725
2024-05-16 11:00:15,458 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 3000W
2024-05-16 11:00:15,459 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 4350
2024-05-16 11:03:15,422 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 0
2024-05-16 11:43:19,432 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 3000W
2024-05-16 11:43:19,434 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 4350
2024-05-16 11:45:15,129 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 500W
2024-05-16 11:45:15,130 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 725
2024-05-16 11:48:15,210 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 3000W
2024-05-16 11:48:15,211 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 4350
2024-05-16 11:50:13,586 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 0
2024-05-16 11:54:21,263 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 3000W
2024-05-16 11:54:21,264 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 4350
2024-05-16 11:56:13,991 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 500W
2024-05-16 11:56:13,993 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 725
2024-05-16 12:01:13,925 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 0
2024-05-16 12:33:19,552 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 3000W
2024-05-16 12:33:19,552 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 4350
2024-05-16 12:34:14,028 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:187] F-15012020-000000000001-00: Setting power to 500W
2024-05-16 12:34:14,029 INFO [MQTT Call: F-15012020-000000000001-00-PwmSwitch-0] d.a.s.c.PwmSwitch [PwmSwitch.java:204] F-15012020-000000000001-00: Setting GPIO 18 duty cycle to 725

Falls es nicht schon hier oder in einem anderen Beitrag beantwortet wurde:
Liegt es an meinen Einstellungen, dass der SAE (fast) immer nur die maximalen duty cycle Werte setzt? Ich hätte angenommen, dass auch Werte zwischen den Maximalwerten gesetzt werden...

2. Obwohl Min-Einschaltdauer auf 360s festgelegt wurde, sieht man im Log um 11:48h ein Einschaltvorgang und schon ca. 120s später ein Ausschalten ("duty cycle to 0").

Anbei noch das Tageslog vom 16.05.'24.
Danke fürs Durchlesen.
rolling-2024-05-16.zip

Viele Grüße!

[camueller]

Du beschränkst Deine Analyse auf den Schalter, aber entscheidend ist doch, weche Schalt-Befehle der Sunny Home Manager sendet:

2024-05-16 10:53:14,199 DEBUG [http-nio-8080-exec-2] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 10:54:13,435 DEBUG [http-nio-8080-exec-5] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 10:55:15,515 DEBUG [http-nio-8080-exec-7] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 10:59:13,294 DEBUG [http-nio-8080-exec-7] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 11:00:15,451 DEBUG [http-nio-8080-exec-5] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 11:43:19,425 DEBUG [http-nio-8080-exec-9] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 11:45:15,122 DEBUG [http-nio-8080-exec-4] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 11:48:15,202 DEBUG [http-nio-8080-exec-5] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 11:54:21,256 DEBUG [http-nio-8080-exec-9] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 11:56:13,985 DEBUG [http-nio-8080-exec-2] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 12:33:19,545 DEBUG [http-nio-8080-exec-1] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 12:34:14,020 DEBUG [http-nio-8080-exec-3] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 12:35:17,877 DEBUG [http-nio-8080-exec-8] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 12:37:13,288 DEBUG [http-nio-8080-exec-3] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 12:38:13,471 DEBUG [http-nio-8080-exec-8] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 12:39:15,724 DEBUG [http-nio-8080-exec-2] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 13:37:13,144 DEBUG [http-nio-8080-exec-2] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 13:40:15,224 DEBUG [http-nio-8080-exec-1] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 14:53:13,669 DEBUG [http-nio-8080-exec-1] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 14:54:13,434 DEBUG [http-nio-8080-exec-3] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 15:05:12,919 DEBUG [http-nio-8080-exec-1] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 15:07:13,221 DEBUG [http-nio-8080-exec-7] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W
2024-05-16 15:08:10,149 DEBUG [http-nio-8080-exec-1] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=3000W
2024-05-16 15:10:13,250 DEBUG [http-nio-8080-exec-7] d.a.s.s.w.SempController [SempController.java:301] F-15012020-000000000001-00: Received control request: on=true, recommendedPowerConsumption=500W

Der SAE setzt also die Schalt-Befehle korrekt um. Aber warum schickt der Sunny Home Manager diese Befehle? Du bist ja beim Schreiben schon selbst darauf gekommen, aber auch das lässt sich im Log prüfen:

2024-05-16 10:52:55,567 DEBUG [http-nio-8080-exec-7] d.a.s.s.w.SempController [SempController.java:163] F-15012020-000000000001-00: DeviceInfo{characteristics=Characteristics{maxPowerConsumption=3000, minPowerConsumption=500, minOnTime=360, maxOnTime=null, minOffTime=120, maxOffTime=null}, capabilities=Capabilities{currentPowerMethod=Measurement, absoluteTimestamps=false, interruptionsAllowed=true, optionalEnergy=true}}

Du hast eine Mindesteinschaltzeit von 5 Minuten (minOnTime=360) und eine Mindestausschaltzeit von 2 Minuten(minOffTime=120) gesetzt. Ich finde die Wert tendentiell unkritisch, aber sie erhöhen die Komplexität der Planung für den Sunny Home Manager und eigentlich bringen sie Dir nicht wirklich etwas. Aus beiden Gründen würde ich diese Werte löschen. Alle anderen Werte sehen gut aus.

Ich selbst nutze PWM-Schalter und Stufenschalter nicht, aber beide werden vom SAE dem Sunny Home Manager als Verbraucher mit variabler Leistungsaufnahme präsentiert genauso wie eine Wallbox. Letztere nutze ich intensiv zum Überschussladen und da funktioniert Leistungsvorgabe durch den Sunny Home Manager sehr gut. Allerdings gibt es bei mir im Haus keinen Akku, was die Sache für den Sunny Home Manager nochmal einfacher macht.