I created a rules file for every Room. (z.B.: Office.rules, Kitchen.rules)
I build in some buttons with different actions, depending on the time, the button was pressed.
These times I want to setup in a global file, and use this setting in every rule.
Definition of constants:
val int TIME_1 = 5
val int TIME_2 = 10
An example of the block, I use in multiple files:
var Timer timer1 = null
var Timer timer2 = null
Item input changed from OFF to ON
timer1 = null
timer2 = null
I don’t think creating Items for every value is not the right way, cause I want to enshure these values are not overwritten by the users. I don’t want to create these constants in every file, cause if I repair a failure, I have to fix multiple files.
In the past, I have also used either variables defined within a rule, or Items containing ‘Parameters’.
I wasn’t super keen on either approach, as I didn’t want a huge number of items for just storing values, and in my case, I also preferred not to use variables, as I would prefer such a simple change not to require scripting changes (sometime across multiple rules)…
So lately, I have started using Custom NameSpace MetaData to store such values within an item (but not the item value itself). Some benefits are:
Its value cannot be set by a user, unless they are logged in as an Admin (Well - I’m reasonably sure they cannot!!)
Its value CAN be set via the Admin UI (Or via a script as well if you wish)
It’s non-volatile, so survives a reboot, without needing any persistence-service ‘restore on startup’ (unlike an item value)
Multiple Metadata Fields can be set within the context of an item
The latest scripts I have written, start using this approach, and seem to work well so-far. It lends itself well to Generic scripts, working with different items, each storing their own value
So in ECMA2021, getting a value from MetaData is as easy as:
Whilst I started going down this route (updating MetaData from scripts etc), I quickly realised I was trying to solve a problem I didn’t yet have !!
For my requirements, I now think in a analogous fashion to an Alarm system configuration, which has a user-mode, and installer mode in the control panel:
The type of settings which would only be available/configurable in ‘Installer Mode’ in an alarm (e.g. Entry Delay, Exit Delay, Zone Setting Flags), are the kinds of settings I would store in Custom Namespace MetaData - They should not need to be changed frequently, and if doing so, a bit of thought should be applied. I think of ‘Admin mode’ in the OpenHAB UI as being similar to Installer Mode in the alarm
Other settings which should be user controllable, I am using Item values, with every-change/restore-on-startup persistence, and these can easily be displayed/controlled via Main UI pages
Again, this suits my current use-cases, but there is no one-size-fits-all in OpenHAB, right?
You don’t need to show them to your users. There is a visibility flag on Items that you can set the Item to be hidden from regular users. It’s not a security measure but unless you have some particularly crafty and malicious users in your home, they aren’t going to be issuing REST API requests to change things.
Is there an if there somewhere? There’s no logic to do something different at different times of day in this example. I’ll assume it’s there and just not represented in this redacted example.
This might be the root cause of your issue. If you are using file based configs, it’s rarely the case where organizing everything by location makes sense. You will have lights in most of the rooms. The lights will behave similarly in most of the rooms. If you split this logic up between multiple files you end up smearing your logic across lots of files which results in lots of duplication.
If you organize based on function then similar logic ends up being colocated in the same file and this problem largely disappears. Have some logic or constants that are shared by all your lights? Well if all the lighting logic is in the same file you can make them global variables and reuse them across all your rooms because all the lighting rules are in the same file.
Therefore, even as far back as OH 1.6 I’ve always recommended organizing your files based on functionality, not location. That ensures that the rules that are similar to each other are colocated in the same file, allowing for more opportunity to reuse.
The fact that you have many rules with the same “block” of code in multiple files is a code smell. It is a further indication that your current organization is not ideal. If these were in the same file would you need to duplicate that same block of code over and over? Maybe you could use a global lambda instead. Maybe you could just have the one rule to handle the lights in all the rooms.
Not in Rules DSL. You can in any other rules language including Blockly.