Is it possible to configure timing between items load and persistance load on OH start?

I migrated from OH 2.1 to OH 2.2 and see some strange error messages in the log.

I think all of the are related to a too fast loading of rules and persistence after loading of items. Is there a way to configure the tiem to wait between items loaded and persistance loaded?

Log file:

item added
2017-12-26 16:12:33.570 [.ItemChannelLinkAddedEvent] - Link 'DoorSensor24-zwave:device:15a7a49f3a6:node24:sensor_door' has been added.

persistance loaded
2017-12-26 16:12:37.414 [vent.ItemStateChangedEvent] - DoorSensor24 changed from NULL to CLOSED

rule with item executed
2017-12-26 16:12:46.570 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'DoorSensor24 Event': The name 'DoorSensor24' cannot be resolved to an item or type; line 1343, column 7, length 12

Any idea?

No it’s not possible.

Give @sjka another pretty please for implementing this.

1 Like

I have a script that runs on startup from Cron that moves all but 1 of my rules files into a separate folder on startup.
The remaining rules file has one rule that is triggered by one item being changed by persistence, this rule then moves the first rule back, each rule then moves another back when it’s loaded.
It works very reliably

I’m seeing this sometimes during startup, too.
But it never shows up during normal operation and all rules are working fine. So it seems its just a problem because during startup those items don’t have a state yet (or let’s say: openHAB is not aware of the state yet).

I would not worry about this :sunglasses:

I’m still manually moving away my rules files on OH restart and move them back in after items files have been processed.
That’s somewhat acceptable effort as you shouldn’t be restarting OH too often … then again, it’s annoying and no professional solution, so I’m still hoping for Simon (or someone else to join in ?) to finally embark on implementing that ESH feature I mentioned, that would be the right “once and for all” solution.
So possibly there’s quite some more people to have this problem going unnoticed ?

1 Like

The other banana skin I keep slipping on is, to me at least, every time a major update comes out, something seems to subtly change that upsets the exact order items initialise or rules work in.
I’m currently battling with a rule that sends a gpio command in a command window via wiring Pi to switch power to an IR LED, and then sends out an IR command, again in a window via LIRC. Most of the time it works, but occasionally the gpio command doesn’t complete in time.
It’s intermittent and very hard to reproduce, let alone fix