Was just wondering how you guys set up your structure in your openHAB files.
I’m looking for input to ease up the way to locate things by providing myself the best structure (I know this will be very different from person to person, but although I’m interesting in hearing your ideas and learnings).
Right now I have the .items, .things, .rules, which are the main ones I use at the moment.
So the way I’ve done it is to create a file for every product I have like xiaomi.items, xiaomi.things, xiaomi.rules.
So here are a few examples of how I did it:
//This is the items xiaomi.items file
//Garden
---> Here goes all the items that are being used in the Garden
//Livingroom
--> Here goes all the items that are being used in the Livingroom
I do also have a dummy.items file, where I put in dummy switches that are not directly linked to any products/units, but I still use the same structure as above, to separate them by rooms.
For the rules file xiaomi.rules I’ve then done it like this:
//This is the Rules file:
//Overall
--> Used if the xiaomi product is being used across rooms etc.
//Garden
--> Here goes all the rules that interacts with my xiaomi products in the Garden
//Livingroom
--> Here goes all the rules that interacts with my xiaomi products in the Livingroom
I’ve gone for many small files.
Items -
rooms.hallway.items
rooms.livingroom.front.items
rooms.livingroom.rear.items
rooms.child name.items
…
rooms.kitchen.items
rooms.kitchen.utility.items (its a room in a room)
Rules are by function
cron.garden.pool.rules
…
state.house.scene.rules
helper.proxy.solar.rules
Etc
Many small files makes editing and auditing easier.
general.items (odd things, nethealth, intruder alarm etc.)
lights.items (lighting controls and feedback)
motion.items (PIR and breakbeam sensing)
alarm.rules (manage response to alarm activity)
lights.rules (rules to manage lights e.g. timeouts, dusk-dawn)
motion.rules (to manage occupation sensing and light triggering)
… etc
My rules are fairly modular e.g. a rule manages sensing to determine area occupancy, and hands off a trigger to a separate rule to work lighting if required (dark), duration, rescheduling.
I used to use a lot of lambda functions for shared code, which is a pain as it does not share across split rule files.
But with the new Group-trigger capability from OH2.3 I am rewriting in a much neater way.
I do my items by product, or more accurately binding (zwave.items, zigbee.items, insteon.items, astro.items, alexa.items, etc) but my rules by function (motion.rules, alerts.rules, etc) because there’s crossover between items within my rules like “Lights on at sunset” which triggers zwave, zigbee, and insteon devices based on astro item status so it seemed most logical to go by function vs product for rules for ease of management.
I organize everything by function. Ultimately outside of Things (and Items for 1.x bindings) OH doesn’t and shouldn’t care who made the device or what binding is being used to connect to the device so I see no need nor any benefit to splitting files by anything other than location or function. YMMV.
And as rossko57 mentioned, there is a higher likelihood that common stuff that needs to be near a shared resource like lambdas will be colocated. So I split everything up by function except for the one sitemap, though even that is spit into functional sections.
To show a case in point. Let’s say I want an alert when a battery powered device goes low. I don’t care if it’s a zwave, esp8266, zigbee it some other type of device. I only care what it is (e.g. smoke alarm). And I only want to have to look in one place to find the associated items, rules, and things for batteries. I don’t want to look to have to look in the zwave file for the zwave smoke alarms and another file for the zigbee smoke alarms.
I also have everything organised by function. heating.items, heating.rules, presence.items, presence.rules…
The groups are defined in the relevant files
I also have a main.items and main.rules where items like time_of_day and day_of_week go into…
And finally a test.items and test.rules for trying out things
Thanks everyone. Got some stuff to think about.
Of course I can also see that for some people one solution seems to fit better than others, but it def. have given me some extra thoughts :).
