openhabforum.de

Hallo,

ich habe ein item (item_xy) als Number.
Ich möchte diese Nummer um punkt 21:00 Uhr mit dem Wert einer anderen Variable befüllen.
Dachte dabei an eine rule so in etwa:
zusätzlich möchte ich nun falls openhab ausfällt beim starten das ganze auch noch haben. d.h. ich muss den werte von item1 persistieren, und im fehlerfalle wiederherstellen. rr4dj ist installiert.
bitte um info!
danke,

23 Uhr oder 21 Uhr? (macht ja keinen Unterschied, aber man muss schon die gewünschte Uhrzeit angeben...)

Um ein Item beim Start von openHAB mit einem wert zu laden, nutzt Du die Persistence Deiner Wahl, persistierst das Item und konfigurierst die Strategy auf everyChange,restoreOnStartup. Soll der Wert auf jeden Fall der eines bestimmten Zeitpunkts sein (also z.B. der Wert von 23 Uhr, ohne Rücksicht darauf, was sonst so im Item gelandet ist), so ist eine leicht andere Vorgehensweise besser, und zwar setzt Du die Strategy auf restoreOnStartup (ohne das everyChange). Weil rrd4j zwingend everyMinute als Strategy benötigt, ist rrd4j hier ungeeignet, dafür aber mapdb, und zwar bestens.
Mit der gesetzten Strategy wird also der persistierte Wert beim Start von openHAB geladen. Um das Item gezielt zu persistieren, nutzt Du diese Rule: Um ein Item auf einen bestimmten Status zu setzen, musst Du allerdings zwingend eine Action oder eine Methode verwenden, Das hier: funktioniert nicht.

wo in openhab3 sind die rr4d eigenschaften eingetragen? Meine Fronius Channels bzw. generell items sind alle automatisch persistiert wie ich sehe...
Muss ich hier achten, dass die eine Variable nur um 23 Uhr persistiert wird, und nicht ständig ?
PV_Total_gen24 heißt die bei mir. als Channel vom fronius inverter (Total Energy).

mit der Rule ist schon mal die persistierung gewährt.
jetzt müsste ich nur noch wissen wo ich für genau diese Variable einstelle, dass ich beim neustart draus lese, und nur einmal und nicht kontinuierlich wie scheinbar aktuell eingestellt persistiere.

achja, und der Zugriff in einer anderen Rule sieht dann wie aus ? (Muss aktuellen Wert von PV_Total_gen24 - persistierten wert von PV_Total_gen24 nehmen), damit ich tagesaktuellen bekomme. (ein Bug im GEN24 Fronius Solar API, die leider keine Tagesaktuelle Erzeugung liefert).
sind Number:Energy Point vom Datentyp.

NACHTRAG: vielleicht noch einfacher: gar nicht um 23 Uhr persistieren, sondern einfach den Wert vom Vortag auslesen von 23 Uhr ? geht das ?

vielen dank!

Die Strategy der Persistence wird bis einschließlich openHAB3 ausschließlich über *.persist Dateien gesteuert.
Dabei gibt es für jeden Persistence Service eine <service>.persist Datei im Ordner $OPENHAB_CONF/persistence/, also z.B. rrd4j.persist für rrd4j.

Und weil die Entwickler von openHAB gerne mal inkonstent sind, haben sie sich überlegt,

1. rrd4j zu installieren ohne das irgendwo kenntlich zu machen
2. rrd4j als Default Persistence zu verwenden, ohne dass dies ausdrücklich ausgewählt ist (also solange nicht explizit eine andere Persistence als Default Persistence ausgewählt ist)
3. einfach alle Items zu persistieren, wenn zu einem Persistence Service keine <service>.persist Datei existiert.
4. Dabei als Default Strategy everyMinute,everyChange zu verwenden, obwohgl auch dies nirgendwo konfiguriert ist.

Diese Entscheidung trägt meiner Meinung viel zur Verwirrung um die Persistence bei, auch wenn sie es Anfängern erst mal leicht macht, sofort und ohne weitere Anstrengungen "hübsche" Charts zu sehen. Die Kehrseite ist aber, dass niemand die eigentlichen Zusammenhänge begreift und sich dann wundert, warum "plötzlich" keine Charts mehr vorhanden sind, obwohl man doch "gar nichts" gemacht hat (in diesem Fall ist "gar nichts" vielleicht, einen anderen Persistence Service zu installieren und zum Default zu machen).

rrd4j ist an dieser Stelle komplett ungeeignet, denn rrd4j setzt zwingend eine Persistierung mindestens im Minutentakt voraus (Strategy everyMinute). Wird nicht mit everyMinute persistiert, kann man nicht auf die persistierten Daten zugreifen.
Anders sieht es bei anderen Persistence Services aus, dort kannst Du everyMinute einfach weg lassen und z.B. nur mit everyChange persistieren, oder eben auch gar nicht, sondern ausschließlich mit der restoreOnStartup Strategy beim Start des Systems den aktuellen Zustand wiederherstellen. Wenn es nur darum geht, den Zustand zu einem bestimmten Zeitpunkt wiederherzustellen, kannst Du auch einfach mapdb nutzen. mapdb speichert nur exakt einen Wert, das ist gewöhnlich der aktuelle (Strategy everyChange), aber auch dort kann man natürlcih eine andere Strategy setzen, z.B. everyDayAt23 (es gibt Standard Strategies, everyChange, everyUpdate, restoreOnStartup, und selbst definierte Cron Strategies, dazu gehört auch everyMinute(!), die selbst definierten Strategies kannst Du nennen wie Du willst, meinetwegen auch Konstantinopel, aber es bietet sich natürlich ein NAme an, der sprechend ist und den normalen Namenskonventionen entspricht, erlaubt sind die Buchstaben des englischen Alphabets und die arabischen Ziffern (nicht an der ersten Stelle im Namen)

Wenn Du nur den Wert vom Vortag um 23 Uhr haben willst, kannst Du den einfach über die Persistence ermitteln: In Einzelteilen:
().floatValue -> Ein floatValue, der dem Wert innerhalb der Klammern entspricht. Geht nur, wenn es sich dabei um ein Number Objekt handelt (nur dann steht auch die Methode .floatValue zur Verfügung).
Entsprechend <Wert> as Number -> Caste <Wert> nach Number, also erzeuge ein Number Objekt, welches <Wert> entspricht. Dafür muss es möglich sein, <Wert> als Number zu interpretieren (das ist hier der Fall)
now.with(LocalTime.MIDNIGHT) -> Mitternacht, genauer 00:00:00 Uhr des aktuellen Tages. Immer dran denken, der letzte Sonntag im Oktober hat 25 Stunden, der letzte Sonntag im März hat 23 Stunden. Beides wird bei LocalTime.MIDNIGHT berücksichtigt.
.minusHours(1) -> eine Stunde vorher -> now.with(LocalTime.MIDNIGHT).minusHours(1) -> 23 Uhr des Vortages.
MeinPersistiertesItem.historicState().state -> der historische Status eines Items. Obacht! .state ist hier notwendig, denn historicState liefert ein historicItem zurück, dieses hat verschiedene Methoden, z.B. auch .timestamp (das ist NICHT der abgefragte Zeitpunkt, sondern der Zeitpunkt, zu dem der anstehende Status im Items gespeichert wurde) Also z.B. wurde ein Wert 15 um 22 Uhr gespeichert, das nächste Mal wurde ein Wert 39 um 23:30 Uhr gespeichert. Frage ich nun .historicState('23 Uhr').state ab, bekomme ich 15 als Wert. .historicState('23 Uhr').timestamp liefert 22 Uhr.

Mein Versuch, mit und ohne .floatValue leider bleibt PV_DaySum_gen24 bei 0.

Nein, so geht das nicht.
Erst mal gehört da kein Semikolon hin, grundsätzlich nie. Das Semikolon wird bei JavaScript gebraucht, der Code ist aber openHAB Rules DSL (basierend auf XTend, welches in Java entwickelt wurde). Einzige Ausnahme: return; erfordert ein Semikolon.

Taste Dich bitte heran, statt einen Term zu verwenden, von dem Du glaubst, dass er korrekt wäre (ist er nicht, die beiden Ausdrücke müssen geklammert werden, weil as Number nachrangig ist)
Also lieber so: Wenn Du das Fronius Binding verwendest, so liefert das Item PV_Total_gen24 mit hoher Wahrscheinlichkeit Werte mit Einheit, also z.B. 15000 kWh und keine reinen Zahlen, also z.B. 15000. Auf den ersten Blick mag das keinen Unterschied machen, aber die Persistence liefert nicht unbedingt ebenfalls Einheiten, und 15000 kWh - 14965 kann man nicht berechnen, da es sich um zwei unterschiedliche Größen handelt.
Das ist einer der Gründe für das .floatValue, das schneidet nämlich Einheiten ab.

udo1toni hat geschrieben: ↑16. Jun 2023 14:20 Einzige Ausnahme: return; erfordert ein Semikolon.

Danke, jetzt weiß ich auch, warum bei mir return nicht funktioniert hat

return gibt an die aufrufende Routine einen Wert zurück. Dieser Wert steht hinter return. Damit wird also ein nachfolgender Befehl zum Rückgabewert, womit die Rule unvollständig wird.
Aber auch wenn man dort einen Wert hinschreibt, gibt es ein Problem, denn die aufrufende Routine erwartet keinen Rückgabewert, es käme also zu einer Fehlermeldung. Das Semikolon am Ende des Befehls unterdrückt den Rückgabewert.

jetzt hab ichs, danke.
Nur beim Gemeinsamen Tagesertrag beim summieren hauts mich noch her: