Initialisierung nach Neustart

[HiG]

Moin,

was ist denn bei OH die "best practice" für die Initalsierung von Item nach einem Neustart

Einige meiner Rules steigen nach einem Neustart mit Exceptions aus

Code: Alles auswählen

2022-01-23 18:31:11.545 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'heizung-3' failed: Could not cast NULL to java.lang.Number; line 60, column 28, length 31 in heizung

Rule-Fragment

Code: Alles auswählen

rule "Temperatur Kueche"
when
   Item x_eg_ku_wi_01_t changed or 
   Item eg_ku_hz_Temp_Ist changed
then
val Number temp2_off   = ((x_eg_ku_wi_01_t.state as Number))     //Zeile 60
val Number temp1_off   = ((eg_ku_hz_Temp_Ist.state as Number))
val Number temp_off   = ((temp1_off+temp2_off)/2)

Das Item "x_eg_ku_wi_01_t" wird per Mqtt "gefüttert"...nach einem Neustart aber ja auch erst wenn sich der Wert geändert hat. Solange scheint der auf NULL zu bleiben. Umgehn knnte ich das wahrscheinlich mit

Code: Alles auswählen

val Number temp2_off   = if(x_eg_ku_wi_01_t instanceof Number) ((x_eg_ku_wi_01_t.state as Number)) else 200

Aber klappt das wirklich immer?


Ebenso wäre es vielleicht ganz sinnvoll Nachts einige Variablen in den Initialzustand zu versetzen. Beispielsweise ob Besuch da war. Da habe ich aber noch keine wirkliche Idee.

Wie handhabt ihr diese Dinge?

[udo1toni]

Aber klappt das wirklich immer?

Ja, das klappt wirklich immer.

Ebenso wäre es vielleicht ganz sinnvoll Nachts einige Variablen in den Initialzustand zu versetzen. Beispielsweise ob Besuch da war.

Ja, kann man machen. Natürlich streng begrenzt auf items, bei denen ein solcher Reset sinnvoll ist.

Gewöhnlich wird man Items entweder über den Umeg einer Variablen

Code: Alles auswählen

var Number temp2_off = 200
if(x_eg_ku_wi_01_t instanceof Number) 
    temp2_off = (x_eg_ku_wi_01_t.state as Number)

oder mit dem ternären Operator

Code: Alles auswählen

val Number temp2_off = if(x_eg_ku_wi_01_t instanceof Number) ((x_eg_ku_wi_01_t.state as Number)) else 200

mit einem Default Wert versehen.

Oder aber man persistiert die Items und setzt als Strategy mindestens everyChange, restoreOnStartup.

Man muss dennoch in der Rule sicherstellen, dass das Item einen gültigen Wert enthält, wenn man NullPointer Exceptions zuverlässig verhindern will.
Man kann damit aber den Default Wert als absoluten Fallback nutzen, nicht als Standard, wenn openHAB neu gestartet wurde.

[HiG]

Oder aber man persistiert die Items und setzt als Strategy mindestens everyChange, restoreOnStartup.

Das wird nicht klappen! Ich habe seit der Umstellung auf Mqtt nen Consolenlistener laufen, welcher die Werte schön in einer Oracle-Db "parkt". Die anderen Persistencen werden abgeschaltet

nicht als Standard, wenn openHAB neu gestartet wurde.

Was wäre da denn ein konformer Weg?

[udo1toni]

Oder aber man persistiert die Items und setzt als Strategy mindestens everyChange, restoreOnStartup.

Das wird nicht klappen! Ich habe seit der Umstellung auf Mqtt nen Consolenlistener laufen, welcher die Werte schön in einer Oracle-Db "parkt". Die anderen Persistencen werden abgeschaltet

Das hat nichts mit Persistence zu tun. Persistence ist eine Funktion in openHAB, um historische Daten in openHAB zur Verfügung zu stellen. Was Du außerhalb openHAB anstellst, ist Deine Sache.

nicht als Standard, wenn openHAB neu gestartet wurde.

Was wäre da denn ein konformer Weg?

Da hast Du was missverstanden. Selbstverständlich ist jeder Weg, einen gültigen Wert zur Verfügung zu stellen "konform". aber ein Default Wert ist nun mal nur das, ein Default Wert.
Gewöhnlich ist dann ein fixer Wert gesetzt, der vielleicht nicht all zu viel mit dem realen Wert zu tun hat. Der letzte bekannte Wert (über restoreOnStartup) ist meist die bessere Wahl.

[KellerK1nd]

Gibt es in openhab 3 noch das Rule load delay von openhab 2?

[HiG]

Der letzte bekannte Wert (über restoreOnStartup) ist meist die bessere Wahl.

Dann lass ich RoundRobin doch drin....

[udo1toni]

Für restoreOnStartup kann man hervorragend mapdb nutzen. mapdb speichert ausschließlich den aktuellen Wert, hat also keine Historie, dafür ist es echt klein und schnell. Man kann beliebig viele Persistences parallel laufen lassen...

[udo1toni]

Gibt es in openhab 3 noch das Rule load delay von openhab 2?

Meiner Erinnerung nach ist das eine Funktion von openHABian. Eigentlich sollte die Rule Engine erst starten, wenn die Persistence schon durchgelaufen ist. in openHAB3 gibt es dafür die neu eingeführten Startlevel. Ich bin mir aber nicht sicher, ob diese ganzen Mechanismen auch zu 100% funktionieren.

Die Startlevel kann man jedenfalls in Rules auch als Trigger verwenden. Man könnte also gezielt Items bereits per Rule mit Daten befüllen, wenn die Persistence noch dabei ist, andere Items zu befüllen.Oder man startet eine Rule gezielt, nachdem die Daten aus der Persistence eingelesen wurden.

[HiG]

Für restoreOnStartup kann man hervorragend mapdb nutzen

Wo finde ich denn die persistierten Werte?

Ich hab das Binding installiert...konfigurieren scheint nicht notwendig, mapdb.persist angelegt

Code: Alles auswählen

Strategies {
        everyDay  : "0 0 0 * * ?"
        everyHalfDay : "0 0 */12 ? * *"
        everyQuarterDay : "0 0 */6 ? * *"
        everyHour : "0 0 * * * ?"
        everyEvenHour : "0 0 0/2 ? * *"
        everyOddHour : "0 0 1/2 ? * *"
        everyHalfHour : "0 */30 * ? * *"
        everyQuarterHour : "0 */15 * ? * *"
        everyMinute : "0 * * ? * *"
        everyEvenMinute : "0 */2 * ? * *"
        everyOddMinute : "0 1/2 * ? * *"
       default = everyChange
}
Items {
     sZuhause : strategy =  everyEvenMinute, restoreOnStartup
}

und... den Service neugestartet. Aber wo seh ich was?
Ausser

Code: Alles auswählen

2022-01-24 17:06:55.964 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mapdb.persist'

finde ich im Log nichts

[udo1toni]

Mach die Strategies bitte alle weg, die sind komplett unsinnig. Nutze stattdessen everyChange, restoreOnStartup, das ist hinreichend.

Wenn Du mapdb installiert hast, läuft das einfach. Da wird gewöhnlich nichts geloggt, es sei denn Du drehst Das logging auf TRACE hoch. Die Datei, in der die Status landen, ist an gleicher Stelle untergebracht wie die rrd4j Dateien, $OPENHAB_USERDATA/persistence/