Time cron in Rule durch Setpoint Variable beeinflussen

[udo1toni]

Und das Item ist Member der Gruppe gMapdb? Das wäre dann ein Fehler.
Das Item muss aufgrund der Konfiguration in mapdb.persist beim Neustart von openHAB wieder auf den letzten Status vor dem Neustart gesetzt werden (ohne weiteres Zutun).

[Quautiputzli]

Und das Item ist Member der Gruppe gMapdb?

Nein, ist es nicht, mit dieser gMapdb habe ich mal etwas ausprobiert. Aber so gut wie alle Items werden wohl gespeichert. Vielleicht auch über RRD4J

[udo1toni]

Aber das ist der Punkt. Über rrd4j kannst Du DateTime nicht persistieren.
Und abgesehen davon müsstest Du ja auch restoreOnStartup als Strategy hinterlegt haben.

restoreOnStartup sollte man nur für solche Items aktivieren, wo der Status nicht ohnehin durch währende des Startup durch das führende Addon ermittelt wird. Die meisten Bus-Addons tun das, bei generic Things (z.B. mqtt) kann es anders aussehen, aber auch dort reicht meist eine kleine Rule, um den echten Status zu ermitteln, statt einen aufgezeichneten mit unbekanntem Alter (restoreOnStartup nimmt den letzten Wert in der jeweiligen Persistence, egal wie lange openHAB nicht lief, egal wann der Status persistiert wurde).

[Quautiputzli]

Mit der Persistence kenne ich mich eben gar nicht recht aus. Ich weiß nicht, was openhab da default mäßig macht.

Also zur Zusammenfassung:
- DateTime geht nicht über rrd4j, und muss deshalb z.B. über mapdb gemacht werden.
- Number und swicht Items gehen über rrd4j, und werden auch defaultmäßig beim startup zurückgeschrieben??

Dieses Item um das es mir geht, ist ja ungebunden, und wird nur über die Oberfläche eingegeben. Ich habe auch noch andere Items vom Typ switch die ungebunden sind, und die scheinen nach einem restart richtig gesetzt zu sein, obwohl ich da nichts an der Persistence eingestellt habe.

Ich muss also dieses Item in die mapdb.persist mitaufnehmen, entweder als Item selbst oder in einer Gruppe, richtig, also z.B. so:

Code: Alles auswählen

Strategies {

//        everyMinute : "0 * * * * ?"
//        everyHour : "0 0 * * * ?"
//        everyDay  : "0 0 0 * * ?"
        default = everyChange
}

Items {
	gMapdb* : strategy = everyChange, restoreOnStartup
	Startzeit : strategy = everyChange, restoreOnStartup
}

Und vor allem mapdb auch erstmal installieren. Können dann beide Presistencen parallel laufen.

PS:
bei der rrd4j scheint doch etwas eingestellt zu sein, und zwar über die UI:

Code: Alles auswählen

configurations:
  - items:
      - "*"
    strategies:
      - restoreOnStartup
      - everyChange
      - everyMinute
    filters: []
cronStrategies:
  - name: everyMinute
    cronExpression: 0 * * * * ?
defaultStrategies:
  - restoreOnStartup
  - everyChange
  - everyMinute
thresholdFilters: []
timeFilters: []
equalsFilters: []
includeFilters: []

Edit:
Oder wäre es gar besser, das Item erstmalig nach startup mit einer rule zu setzten?

[udo1toni]

Das Default Verhalten von openHAB ist abhängig von der Version. Bis OH2 musste man alles manuell installieren und konfigurieren, sonst wurde auch nichts persistiert.

Mit OH3 wurde rrd4j immer installiert, aber nicht als installiert gekennzeichnet, und als Default Persistence eingerichtet, aber nicht als solche gekennzeichnet, außerdem wurde * : Strategy = everyChange, everyMinute gesetzt - ohne, dass dies irgendwo angezeigt wurde.
Sobald man allerdings eine rrd4j.persist anlegte, wurde deren Konfiguration befolgt.
Es dürfte klar sein, dass dieses Verhalten ordentlich für Verwirrung gesorgt hat.
Hintergrund war, dass man die schicke Analyze Funktion zur Verfügung stellen wollte, ohne dass der Anwender irgendetwas dazu tun musste.

Mit OH4 ist es nun so, dass openHAB von sich aus bei der Inbetriebnahme rrd4j als Addon vorschlägt. Soweit ich weiß, ist das dann zwar immer noch nicht als Default gekennzeichnet, wird aber dennoch default genutzt, solange man nicht aktiv eine andere Persistence wählt.
Und als Strategy ist nach wie vor obige Regel aktiv, nun aber auch sichtbar, weil die Konfiguration nun ja auch über die UI vorgenommen werden kann.
restoreOnStartup ist aber definitiv keine Default Strategy, die musst Du irgendwann selbst hinzugefügt haben - und das ist keine gute Idee.
rrd4j kann aber so oder so nur mit rein numerischen Werten umgehen, wobei OFF, ON, OPEN und CLOSED auf die Werte 0 und 1 gemappt werden.
DateTime, String, Color usw. haben ein Format, welches rrd4j nicht speichern kann.

Du kannst beliebig viele Persistence Services parallel betreiben, aber nur einen als Default Persistence auswählen. Die Default Persistence ist Datenquelle an allen Stellen, an denen Du nicht explizit eine andere Datenquelle angibst.
Weiterhin kann man für jedes Item separat entscheiden ob, und wenn ja wie das Item persistiert wird, und zwar individuell für jeden Persistence Service.
Ob Du diese Konfiguration über die UI erledigst, oder über Textdateien, ist egal, allerdings wäre es sinnvoll, sich für einen Weg zu entscheiden, und diesen für alle Persistence Services zu nutzen (also nicht Persistence A über die UI und Persistence B über Textdatei). Dabei geht es in erster Linie darum, Chaos zu vermeiden
Da rrd4j ausschließlich mit numerischen Werten umgehen kann, ist es als Quelle für restoreOnStartup nur begrenzt geeignet. mapdb ist im Gegensatz dazu ausschließlich für diese Anwendung geeignet, weil sich mapdb nur exakt einen Zustand merken kann. Je nach Konfiguration kann das der letzte Zustand sein (everyChange) oder auch ein Zustand zu einem bestimmten Zeitpunkt (z.B. everyHour...) oder gar ein gezielt persistierter Wert (aus einer Rule heraus MeinItem.persist("mapdb") speichert den aktuellen Zustand von MeinItem in MapDB)

Also per Default (wenn rrd4j installiert, aber nicht weiter konfiguriert ist) werden alle Items jede Minute und bei jeder Änderung in rrd4j gespeichert, allerdings können nur numerische Werte auch wieder ausgelesen werden - für Contact und Switch sind die beiden möglichen Zustände auf die Werte 0 und 1 gemappt. Ein restore findet nicht statt.

Die bequeme Variante ist es, in den Items verschiedene Group Items zu definieren, Items, die persistiert werden sollen, werden dann den Groups zugewiesen. Anschließend konfiguriert man die Group Items passend in die Persistence hinein. Dabei wird der Itemname vollständig ausgeschrieben. Ein * am Ende des Namens bedeutet, dass nicht das Item selbst persistiert wird, sondern stattdessen alle unmittelbaren Member des Group Items.
Für jedes Wunschverhalten legt man ein eigenes Group Item an und hinterlegt die gewünschte Strategy, so kann man anschließend Items einfach diesem Group Item hinzufügen, um das konfigurierte Verhalten für dieses Item zu erreichen.
Diese Option - per Group Item - ist für Charts in Sitemaps noch zusätzlich interessant, denn man kann dort das Group Item als Quelle für den Chart angeben. In der Folge werden die persistierten Werte alle zugeordneten Items in ein gemeinsames Chart gemalt - das kann z.B. für Temperaturen aller Räume im Haus ganz nett sein, um starke Abweichungen besser zu visualisieren.
Das Chart Widget greift dabei immer auf die einzelnen Item Tabellen zu, man kann solche Group Items also auch nachträglich für bestehende Item Persistences erstellen.

[Quautiputzli]

Okay, das bringt etwas Klarheit.
Das heißt für mich ich entferne die Strategy "restoreOnStartup" für alle Items, und packe die ungebundeden Items bei denen ich gerade das will in eine Group, und dort dann mit der Strategy "restoreOnStartup".

Und Für DateTime und color das ganze in Mapdb.

Danke

[udo1toni]

Ja, das wäre eine sinnvolle Variante