Bedarf-Signalisierung auf MQTT umstellen

[camueller]

Bei der Anlaufstromerkennung sind einige Mechanismen implizit. Vermutlich ist es sinnvoll, explizite Mechanismen bereitzustellen, die dann auch der Anlaufstromerkennung genutzt werden können.

Konkret müsste man dazu

1. Zeitpläne als "on demand only" markieren können, d.h. sie werden nur an den SHM übermittelt, wenn ein Bedarf signalisiert wurde.
2. Bedarf-Signalisierung via MQTT, wobei dieser sich auf das nächste Zeitfenster oder alle Zeitfenster beziehen kann.

[camueller]

@Tombra1889 Feature ist implementiert.

Eine Testversion kannst Du hier herunterladen: https://drive.google.com/file/d/1ja6u8jUABVc_AlDSPfLw81cqx1PVGJqc/view?usp=share_link

Eine Dokumentation der MQTT-Nachrichten habe ich begonnen. Die für Dich relevanten Nachrichten sind bereits dokumentiert: EnableRuntimeRequest und DisableRuntimeRequest.

Lass mich wissen, ob das für Dich so funktioniert.

[Tombra1889]

Hey, vielen Dank! Die Installation habe ich vorgenommen und im Anschluss die "Anlaufstromerkennung" herausgenommen.

So ganz funktioniert es allerdings noch nicht. Ich habe es jetzt so verstanden, dass ich das Zeitfenster entsprechend aktivieren kann, wenn ich die mqtt-Befehle sende:

z. B. {"time":"2022-12-28T21:20:39.74500","type":"MqttMessage"} an EnableRuntimeRequest

Die Ampeln bleiben aber leider schwarz.

{ "entries": [ { "enabled": false, "end": "2022-12-29T18:00:00", "max": 28800, "min": 0, "start": "2022-12-29T08:00:00", "state": "QUEUED", "type": "RuntimeRequest" }, { "enabled": false, "end": "2022-12-30T18:00:00", "max": 28800, "min": 0, "start": "2022-12-30T08:00:00", "state": "QUEUED", "type": "RuntimeRequest" } ], "time": "2022-12-28T21:28:29.364866", "type": "TimeframeIntervalQueueMessage" }

In den Einstellungen habe ich "externe Aktivierung" im Zeitplan aktiviert.

[camueller]

Die Ampeln sind bei Dir schwarz, weil das Zeitfenster nicht ACTIVE ist, d.h. Du befindest Dich ausserhalb des Zeitfensters.
Mit obigem MQTT-Request steuerst Du nur die Anforderungsstatus (ENABLED/DISABLED im Log), die zeitliche Komponente muss aber weiterhin erfüllt sein.

Ich habe das soeben nochmals getestet:

• Anforderung im Zeitplan auf "externe Aktivierung" gesetzt (Anlaufstromerkennung darf nicht gesetzt sein!)

• Queue sieht so aus:

2022-12-29 06:55:17,794 DEBUG [Timer-0] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:224] F-00000001-000000000008-00: Current Queue:
2022-12-29 06:55:17,795 DEBUG [Timer-0] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-00000001-000000000008-00: ACTIVE/2022-12-29T04:00:00/2022-12-29T20:00:00::DISABLED/0s/300s
2022-12-29 06:55:17,795 DEBUG [Timer-0] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-00000001-000000000008-00: QUEUED/2022-12-30T04:00:00/2022-12-30T20:00:00::DISABLED/0s/300s
2022-12-29 06:55:17,795 DEBUG [Timer-0] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-00000001-000000000008-00: QUEUED/2022-12-31T04:00:00/2022-12-31T20:00:00::DISABLED/0s/300s

• MQTT-Message
  Topic: sae/F-00000001-000000000008-00/Event/EnableRuntimeRequest
  Payload: {"time":"2022-12-28T05:38:06.513324","type":"MqttMessage"}

• Einträge im Log

2022-12-29 06:55:37,625 TRACE [MQTT Call: F-00000001-000000000008-00-Appliance-2] d.a.s.m.MqttClient [MqttClient.java:289] F-00000001-000000000008-00-MQTT-Appliance: Message received: topic=sae/F-00000001-000000000008-00/Event/EnableRuntimeRequest payload={"time":"2022-12-28T05:38:06.513324","type":"MqttMessage"}
2022-12-29 06:55:37,625 DEBUG [MQTT Call: F-00000001-000000000008-00-Appliance-2] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:68] F-00000001-000000000008-00 Handling event EnableRuntimeRequest

• Queue sieht so aus:

2022-12-29 06:55:47,794 DEBUG [Timer-0] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:224] F-00000001-000000000008-00: Current Queue:
2022-12-29 06:55:47,795 DEBUG [Timer-0] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-00000001-000000000008-00: ACTIVE/2022-12-29T04:00:00/2022-12-29T20:00:00::ENABLED/0s/300s
2022-12-29 06:55:47,795 DEBUG [Timer-0] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-00000001-000000000008-00: QUEUED/2022-12-30T04:00:00/2022-12-30T20:00:00::DISABLED/0s/300s
2022-12-29 06:55:47,796 DEBUG [Timer-0] d.a.s.s.TimeframeIntervalHandler [TimeframeIntervalHandler.java:316] F-00000001-000000000008-00: QUEUED/2022-12-31T04:00:00/2022-12-31T20:00:00::DISABLED/0s/300s

• Ampel ist gelb

[Tombra1889]

Hey, danke nochmal für deine Rückmeldung.

Ich habe es gerade noch einmal ausprobiert, wenn man sich innerhalb des Zeitfensters befindet, funktioniert es. Gestern habe ich mich in der Tat außerhalb des Zeitfensters befunden, dort war dann aber das vorherige gewohnte Verhalten so, dass die Ampel auf rot war und auf die Aktivierung des Zeitfensters gewartet hat.

Aber mit dem aktuellen Verhalten kann ich auch super leben. Vielen DANK!

[camueller]

Die Version, die ich gestern für Dich gebaut hatte, aktiviert tatsächlich nur das aktive Zeitfenster.
Als ich gestern die Dokumentation der MQTT-Nachrichten erweitert habe, fiel mir auf, dass es eigentlich das nächste Zeitfenster sein muss, was nicht unbedingt schon aktiv sein muss. Also habe ich das im Code entsprechend geändert.

Brauchst Du davon auch eine Testversion oder kann das bis zum nächsten Release warten?

[Tombra1889]

Ahh ok, vielen Dank. Kann gerne bis zum nächsten Release warten. Ich habe es aktuell so eingestellt, dass der Befehl alle paar Minuten kommt, somit aktiviert wird, wenn ich in das nächste Zeitfenster laufe!

[camueller]

Kommt mit SAE 2.2.0.