Is it possible to replace all the items files defining the items in OH, with items defined in script files? I’m not thinking about adding them to ManagedItemRegistry, rather implementing my own ItemProvider in script. This way I can provide all my items, and parameterise their definition as I like. Has anyone done this? Any reason why it shouldn’t work?
– background below, reading not required… –
I have quite a few items in my OH instance, and there are many patterns - such as I have lots of coloured lights which are all fronted by a proxy item to decide the colour based on the time of day. I found early on that I hated to copy-paste item definitions and tweak them for each piece of hardware. At this point what I decided to do was to generate most of my items’ defintions - I just created a simple piece of code that took a list of hardware and generated (the bulk of) my items files. This has served me well, but has also led to the need to generate rules files when I want rules that operate on sets of items.
I have recently ported all my rules over to scripted automation, and used metadata in a number of places for ‘related’ items. The current set of scripted rules feel waaay less ‘hacky’ that what I started out with, and is much simpler to understand what is going on. The last remaining piece of my system which now feels ‘hacky’ is the item generation. Not because the items are generated, but because this is additional code that runs outside OH, in a different environment, uses different syntax (JS + Handlebars), operates on text, etc.
Absolutely. The original core.items module did not use a managed provider. I changed that, but plan to make it an option. The OpenWeatherMap script in Community adds the ~700 Items available in the binding. I also put some code together to pull all of the default Item definitions from a Things Channels and then create the Item’s, like autolinking does. I’m also prepping a core.things module which could be used in a similar way to script your Thing creation.
I’m following you up to this point. If you can generate the rules files in the first place, why can’t you just write one generic Rule and apply that Rule to your new Items via Group membership or dynamically generated Rule triggers?
I’ll add a use case for this to the ones that Scott mentioned. I use this to create temporary Items I use in the tests (I hesitate to call them unit tests) that I’ve submitted with some of my Community library submissions. I’m additionally toying with the idea in a couple of other areas as well (e.g. generic implementation of the Manual Trigger Detection DP).
I’m kind of ambivalent about the concept over all. I’m a firm believer that the Items are the model of your home automation. As such, you as the creator of your home automation should understand each and every Item and it’s context. When you have Items automatically created it’s hard for the home automation developer to know and understand the model. On the other hand, especially with flags and proxy items and the like, does the user really need to to know much about them to understand the model?
I suspect that I could have used groups rather than generated the rules themselves, I just wasn’t aware at the time that it was possible. One example I had is that all my coloured lights have both a real and proxy item (both generated), and I also generated associated rules to wire them together. I think it’s possible to do this with a group as a rule trigger, and convention to located the target item from the proxy.
I agree with you about the items forming the model. My plan is simply to be able to declare all my items in one (or a few) JS files. This way I can easily template certain types of item. For example I have a number of items that are tasmota-flashed esp8266 devices. For me these translate to 3 items each (a switch/relay, a reachability item, an RSSI item) plus a thing definition to hook up MQTT. Currently I generate these definitions based on: the mqtt id and the name/context (with optional groups too). It means adding a new device of the same type is trivial, and also making a change across all instances of a device type is too.
If I move this into JS, I can write a ‘TasmotaDevice’ class which supplies a set of items and things, and get essentially the same behaviour with simpler code. I can also more heavily use inheritance too, as I have some 4-relay tasmota devices, and I have various types of Xiaomi sensors all of which report battery in the same way etc. (I do actually do some of this now, by including common templates inside other templates, but it gets confusing…)
Actually, on the point of maybe not actually needing generation for rules, this has made me think about my sitemap: this currently has a load of generated pieces in it. Generally the solution should be the same as rules: use groups, but there’s very little flexibility when displaying a group of items on a sitemap. I guess that providing a sitemap in scripts will be where I end up heading next…!
