I’m currently writing code to allow me to set up my devices, with predefined things and items for each device. For example, I have a number of ESP8266 devices running Tasmota. Each of these has one Thing, with 3 channels (switch/reachable/rssi) and corresponding items. I plan to have a single statement to set up a single device.
My question is, what should I call the class that sets up and is specific to the device? Is it a ‘Thing’, because I thought that things corresponded to real-world items? Or is it a ‘ThingWithItems’? Or is it something else, like a ‘Device’?
Are you looking for a name for the class that generates these items? To me that seems like it wouldn’t be an instanced class. For that I would just have a script file than runs early in the load sequence that checks for a single item (reachable let’s say) and then creates the remaining support items (rssi in your case) and things (reachable and rssi MQTT thing channels) if they don’t exist. No need for a class as all other interaction is done through openhab.
I am planning on doing this same thing for my Espurna devices when I have the time. I will come back here and post my code when I do.
I would avoid naming stuff in your scripts in a way that make them look like something that has a definite meaning in openHAB. So something like TasmotaThingItemGenerator (yuck) or at least something that indicates what the class/script does. The Object isn’t a Thing nor an Item, it generates Things and Items. That would avoid confusion better I think.
A class that generates Items and Links for all Channels of a Thing… hmmm. Sounds like the autolinking functionality in ThingLinkManager, but without Simple Mode enabled and just for a specific Thing. This is just what I have implemented in a core.things module (mentioned here and here). There’s no class to name… just an add_thing function with an argument to enable/disable autolinking.
In case it’s not known to others, Jonathan is using JavaScript.
Thanks! I think it is mostly auto-linking, yes. Although I’ve never used that so I’ll take a look. Hopefully most of this already exists!
Also what is the difference between item metadata (which can be declared as { key=“value” }) and linking, which is declared the same way (e.g. with a key of channel for mqtt)? Do links simply create the correct metadata? When I looked at the code that provides items from .items files, it supplies both an ItemProvider and a MetadataProvider.
I’ve not delved drop into this but it appears that reach party of oh gets a shot at the metadata and if it finds something that’s relevant it gets the config instead of metadata.
For example, I learned making the expire binding drop in replacement that if you have the expire binding installed, the expire config doesn’t already in metadata. Remove the binding and all of those configs will appear as metadata.
I think an entry there only becomes metadata when something else like the linker it a 1.x binding doesn’t consume it first.
So it’s actually a bit the opposite. Links don’t create metadata, metadata creates links. And this is all only relevant for .items file defined Items. When establishing links through the rest api, it goes straight to the link registry and gets saved out to the links jsondb file. Metadata is never even involved.
Note, the above is based on observation, I’ve not looked at the code itself.
Ah, yes. That makes sense. It’s been long enough since I’ve done it and I was dining a lot of other stuff at the same time. I don’t remember it but I’m certain I penalty had to restart too.
BTW from all the responses in this thread, I think that @rlkoshak is the only answer (yuck as it is) that actually satisfies what I’m doing here, which is define things and items at the same time.
Here is a piece of sample definition, which creates 2 things, 6 items, and the links between them (+ some metadata):
let homeDevices = [
new TasmotaDevice({ name: "bedroom 1 light", mqttId: 'bedroom-1' }),
new TasmotaDevice({ name: "bedroom 2 light", mqttId: 'bedroom-2' })
];
I plan to change the ‘TasmotaDevice’ class to ‘TasmotaThingWithItems’ or something. Nasty.
FYI I found that while most osgi services worked fine from within a script, ItemLinks did not, if they were registered via the automation.script bundle. I had to dig a bit to figure out that osgi does not appear to like exposing a service from one bundle to another if the exposer doesn’t declare a dependency on the bundle consuming the service. Dynamic imports don’t count (which is where this dependency arises). I solved this by providing an explicit bundlecontext as a scriptExtension, rather than having scripts uses FrameworkUtil to locate a bundlecontext via a class from the automation.script bundle . It’s probably worth pushing more osgi-related code into a scriptExtension; this doesn’t seem like logic that belongs in script modules.
