A typical use case with CalDav i think is switching items to a defined state.
With this use case what would be the best way of initializing the associated item after a reload or restart. I surely would not want to repeat the “logic” in the calendar events in the startup rule.
In simple cases i assume we could use the “next event” feature and switch to the opposite state (e.g. heating will go “ON” on 1.10, so obviously it should be “OFF” now).
But wouldnt it be better having a “previous event” feature, too? Or must we revert to item persistence here?
This would imply, the calender is the only source which can switch the item.
Instead of relying on calender events, you better should use persistence to get the last known state (in case of reboot or restart). Be aware that even this state can be out of date, since a restart will need some time, and maybe the hardware was switched manual meanwhile.
The problem isn’t one of a race condition as it is one of having your devices report their current states. Once both the .items files and .persist files have been loaded all of the Items that are configured with restoreOnStartup get initialized to the most recent value in the DB. I’m not certain this is guaranteed to occur before the bindings start for the individual Items but I’ve not seen any reports on this forum that it is a problem.
However, the real problem is having a way for openHAB to say “Hey! I was asleep, what’s your current state?” In my setup I have a custom coded script which openHAB can send an MQTT script to which will cause my remote devices to publish their current state. But this will not always be possible for every device or technology.
As to my other question - i have confirmed in the source (1.8) that persistence service will not set item state if it something other than Uninitialized. So, item persistence and bindings will not interfere.
But rules will! I found no description on timing so far, so i assume it is possible that rules will initialize to a default-default - after this persistence will no longer touch the item?
Rules are not involved with initialization. If the rules start running before all .items files have been loaded any Items referenced in the Rule will be UnDefType (I think that is right). If a Rule is running and persistence has yet to load and initialize the Items those Items will be Uninitialized in the rule. If the Rule tries to sendCommand/postUpdate to an UnDefType you will see an error. If it does so for an Uninitialized Item the Item will take on the new state, and as you saw in the code, persistence, when it does catch up, will not restoreOnStartup that Item.
You can somewhat control this by changing the polling periods for the various directories so the rules get loaded after the items and persistence. These are the “folder” options near the top of openhab.cfg. Set “folder:rules=##,rules” where ## is a number to some number value larger than items and persistence.
The problem is all the different files are loaded in parallel. By changing the file polling period what you are essentially making it deterministic by timing the loading of the various file types so, for example, items get loaded before persistence which gets loaded before the rules.
