Was bedeutet die Fehlermeldung und was kann ich dagegen tun

[pschauder]

Hi,

bei meinen letzten Experimenten habe ich zu Testzwecken eine Cron Rule eingebaut, die einige Stati regelmäßig ins Log schreibt. Dabei ist mir aufgefallen, dass einige 'plötzlich' -uninitialized- daherkommen. Also im Log zurückgespult und dann das hier gefunden:

2015-05-16 16:27:00.026 [INFO ] [org.openhab.model.script.LogIt] - gstatus Status_Handle_it  1   : OFF
2015-05-16 16:27:00.031 [INFO ] [org.openhab.model.script.LogIt] - gstatus Status_Sonne_Buero  2   : OFF
2015-05-16 16:27:00.035 [INFO ] [org.openhab.model.script.LogIt] - gstatus Status_First_Buero  3   : OFF
2015-05-16 16:27:36.811 [INFO ] [c.internal.ModelRepositoryImpl] - Refreshing model 'Haus.items'
2015-05-16 16:28:01.421 [WARN ] [tuwien.auto.calimero          ] - [KNXnet/IP receiver] KNXnet/IP Tunneling 127.0.0.1:3671: skipped tunneling request with rcv-seq 177
2015-05-16 16:28:01.428 [WARN ] [tuwien.auto.calimero          ] - [KNXnet/IP receiver] KNXnet/IP Tunneling 127.0.0.1:3671: skipped tunneling request with rcv-seq 177
2015-05-16 16:28:23.184 [INFO ] [org.openhab.model.script.LogIt] - gstatus Status_Handle_it  1   : OFF
2015-05-16 16:28:23.189 [INFO ] [org.openhab.model.script.LogIt] - gstatus Status_Sonne_Buero  2   : Uninitialized
2015-05-16 16:28:23.196 [INFO ] [org.openhab.model.script.LogIt] - gstatus Status_First_Buero  3   : Uninitialized

Vermutlich gibt es einen Zusammenhang mit den "Haus.items", aber was könnte das sein? Ist der kleine Raspberry B2 kurzzeitig in die Knie gegangen? Wurde der Bus nicht richtig bespaßt?

Wenn sowas nur bei Änderungen auftritt, wäre das ja zu verkraften, aber kann das auch im laufenden Betrieb passieren?

Gruß
Peter

[pschauder]

Hm, weiter getestet und herausgefunden: Die Zustandsänderung der Switche hat nichts mit dem Fehler zu tun, nur mit dem Haus.items Update.

Dazu dann die Frage: was kann ich dagegen tun?

Außerdem bleibt die Frage: was bedeuten die beiden Fehlermeldungen die sich ja scheinbar auf die KNX Kopplung beziehen.

Gruß
Peter

[RoRo]

Das gleiche (items-File-Update setzt Werte auf "undefined") ist mir kürzlich auch aufgefallen.
Als Abhilfe habe ich die entsprechenden Items persistent gemacht, indem ich sie in eine Gruppe "Persist" gepackt habe, welche ich via rrd4j.persist wie folgt definiert habe:

Strategies {
    everyMinute : "0 * * * * ?"
}

Items {
    Persist* : strategy = everyChange, everyMinute, restoreOnStartup
}

Im Zweifel werde ich das mit openHAB 1.7 auf https://github.com/openhab/openhab/w...db-Persistence umstellen, mit der momentanen 1.6.2 ist rrd4j zwar eigentlich massiv oversized, funktioniert aber.

Tschoeeee
Roland

[pschauder]

Hi,

hab das mit der Persistens geübt, bin aber an der xxx* Version gescheitert. Ich kann zwar Hugo_01 und Hugo_02 getrennt als Persistens eintragen, wenn ich das gleiche mit Hugo_* mache, funktioniert es aber nicht. Auch die Version mit Angeben einer Gruppe funktioniert nicht. So wie ich die Beschreibung der Persistens verstanden habe, sollte aber auch eine Gruppe gehen, oder?

Gruß

[udo1toni]

Wenn Du einzelne Items persistieren willst, musst Du sie auch einzeln in der jeweiligen .persist angeben. Alternativ kannst Du alle zu persistierenden Items in eine Gruppe packen, und die Gruppe persistieren, die musst Du dann als Gruppenname* in der .persist einfügen. Der * steht also nicht als Platzhalter für beliebige Zeichen in einem Itemnamen, sondern als Markierung, dass eine Gruppe gemeint ist, und deren Mitglieder persistiert werden sollen.