One things / items file or many?

[aksnet (Andreas Kuhn)]

Hi Guys,
i may have overlooked it in the doc or it’s not clear enough, so i’m asking here.
Currently i have 1 things and 1 items file with everything in it. When i do any modification on these files OH seems to drop everything and starts adding the things and items again, which will result in an initialize status for some components, mainly homematic.

Would it make sense and is it supportes to split, lets say each thing into a own things file and so for related items as well. So my hope is by splitting them only the parts in the file that was modificated will be affected.

Thanks
Andreas

[hmerk (Hans-Jörg Merk)]

You are not limited to one file of each type, but I don’t think it’s a good idea to have one file for every thing or item.
Is there any special need for having your things managed in files instead of using PaperUI with json storage?

[aksnet (Andreas Kuhn)]

Hi Hans-Jörg,
thanks for the fast feeback.
When i started with OH i was using PaperUI for 100%, but i am used to work with the console and config files, so i migrated first all items into 1 items file and then all things in 1 items file.
I am much faster wirh changes that way, i wished i could modify my HABPanel directly via a file. Would save me a lot of time.

And migrating all into files was a good lesson, so i had to read all binding docs etc

[hmerk (Hans-Jörg Merk)]

Hi Andreas,
I agree according to the items, but don’t see the benefit for things.
If you need to edit a thing, you still can do this outside PaperUI, as the JSON storage files are human readable and editable.

[michael_sutter]

Hello @aksnet

I’ve grouped my rules and items on files.
Items mainly targeting to bindings and rules targeting types (light, shutter, and heating…)

With this I reduced the initial action to a minimum.

[aksnet (Andreas Kuhn)]

Hello @hmerk ,
hmm i didn’t know yet that the PaperUI relies on simple files, i thought it’s some sort of DB.
Were would i find this(these) files of PaperUI?

[KjetilA (Kjetil Asdal)]

@aksnet

So my hope is by splitting them only the parts in the file that was modificated will be affected.

This was my hope as well, and one of the reasons for splitting my system into multiple item-files (the other being purely structural). Sadly it appears that splitting into multiple item-files does not change the situation, and that when reloading an item file, all items across the system are re-initialized. At least based on my experience.

[job (Joachim Boeddeker)]

@aksnet

hmm i didn’t know yet that the PaperUI relies on simple files, i thought it’s some sort of DB.
Were would i find this(these) files of PaperUI?

If you are using openhabian it’s in:

/var/lib/openhab2/jsondb/

[hmerk (Hans-Jörg Merk)]

@aksnet

hmm i didn’t know yet that the PaperUI relies on simple files, i thought it’s some sort of DB.
Were would i find this(these) files of PaperUI?

It is some sort of DB, but JSON-DB stores it in readable and editable files.
@job already wrote where to find the files.
Another bonus using JSON-DB - In PaperUI, you can define how many backups of the DB will be stored.

[job (Joachim Boeddeker)]

@KjetilA

and that when reloading an item file, all items across the system are re-initialized. At least based on my experience

My experience differs. I just see refreshing events for the items in the file i changed. I’m using OH2.1 stable.

[aksnet (Andreas Kuhn)]

Thanks. I may overthink the things handling again then.
Sadly that splitting the items into different files seems not result into only reloading the items included in this single file, based on what @KjetilA said as well.

Hans-Jörg, do you have more information how OH has implemented this handling? Should only a changed item file be reloaded or will OH reloads then all item files? If only the modified file should be read in again then the current behavior may be a bug ?

[spy0r (Stefan)]

openhab has to reload all items since groups have to work between different item files as well! that’s not a bug, it’s a feature

[job (Joachim Boeddeker)]

@spy0r

openhab has to reload all items since groups have to work between different item files as well!

Really all? I received about 100 state change/update events after changing a file of 12 items.
Altogether i have about 500 items configured.

Shouldn’t i have received about 500 events then?

[rlkoshak (Rich Koshak)]

@aksnet

When i do any modification on these files OH seems to drop everything and starts adding the things and items again, which will result in an initialize status for some components, mainly homematic.

This is what Persistence and restoreOnStartup is supposed to address. See:

Design Pattern: Group Based Persistence

Edit: Updated for OH 4 See Design Pattern: What is a Design Pattern and How Do I Use Them for an explanation of what a DP is and how to use them. Problem Statement There are several reasons why a home automation enthusiast would want to use openHAB persistence: charting, using historical Item states in rules logic, restore previous values on openHAB restart, detailed analysis, access to the data with external tools, etc. By default, a persistence add-on will implement a default strategy which…

[spy0r (Stefan)]

Sorry, i don’t know it exactly, that’s what i read many times here in the forums. Maybe not all of your 500 items are group related?
But that’s a core functionality, maybe @Kai can say exactly why it is like it is…

[sjka (Simon Kaufmann)]

Maybe I can shed some light on this…

Whenever a *.things file is changed, all of its things get fresh handlers - that’s why you will see them starting a new INITIALIZING phase until the (hopefully ) go ONLINE. This is I assume mainly due to the fact that it’s rather complex and error-prone to tell whether really nothing was changed as there are many direct and indirect parameters which could have an influence.

For *.items files this is easier to tell. Therefore existing items which have not been changed will be left intact. Which matches the observation that there are by far less events than items.