Effizientester Weg für REST-Nachrichten alle 5 Sekunden?

[Prof. Dr. Peter Henning]

Meine neue WallBox verlangt zur (internen) Berechnung, wieviel Watt sie laden darf, alle 5 Sekunden einen Aufruf

Code Auswählen Erweitern

http://192.168.0.211/api/set?ids={"pGrid":1280.,"pPv":140.,"pAkku":0.}wobei die 3 Zahlenwerte natürlich Readings von FHEM-Devices sind.

Natürlich werde ich versuchen, das auch zu messen. Aber Ich würde gerne vorher mal Eure Orakelsprüche hören, wie das am effizientesten zu realisieren ist:

• In dem für die WallBox existierenden HTTPMOD-Device einen neuen Set-Befehl zu definieren, der zyklisch ausgeführt wird. Ungünstig, weil die Response - die eigentlich nur ein "true" ist - durch alle definierten Filter für die Readings gejagt wird.
• Ein zweites HTTPMOD-Device, das nur die Aufgabe hat, diesen speziellen Request abzusetzen. Und nur ein Reading kennt, nämlich mitteilt, ob die WallBox das geschluckt hat.
• Ein kleines Perl-Code-Snippet in meinen 99_EnergyUtils, das alle 5 Sekunden von einem "at" aufgerufen wird und die Daten übermittelt.
• Ein Shell-Script außerhalb von FHEM, das zyklisch alle 5 Sekunden ausgeführt wird.

Mein erster Versuch wird mit Option 3 sein.

LG

pah

P.S.: Bevor mir jemand MQTT empfiehlt: Fällt deshalb flach, weil dann diese WallBox wahnsinnig gesprächig ist und das Netz jede Sekunde mit unnützen Daten zumüllt.

[betateilchen]

weil die Response - die eigentlich nur ein "true" ist - durch alle definierten Filter für die Readings gejagt wird

Brauchst Du die Antwort überhaupt für irgendwas, oder geht es nur darum, die Wallbox alle 5 Sekunden zu "füttern"?

Mein Bauchgefühl spricht für Variante 3.

[rudolfkoenig]

Ich waere fuer #3, weil ich die Moeglichkeiten von HTTPMOD nicht genau kenne.

Falls #1 keine weiteren Events generiert, dann wuerde ich messen, wieviel Last das pruefen der Regexps erzeugt: ich vermute wenig.

[Prof. Dr. Peter Henning]

@betateilchen: Die Wallbox steuert danach ihre Fotovoltaik-Überschussladung, inklusive Umschaltung 1/3 Phasen. Wie gut diese internen Algorithmen funktionieren, kann ich noch nicht sagen. Und die Antwort wäre nur interessant, um zu wissen ob die Kiste das angenommen hat.

Ich habe das jetzt mit Option 3 realisiert, weil mir das auch nach dem Gefühl das beste zu sein schien. Bisher keinerlei Last bemerkbar.

LG

pah

[Sidey]

Also vermutlich ist es am effizientesten das ganze in einem eigenen Prozess/thread laufen zu lassen, der eine Loop und ein delay verwendet.

[Prof. Dr. Peter Henning]

Schon richtig. Aber dann nicht so leicht aus FHEM kontrollierbar.
Derzeit mit dem at geht es sehr gut.

LG

pah

[betateilchen]

Also vermutlich ist es am effizientesten das ganze in einem eigenen Prozess/thread laufen zu lassen, der eine Loop und ein delay verwendet.

Das wäre aber in diesem Szenario schon ein bisschen mit Kanonen auf Spatzen geschossen...

[Sidey]

Das wäre aber in diesem Szenario schon ein bisschen mit Kanonen auf Spatzen geschossen...

Wieso? Die Frage war doch nach Effizienz und nicht einfachheit..

Im Gegensatz, je nachdem welcher der anderen Optionen verwendet wird, wäre es ziemlich ineffizient alle 5 Sekunden einen FHEM Prozess zu forken nur um einen HTTP Aufruf abzusenden.
Das wäre aber mit unter die einfachste Option denke ich.

[JoWiemann]

Hallo,

und warum nicht einfach einen cron Job? Ist doch dafür prädestiniert.

Grüße Jörg

[Prof. Dr. Peter Henning]

@Sidey: Nicht ganz. "Effizienz" bedeutet nicht unbedingt "geringster Ressourcenverbrauch des Servers" - sondern auch des Benutzers.
@JoWiemann: Ja,das war unten Pos. 4.

Der Knackpunkt ist eben, dass zu "Effizienz" auch "Einfachheit" gehört. Wenn ich irgendwann ein To-Do dafür schreibe und hoffe, dass irgendein Windows-User versteht, was es mit Cron-Jobs auf sich habe, kann ich es auch lassen.

Ich denke, am Ende wird es ein Raspberry Pi Zero werden, auf dem eine "Mini-FHEM"-Installation läuft. Und der nur die Aufgabe hat, 1x pro Minute Daten von einem SmartMeter zu holen und diese alle 5 Sekunden  an die WallBox zu leiten. Der Hersteller der Wallbox vertreibt selbst so eine "Extrakiste" - zum Preis von mehreren 100 €.

LG

pah

[zap]

Also ich halte Variante 3 für die effizienteste. Ich würde für den Request httputils mit Option keepalive verwenden, in der Hoffnung, dass die Wallbox Connection keepalive unterstützt und somit noch der ständige Verbindungsaufbau wegfällt.
Gibts eigentlich noch kein Modul, das genau dieses Verschicken von Requests übernimmt, also ein Gegenstück zu httpmod?

[Christoph Morrison]

und warum nicht einfach einen cron Job? Ist doch dafür prädestiniert.

Wie führst du mit einem Cronjob alle 5 Sekunden etwas aus? Die kleinste Auflösung sind doch Minuten. Man müsste dann jede Minute x Jobs mit sleep ausführen? Da sträubt sich etwas in mir.

Ich denke, am Ende wird es ein Raspberry Pi Zero werden, auf dem eine "Mini-FHEM"-Installation läuft. Und der nur die Aufgabe hat, 1x pro Minute Daten von einem SmartMeter zu holen und diese alle 5 Sekunden  an die WallBox zu leiten. Der Hersteller der Wallbox vertreibt selbst so eine "Extrakiste" - zum Preis von mehreren 100 €.

Immer wieder unglaublich. Steht wenigstens irgendwas mit Smart oder KI drauf?

[Prof. Dr. Peter Henning]

@Christoph Morrison: Nö. https://shop.go-e.com/de-de/controller/go-e-controller/

@zap: keepalive geht aber nur in BlockingGet. Ich benutze derzeit NonBlockingGet, das funktioniert ganz gut.

LG

pah