openhabforum.de

Hallo zusammen,
ich habe eine Regel, die alle 10 Min aufgerufen wird: Jetzt hätte ich gerne, dass wenn ein bestimmtes Item stein status ändert, diese Regel nicht mal alle 10 Minuten sondern alle 2 Minuten aufgerufen wird. Hat jemand eine Idee wie ich das realisieren könnte?

Viele Grüße und Danke vorab

Den Cron alle 2 Minuten aufrufen und über den Itemstatus switchen, ob die Rule jedes Mal oder nur jedes 5. Mal durchlauft

Ich frage mal andersrum: Warum?
Grundsätzlich ist openHAB ein ereignisgesteuertes System. Bei zyklischen Rules gibt es oftmals effizientere Wege. Z.B. könntest Du einen gewöhnlichen Timer mit Reschedule verwenden, beim Reschedule kann man dann die Zeit anpassen. Aber wie erwähnt kommt es auf die Funktion an...

Gesendet von meinem SM-G973F mit Tapatalk

EmptySoft hat geschrieben: ↑6. Jun 2020 19:43 Ich frage mal andersrum: Warum?
Grundsätzlich ist openHAB ein ereignisgesteuertes System. Bei zyklischen Rules gibt es oftmals effizientere Wege. Z.B. könntest Du einen gewöhnlichen Timer mit Reschedule verwenden, beim Reschedule kann man dann die Zeit anpassen. Aber wie erwähnt kommt es auf die Funktion an...

Hintergrund ist folgender: Ich habe meinen Zoe in Openhab eingebunden und wenn der Zoe steht, dann frage ich alle 10 Min die aktuellen Serverwerte ab. Es werden die Updates des Batteriezustandes etc. nicht regelmäßig zu bestimmten Uhrzeiten geschickt. Daher hatte ich mal so aus dem Bauch heraus 10 Min eingestellt. Wenn der Zoe allerdings geladen wird, dann geht das auch minütlich. Dadurch bekomme ich detaillierte Infos über das Ladeverhalten.

EmptySoft hat geschrieben: ↑6. Jun 2020 19:43 Den Cron alle 2 Minuten aufrufen und über den Itemstatus switchen, ob die Rule jedes Mal oder nur jedes 5. Mal durchlauft

Das wäre ein smarter Weg und leuchtet mir auch ein...Ich wollte halt die Last so gering wie möglich halten.

Warum triggerest du nicht auf Änderung/Update Akkuzustand? Dann arbeitet die Regel auch wirklich nur, wenn auch Werte sich ändern/updaten.

KellerK1nd hat geschrieben: ↑7. Jun 2020 16:27 Warum triggerest du nicht auf Änderung/Update Akkuzustand? Dann arbeitet die Regel auch wirklich nur, wenn auch Werte sich ändern/updaten.

und dann hast Du auch alle Werte

KellerK1nd hat geschrieben: ↑7. Jun 2020 16:27 Warum triggerest du nicht auf Änderung/Update Akkuzustand? Dann arbeitet die Regel auch wirklich nur, wenn auch Werte sich ändern/updaten.

Das geht leider nicht. Um den Wert überhaupt zu bekommen, muss ich ein python script laufen lassen, der den Wert erst holt....

Um das im pseudo code zu veranschaulichen: Wenn ich nun auf das aktualisieren des Akkuzustandes warten würde, dann würde dieser sich nie verändern. Da das Skript nicht ausgeführt wird.

Habe es jetzt so gelöst wie EmptySoft es vorgeschlagen hatte:
Blöd ist halt, das der Status "charging" erst dann gesetzt wird wenn ich die 10 Min erreicht habe. Das heißt ist habe im Worst-Case 10 Min charging-status ohne das Item refreshed zu haben. Wenn der Ladevorgang abgeschlossen ist, stört es mir nicht so sehr, da ich dann halt das Skript für 10 min alle 2 Min aufrufe....

Ideen wie ich das noch cleverer lösen könnte um den Versatz zu minimieren?

Du schreibst, dass durch das Python-Script die Items aktualisiert werden.

Was spricht denn dagegen, das Python-Script viel häufiger laufen zu lassen, etwa minütlich? Das ändert dann das Item, in der der aktuelle Ladestrom drinsteht.
Auf dieses Item kannst du dann mit "Item ... changed" triggern und alles notwendige tun.

So mache ich das bei unserer PV-Anlage, wo ich minütlich via REST die aktuelle Leistung und die erzeugten kWh abhole. Allerdings starte ich zum Sonnenaufgang einen Timer, der das minütlich macht und der bei Sonnenuntergang gecancelt wird, um den Cron-Job zu sparen.

Ich habe einen SolMate (genau das Gegenteil von Deiner ZOE eine Photovoltaikanlage mit Accu) die ich über eine REST API abfrage. Den frage ich im 5 Sekunden Takt ab, wenn sich die Werte ändern, pusche ich sie per MQTT an OpenHab und speichere im PythonScript die alten Werte um sie nach 5 Sekunden wieder mit den neu geholten Werten zu vergleichen. Besser kann ich es nicht (habe mir den ganzen IT-Kram selber beigebracht) Das Script verbraucht vernachlässigbare CPU Load

OH ist ereignisgesteuert. Am einfachsten nachvollziehbar sind die Ereignisse "Item hat den Wert geändert" oder "Item hat ein Kommando empfangen".

Die betreffenden when-Statements lesen sich dann fast wie ein Aufsatz, und man kann sofort sehen, worum sich eine Rule kümmert, ganz im Gegensatz zu Time cron-Rules.

Um also ein externes System, für das es in OH kein Binding gibt, das aber zum Beispiel ein REST-Schnittstelle hat, anzubinden, schreibt man etwa ein Python-Script, das regelmäßig die benötigten Daten aus dem System holt und in Items schreibt. Mehr machen Bindings im Grunde genommen beim Lesen von Systemdaten auch nicht.

Alles andere, auch Vergleiche, ob sich der Wert eines Items geändert hat, sollten dann in einer Rule gemacht werden.

Dann verhalten sich alle Systeme, ob sie nun über ein Binding oder selbst angebunden sind, Rule-seitig gleichartig.