Since editing item files mostly (if not only?) leads to problems, could it be a suggestion to deactivate/ignore the “filesystem event” for item files? Especially since the new VS editor is dependent on a “live” system for syntax check (if I’m not mistaken) ?
That way we can edit item files but they won’t register until next restart/reboot as we have to anyways…
What problems?
Besides the error complaining about an empty file just before successfully loading the file what problems are you encountering?
I doubt it. I suspect if anything changes it will first be to let us prevent the rules files from loading and running before all the items files have been loaded. That is a problem that you will see at OH startup though, not when modifying .items files.
That is correct. There is a server port on OH that VSCode uses to check the syntax.
Well, since I started using OH 1.6 I’ve always restarted OH after editing items files because the system seems to become unstable (rules not working/not triggering or timers not working and so on…), This seemed to also be the case after I migrated to OH2. Am I mistaken? Is it only me?
Your experience is yours and cannot be mistaken. However, there are very few reports of this sort of behavior and it is incorrect behavior. Far better to fix the actual problem and have OH work correctly than apply band-aids and work arounds that treat the symptom rather than addressing the problem.
I’ve used OH nearly as long as you and I’ve never restarted OH after editing items files. For a brief period, I had to restart when I made changes to Groups but I’m not sure that is a problem anymore; I don’t edit Groups that frequently. But I’ve never had problems with rules stopping working and timers not working after editing .items files. My problem was Items added to or removed from a Group did not get reflected in the Group until a restart.
And I can say based on my support on this forum, the vast majority of users also do not restart OH after editing .items files.
So, given you are experiencing problems, it would be better to fully describe the problem and under what circumstances the problem occurs and fix that. As designed and as most users use it, you should be able to edit .items files without restarting OH.
Hmh, I’ve could’ve sworn I’ve seen other people mentioning this on the forums as well…though I don’t have any examples. Oh well, I’ll try editing items files in the future and report any issue I see 
There have certainly been reports of people having rules not trigger and other similar types of problems, but none of them to my recollection were related to editing items files. Recently the problem people are reporting has to do with cron triggers.
Finally, I will say that it is possible that changing .items files can cause problems in rule, but in this case it is because the rules are not able to handle all the Items becoming NULL or rules start to trigger before certain Items have valid states (I’ve not seen this myself but have seen it reported). This can usually be handled with some simple error checking in Rules or tweaking the triggers on Rules (e.g. changing from received update to changed from OFF to ON so the rule doesn’t trigger when the Item goes from NULL to the restoreOnStartup state).
You’re probably making the false assumption that OH is ‘instable’ because you don’t understand what’s happening.
First, you shouldn’t edit items and rules files directly on disk because every save can cause rules to be reloaded (recompiled, effectively - uses a lot of CPU). More or less the same happens when you save items files, this requires even more processing. Now there’s people to save every minute’s work, causing permanent reloads (they’re queued !). This is leading to (at least) a ‘laggy’ system experience, and - in case the syntax is incorrect - even to OH misbehavior.
Second, there’s a bug to cause UI hangs while rules/items are reloaded (may be misinterpreted as ‘unstable’, too).
Said bug is expected to be fixed in the next snapshot.
You can stop editing files in place (i.e. create a copy elsewhere and only copy it back when you’re done)
EDIT: recommendation to edit services/runtime.cfg to change frequency of scans for updates removed.
When was this added? I missed that the polling times were added back. I assume it was added during the latest inclusion of ESH Kai announced a few days ago?
This is pretty exciting news as it has caused lots of people lots of problems.
Though, wouldn’t this set of times cause problem with Rules being loaded before Items? If one has System started and/or cron triggered Rules it seems possible that the Rules will fail because the Items don’t exist yet, or do these times only apply to how frequently OH polls the folders after the first loading?
Actually, OP was asking to completely turn off polling and automatic loading of .items files. He does not want the .items files to be loaded except when OH starts.
Ouch. No there’s no recent addition I’m aware of.
Then seems I actually missed it was removed ? So let me reverse the question: Are you sure it was removed - and when ? 
Well, that is still happening every day (at startup time), although in operation, to change items seems to trigger
an update (or sync or whatever) on rules, too, at least my standard log level keeps spitting log messages telling me so. And that part is working for me, at least not that I’m aware of current problems with it.
I also have loads of items (>600 right now) and loads of rules (didn’t count them) and a bunch of things. I only use item-based configuration (nothing in PaperUI) - and I never experience not triggering rules (if I set the trigger correctly that is! 
).
What I do experience is what Makrus mentioned: If I change items or rules (or both), the system becames slow for a time until everything is reloaded/recalculated and stuff. But I bet, if I delay reloading configuration and restarted OH everytime it would be … boring!
I’ve always been under the impression that when OH 2 came out it no longer did polling for files and instead depended upon file events (hence the errors one sees when editing over SAMBA, for example). and the polling parameters have never been applicable to OH 2.
I can’t remember where that impression came from, but the above posting is the first hint I’ve seen that there is adjustable polling periods for the config files. There should be a things entry as well, right? I used to use changes to the polling periods in OH 1.x to deal with the startup problem with Rules running before Items load by setting the Rules period so it is long enough past the Items polling period that the Items finished loading before Rules started. I do remember looking in to whether the same was supported in OH 2 and came to the conclusion at the time that it was not supported. Maybe I was wrong?
Just checked. Rich you’re right any config file changes has instantaneous effect (rules getting reprocessed).
Didn’t find out since when but likely OH2/Karaf introduction.
So forget about my comment to tweak runtime.cfg, it doesn’t work (doesn’t override) that default behavior.