What is reset to uninitialized on configuration change?

Setup, Configuration and Use Beginners
1

I have several files for items, e.g. counters (for reading meter data), lights, blinds and so on.

I now noticed that if I change any of that files, it seems that all items forget their current data. So if I change something in the blinds file, the log shows that this file gets refreshed, but also the items from the other files are reset to uninitialized. Is this the expected behaviour? Or am I doing something wrong?

Most of these items are periodically set (either from rules or from the knx bus), so I don’t need and don’t want to persist them.

2

Yes, whenever you load a new Items file it needs to reload all your Items which causes their states to be reset.

To avoid the UnDef state you will have to use persistence and restoreOnStartup. Or just live with the brief periods where it is UnDef.

3

Thank you for clarification. Does that also apply for rules, scripts and so on? So if I edit a rules file will all rules be reloaded? Or even worse will items be reloaded also on rules change?

4

Based on my experience it does not apply to rules and scripts. Items are not cleared when you change a rule or script file and changing one rule file does not cause others to reload (and therefore re-execute the System started triggered rules).

The difference is, I believe, that since an Item can be a member of a Group from another .items file OH has to reload all of them to pick that up. Rules and script files on-the-other-hand are intended to be discrete from each other so there is no need to reload them all when one changes.

5

Is there a possibility to persist only the latest version? There are a lot of items that should be initialized with the last value after a restart or items change, but I don’t need the history.

Also there is a problem with the astro binding, which also looses it’s data after items change, but obviously has only a timer job for refreshing the sun position values, but sunset and sunrise seems to get populated only on midnight. Is there a way to get this working? I think I could persist these values, but I also have events on this times, and I think they won’t trigger until set again after midnight.

6

Have a look at the “mapdb” persistence service. I am using this for the exact same reasons as you list above.
/Kjetil

7

Great, thank you! And sorry, that I didn’t find it myself. :wink:

But I think that doesn’t solve the problem of the astro binding, which looses it’s events on items change?! Didn’t tested it so far, but because the DateTime values are lost, I guess the event’s won’t fire, also?

8

I also have the astro binding mapped to DateTime and Switch items as follows:

DateTime	AstroSun_tSunrise	{ astro="planet=sun, type=rise, property=end" }
DateTime	AstroSun_tSunset	{ astro="planet=sun, type=set, property=start" }

Switch		AstroSun_sSunrise	{ astro="planet=sun, type=rise, property=end" }
Switch		AstroSun_sSunset	{ astro="planet=sun, type=set, property=start" }

I assume your setup is similar.

As you indicate, the astro binding does some internal updating at midnight. This results in the DateTime items being updated to new values for the next 24 hour period, as well as internal timers being scheduled for updating the Switch items at correct times. Note that the Switches will, when either sunrise or sunset is happening, only briefly toggle to indicate the event.

So, to the persistence side of things:

The DateTime items will be persisted, and restored, using the mapdb service so I don’t see any problems with this.

The Switch items likewise, although this is not important since the information is not in the state, but rather in the “change of state”.

All-in-all, I don’t see any immediate problems, and I don’t remember experiencing any.

BR
Kjetil

9

I think I may have a solution to this which I’ve implemented by accident. I use Sunrise and Sunset events to drive time of day switches (see this post). As part of this solution I have a system started rule which accesses the state of a couple of Astro Items. When ever that rule reloads I get a log statement saying that Astro has recreated the timer to recalculate the times for midnight and I believe it also recalculates the new time for the current day at that time.

I also use persistence so if rrd4j can persist date times that is also working for me as well.

The end story is that I have done something in my environment which has somehow inadvertently prevented this problem for me.

10

I spotted a similar behavior if I edit the file with the astro items. Then I see the same log entries you mentioned and everything is filled and seem to work.
But if I edit other items files, this doesn’t happen. Maybe I have to have a look into the astro binding code to see what is happening exactly.
I’m using mapdb now for persisting the items I only need the latest state and it seems to work well (although I spotted some item names in the mapdb storage file that shouldn’t be persisted with mapdb but with MySQL!?).

All in all it’s not a huge problem because once my system setup is completed, it shouldn’t be edited this often so it won’t happen often. But I have some rules based on astro events and it would be annoying if sunset doesn’t work every day I edit my configuration…