I have spent quite some time on creating some kind of structure to my openHAB setup in terms of how I define items, rules, sitemaps, etc.
One important part of this is to have multiple .items files where I keep items that are in some way related.
Apart from the general reasons for doing such a split (e.g. avoiding huge files, make it easier to locate things, etc.) I have until now been under the impression that it also made sense from an openHAB-perspective.
By this I mean that when you modify an .items file and it is reloaded the items go back to their “undefined/uninitialized” state and it may take some time for the system to reach a normalized state again. My thinking was that by splitting items over multiple files, lesser parts of the system would be impacted by a modification to one of the files.
However, while debugging some other issues I had to disable “restoreOnStartup” for a period, and then I started to see some strange behavior. Digging in, I suddenly realized that my assumptions were all wrong! It turns out that whichever of my 10 .items file that I modify, when the file is reloaded all my items (from all files) are reset to “undefined/uninitialized” state!
To me this is a big issue since it basically upsets my hole system each time I do a change!
Can someone confirm that this is indeed the way openHAB works? If so, is it by design/intention or by mistake?
Cannot speak authoritatively on this, but —about a year ago I did essentially the same thing—split items into some sort of cohesive multiple ITEMS files. I gave up on it when I could not create any groups which effectively spanned those files. All Lights On in groupX etc just did not work across multiple items files. It might have just been my newness to OH at the time, but I decided I had better things to do that chase that down. Rules partitioning is much more important for maintenance purposes.
I just ran a test and I’m afraid I was unable to either confirm or deny the behavior. I have noticed that without restoreOnStartup a number of my items would get reset at midnight so perhaps that is related. However, I do have some Astro items and whenever I load that items file I’ll see “Astro scheduled something something for midnight” in the logs. I do not see that message when I edit any other Items file. Similarly I get a bunch of stuff in the logs when I touch a file with zwave items in it that don’t appear when I edit other files. Not sure what, if anything this means though re your problem. Since I’ve been running with restoreOnStartup I’ve had no problems but I try to make my rules relatively insensitive to these sort of problems so maybe I’m just lucky.
Actually there are a few issues with splitting up the files from openHAB’s perspective. The first issue is a bug which occasionally rears its ugly head during openHAB startup. Sometimes it will act like one of the rules files doesn’t exist and throw all sorts of errors and fail to load subsequent files. All sorts of elaborate workarounds have been talked about (e.g. a timer that goes off after a certain period of time and if an Item doesn’t exist touch the file it lives in). I’ve seen this on occasion but I just watch the logs during a reboot and touch the files it failed to load when the error occurs.
The other problem is that it loads each file in parallel. If you don’t set your file polling periods to different lengths openHAB will start loading all of your files. This can be a problem if it loads a rules file that refers to an item in a file that hasn’t been loaded yet. So I make sure that my polling periods have persistence load first, followed by items, then rules and finally the sitemap.
I gave up on it when I could not create any groups which effectively spanned those files.
I haven’t seriously started using groups yet, so I have not seen this problem.
Rules partitioning is much more important for maintenance purposes.
I agree that partitioning of rules is crucial, but I also think it is important to be able to do partitioning on items. In my relatively small system I already have in excess of 200 items and having all of those in one file is less than ideal.
Actually there are a few issues with splitting up the files from openHAB’s perspective. The first issue is a bug which occasionally rears its ugly head during openHAB startup. Sometimes it will act like one of the rules files doesn’t exist and throw all sorts of errors and fail to load subsequent files.
I am aware of this, although thankfully I have not really been bitten yet. [Knock on wood!] Anyway, that problem is related to .rules files only as far as I have understood. I have never seen any discussion on the same problem with multiple .items files.
Anyway, the possible issues with groups across multiple files and the actual use of multiple files versus on single file, I regard as bugs in openHAB. From a programmers perspective I really think it makes sense to be able create structure by splitting the system across multiple files (.items, .rules, .sitemaps, etc.). Just as important as the structural aspect, is the possibility to partition the system into “subsystems” that do no impact each others (unless required).
When I restart my system I am completely happy with the fact that it takes some time for the system to normalize. However, when I simply touch one isolated part of the system I would expect only the part of the system that is impacted to be affected - and not the entire system. Do you agree?
Ps! @rlkoshak How do you add the name and profile picture when you quote from another post?
From a browser (not the phone) using Chrome or FireFox (I’ve not tried other browsers) I simply highlight the text I want to quote and a gray block appears right above the highlighted text that reads " quote reply
I put the quote in with the tagging to include the name and profile pic. The above looks like:
[quote="KjetilA, post:4, topic:3167"]
Ps! @rlkoshak How do you add the name and profile picture when you quote from another post? :smile:
[/quote]
I wouldn’t say 200 items would not qualify as a small system any more . But I’m with you, I like to keep my Items partitioned the same as my rules. My strategy is to separate both Items and Rules based on what they do rather than where they are and I have one rule file and one items file for each category. For example I have:
default: stuff that doens’t fit into other categories and is too small for its own category (e.g. HVAC control)
entry: door and window sensors. Basically anything that tells me that someone has opened an entryway to the house
garage: garage door controllers
lights: controls the house lighting
network: monitors the up/down status of remote devices (Raspberry Pis) that report to openHAB and reports and rests them when they go down
presence: detects when someone is home or not
weather: gets and processes the weather info
Because I have everything broken up this way have very few groups that span Items files so I’ve not seen the behavior @bob_dickenson describes. I think I’ve defined groups that I’ve used across multiple files but didn’t really use them heavily, mainly to group things on the sitemap. But what I did do seemed to work. I also have everything that could impact the behavior of my rules restoreOnStartup so I’ve not noticed the behavior you describe either. If everything is getting rest when one file updates I don’t notice it because restoreOnStartup kicks in before the rules can trigger. I guess I’ve been lucky.
I actually wasn’t happy with that. I wanted my system startup to be as deterministic as possible so maybe that is why I haven’t noticed these problems.
I’m tempted to experiment and try to suss out what is going on here. There just are not enough hours in the day.
For me, when I started using groups, particular using them in my rules, that was the point where I started to really understand openHAB. If you find your rules to be long and overly complicated and you feel like you are doing things that are clearly awkward, consider using groups with foreach or filter. I’ve dropped my lines of code in my rules by more than 50% and gone from about a dozen lambdas to three simply by using groups.
Mostly FYI – I encountered that problem with multiple ITEMS files pre-1.7, so it might be resolved.
AFAIR the fundamental manifestation was a namespace issue for groups–i.e., I could not define a group which spanned more than one .ITEMS file. If I defined the group in one ITEMS file and tried to make an item in another ITEMS file a member of that group, it would not do so. If I defined the same group name in both files, they manifested as two different instances of the group name.
Again this was pre-1.7 and I have not re-tested.
Your partitioning of items/rules makes sense from technical subsystem level, although does make it harder to get common view of all subsystems manifested in a particular area of your home. I went the other way when I tried this pre-1.7 and did ITEMS and RULES by area of home to get more unified view of “what’s happening here”. Either way is reasonable. I ran into trouble with multiple ITEMS files where (for example), I’d have Living Room ITEMS in one file and Dining Room in another ITEMS files, and needed a combined “First Floor Lights” group. Could not get a common group definition to work which spanned both ITEMS files.
I think the problem may have been fixed. When I first started with OH it was version 1.7 I had some gross that spanned items files and when I put the group on the sitemap it showed then all.
I only use my sitemap for debug purposes. Almost everything just happens. In the rare cases where I do need to activate it deactivate something I do so through IFTTT Do buttons or Tasker (e.g. when I approach the house a dialog pops up skating if I want to open the garage). So the functional split still makes sense for me.
I have the same issue. Have not added persistence yet, so see the full effects off this. Many of my items rarely (or almost never) change, such as electricity supervision. I guess persistence is the “solution”.
There was an open issue only covering the NTP binding, even though it actually is a general issue.
I suffered last evening from this issue (and maybe long time before as well). I reloaded one items-file (for mysensors nodes) and the item IsNight (which is not covered from the reloaded items-file) switched to uninitialized. I monitor some of my items, because of some kind of bug fixing in my rules. Therefore I could find out this behaviour.
Would a restoreOnStartup solve this issue? I’m asking as this is not really a startup, when a items-file is reloaded.
How can I solve this uninitialized items in this case?
Rich had a nice explanation for that but I can’t find the thread right now. In short: this is the only way you can have more than one item file in openHAB. All items (in all items files) need to get reloaded if you change a single item file.
Yes, I’ve setup influxdb persistence and a restoreOnStartup in my persistence file and don’t have that problem.
This is because of Groups. You can have an Item be a member of a Group defined in a separate file. But the only way to make all the Group memberships correct is to reload all of the Items.
No, because you could have changed the membership of that Group in those other files and the Groups would need to be initialized with the new memberships as a result.
