What is the tradition for the items file, keep all items in one large file or can i split it into several?
I would like to have one item file for temperature ,one for lights other and one for debugging/testing. This way I can quickly test one part of items by just adding a item file , instead of always have to comment in and out items located somewhere in a huge item file.
Is there any speed concern by splitting it into several files?
How does people out there do it?
I put all my items in separate files similar to what you are proposing. I also recommend separating your rules files for the same reasons. There are concerns though:
There is a bug that some people see frequently and others see almost never that causes openHAB to throw a FileNotFound exception when loading multiple rules files. Simply touching the files or restarting openHAB will fix the problem though.
You will want to set your config file polling such that your rules get loaded after your Items files and persistence files have loaded. Because openHAB spins off a separate thread to load each file it is possible with multiple files to load some of your rules files before all of your items files have loaded. If any of those rules execute during that time they may fail with a UnDefined Item error. I put 5 seconds between my items and persistence files and the rules file.
I personally haven’t seen this but I’ve seen others report that a Group defined in one items file will not be accessible to Items in other files. Because I separate all my items based on function I’ve yet to need to have a Group span files so I don’t know this limitation is still true.
Variables (vars and vals) defined in one rules file will only be accessible from that one rules file.
This is a growing pet peeve of mine. A lot of people are very concerned with speed when it comes to openHAB. Besides not really defining what they mean (processor speed? message delivery latency? action response times? etc.) I can think of very very few cases (GUI action to device response being one of the big ones) where even having a delay of seconds really amounts to any practical difference in home automation. And even a first generation Raspberry Pi is powerful enough to run openHAB with 100 msec or less response times most of the time.
So don’t worry about speed with openHAB until you really do hit a problem. And if you do hit a problem, the solution may be to not use openHAB for that part.
But to answer your question, at the most in the worse case scenario it could take a few extra seconds for openHAB to start up if you split your rules and items into lots of separate files. Once loaded there will be no noticeable difference in performance.
This is my approach as well (currently running at ~20 .items file, ~20 .rules files and ~20 .sitemap files). To me, splitting things into different files, is key to creating structure in the system.
I am occasionally seeing the FileNotFound problem you mention above, but not very often so it is managable.
There is one thing worth mentioning, though:
One of the reasons for splitting my items into multiple files, was to be able to work on parts of the system (i.e. modifying the files) without affecting the rest of the system. For quite some time I actually thought I had acheived this goal, but then I started seeing anomalies, and I did some “research”.
As it turns out, based on empirical data as well as code review, when you modify an .items file and openHAB detects that it has changed, ALL .items files are re-read!
To me this is a big concern, and I simply cannot understand why it is implemented this way.
One of the reasons I can think of is group configuration. I have groups in a separate items file because I have groups that cross many items types and files. If I mess with groups in one of the items files, it will or could affect how other items files behave. The only way to have consistency is to load everything again to make sure.
I have now started splitting the items in multiple files, will let you know how it goes.
Fair point! I did not think of that since I am not using groups in my setup at the moment.
I guess this could have been solved by some kind of “dependency resolver”, but it would likely be quite complex, so it is definitely easier to simply re-load all files.
You are able to use Groups across multiple item files ? for me somehow group in one file is not recognized in another 
… i created Group:Switch in separate item file and it didnt work.
I am also splitting up my items and rules for different parts of my system (heating, lighting, sonos, kodi, …).
Yes. that’s the case. I did not quite understand your problem.
On the other side I always stayed with only exactly one sitemap containing everything important to me cascaded. What are you using 20 sitemaps for? 
What’s your use case? How do you browse them / switch between them?
I agree that using 20+ sitemaps may seem a bit execssive, 
I should point out that I very much subscribe to one of @rlkoshak’s mantras: Home automation should just work without any (or at least significant) user involvment.
From this it follows that I really only have one (very limited) sitemap that I use on a regular basis. This gives me a sort of condensed overview of the system - some information points that I find important and take a look at on a regular basis.
All the rest of the sitemaps are there solely for maintenance/debugging purposes and thus are focused on providing as much details as possible for given parts of the system.
I have also choosen to have some sitemaps that focus on systems (or rather bindings), e.g. one for Z-Wave devices, one for network devices, one for DYI devices (interfaced through MQTT), etc.
… and other sitemaps that are focused on functionalitites, e.g. ligthing, security, presence, appliances, etc.
When it comes to navigating between them, I really don’t. I have simply given them sensible names, and added them as favorites in my web browser,
This describes a lot and actually sounds pretty similar to the idea behind my setup. I have one nurtured and condensed view on the important parts of my system but with more details in the background. One example is the speedtest integration I presented a few months ago. As you can see, there is a nested menu for it but only one summarized line on the main sitemap.
Besides providing a nice sitemap, which I still find pretty important, my home automation is also aimed at “automation”, without the need of user interaction.
Instead of additional sitemaps, I have this one last line in my one sitemap:
sitemap ... {
....
....
Group item=Whg label="Alle Elemente" icon="house"
}
With “Whg” being my all containing group 
That is correct. For all the groups I have for v1.9 bindings, they are in a single groups.items file. They group things horizontally if you think of the bindings as verticals.
As an example, I have denon.items, and insteon.items so that a binding has an items file for those things that the binding controls, but I have a group basement that comprises elements from both insteon and denon items files. This is then how I feed my sitemap. My sitemap is based almost entirely on groups so that the sitemap itself changes dynamically as devices in the group come and go.
I do the same with groups for 2.x inside of MapDB. Groups are functional areas that feed the sitemap.
Hope this helps.
yes this helps, i am trying to implement almost the same structure … thanks
I’ve tried to setup multiple Items files, and made one only for the Groups… But it seems like it doesn’t work.
I’ve made an item that takes the average of 4 sensors - this doesn’t work when the Group is put in another file than the Item is in…
If i put the group in the same item file where the items is it works…
Is there a workaround for this?
This should work but I’ve been seeing some inconsistent behavior with Groups in OH 2. Perhaps this is related. I don’t have a work around. All I can say is it appears to work for me right now but I couldn’t tell you why.
Okay… then i must try again to move the group stuff around a bit… Would be smart to have Groups in a single file…
It depends. I have my groups spread all over my files. With just a couple of exceptions having to do with persistence and keeping track of the online status of my sensors, all my groups are specific to one function (e.g. lighting). Since I split my Items and Rules up by function the Groups and the Items that are members of that Group naturally fall into the same files anyway.
But like I said, there are exceptions where Items are members of Groups defined in other files. And for me those appear to work so it should be possible. I can’t say why it isn’t for you.
I’ve been an advocate for this sort of organization because I’ve found it solves a lot of problems. In addition to having Groups located in the same file as its members, I don’t have to worry about copying lambdas into multiple files because all the rules that need that lambda are already colocated. It also makes it easier to find opportunities for simplifying and merging rules because it is easier for me at least to notice patterns when the rules are in the same file. YMMV.
@Rasmus7700 - how about ensuring your item file that contains all the groups loads before rest of Item files ?
That could be something… But… how to ensure that, as i can read OH2 just loads them randomly?
I have this issue that a rule is being run before the Thing has become online. What file do ypu specify this 5 seconds in?
You would have to post your rule and Items.
The five seconds referred to is related to OH 1.x and not applicable to OH 2.