Dynamic things: Generate XML at build time, or create at binding load time?

I’m working, slowly, on an OH2.0 Insteon binding. Yay! The OH1 binding was written by Bernd Pfrommer to use a lot of data-driven constructs, such as the list of known Insteon devices, and the features those devices offer. It is very nicely done, and he did an excellent job of keeping the logic and interface separate. Much of the code to handle the complex Insteon protocol ports very cleanly.

Being an OH1 binding, the current insteonplm knows nothing about Things. It maps items directly to channels. To be an effective OH2 binding, insteonplm needs to define the Things that the PLM bridge can connect to.

The V2 binding needs to define all the items in that XML file as Thing types. I see several ways to do this:

1> When the binding loads, read the XML and insert new thing types into the system to match the items in the XML file. Possibly remove the thing types when the binding unloads.

2> Use a tool at build time to read the XML file and write new static XML files for the thing definitions. OH will manage those things via the normal XML methods.

3> Maintain the Thing definition XML files independently of the Insteon definition XML files.

Right now, the Insteon definition XML files are stored in the jar file, and updating them is technically possible without a new release of the code, but normally this would be done by releasing a new version of the jar file built with the new XML files. If the XML files were stored externally, and easily replaced or updated without rebuilding the jar file, I would be leaning heavily towards option #1 so that the XML could be updated by the end user. However, the files are stored in the jar, and most users won’t feel comfortable manually updating the contents of the jar file.

Option 2 seems plausible to me, but I have no idea how to get OH’s build tools to automate it. Were this standard Makefiles, I would jump on this in a moment, but Maven is a scary unknown to me, and I’m already sinking in the learning curve.

Frankly, I’m probably going to start with Option 3, so I can keep moving. Either of options 1 or 2 can be added later to make maintenance and updates easier. Option 3 lets me write some XML and have things to put in the system to begin testing with, and lets me manually play with the ideas of how the Insteon feature definition file maps to things and channels.

Other binding developers: Which do you think makes the most sense?

Binding users: Do you care, as long as it works?

Anyone have any thoughts?

Is this a requirement from your binding? Or do you think this is a requirement from the system?

OH2 does not require an XML file at all - well - it does require some, but the definition of the thing type can be completely dynamic.

This is not required. You can “simply” define your thing dynamically. You have a simple XML file that has no channels, and then you can dynamically add channels. This is how the ZigBee binding works - it interrogates the device, and builds the channels based on the services it finds in the device. There is only 1* XML to worry about here.

  • I lie slightly - there is actually more than 1 XML if you go looking as the ZigBee binding also allows devices to be statically defined where the interrogation doesn’t work. This can happen if there are non-standard features (ie outside of the ZigBee specification) that need to be worked around manually.

In this way the binding supports most ZigBee devices without any definition in XML, and we only have about 5 statically defined devices.

1 Like

I’m sorry I wasn’t clear. When I said, “The V2 binding needs to define all the items in that XML file as Thing types”, I meant the XML file the binding uses internally to define all the Insteon devices it knows how to interface with.

My question boiled down to, “I have a list of all the devices the binding can communicate with defined in a binding-specific XML file. What is the best way to turn that list into Things for OH to use?”

I can create Things dynamically at load time, or I can generate the Thing definitions as XML at build time, or I can just maintain Thing definitions in XML by hand.

It sounds like you’re suggesting the dynamic creation is the best solution. It probably is in the long run.

Would the Zigbee driver be a good place to look at as an example, or are you aware of a clearer one? I’ll have a look at Zigbee and see if I can tease apart what it’s doing.

Isn’t that list defined in the binding already? If you are defining the devices manually, then just manually add them to the binding - that’s what most bindings do.

The ZWave binding uses a database as there are over 1000 things. This database automatically generates the XML files for inclusion in the binding.

So, I guess this provides two extremes for either generating thousands of XML files automatically from a static source, or generating the things completely dynamically and not using XML files.

I don’t know the binding, or the types of devices it supports. The advantage of the dynamic creation is that there is no need to create the XML files when a new device comes on the market. Of course it’s only any use if the system provides a means to automatically detect all the services that a device supports. I don’t know if that’s the case here?

I’m sure there must be other bindings doing this, but I’m not aware of one - sorry.

Sadly, an Insteon device only gives you it’s Insteon address (think mac address) and, USUALLY a device type ID. That doesn’t even always work. An unknown device type ID is a black box we know nothing about and have no idea what messages it will support. When new devices are released, we have to add them manually to the list in the binding.

The Insteon market is fairly stable now, and this doesn’t happen frequently like it does with ZWave, but it still does need doing.

There are not thousands of Insteon items; there are more likely dozens.

1 Like

This is interesting to me, as I’ve finally gotten the insteonplm binding to a point where it would be really helpful to have all the thing types defined.

I looked at the Zigbee binding, and think I found where you do it. You seem to have one generic object which you create and then update for that specific thing’s requirements, as queried by Zigbee.

I was expecting to pre-create all the ThingTypes for the possible Inseton things I know how to manage so that you could select them from the list when adding them in PaperUI. Until I get discovery working - and maybe even past that because Inseton may not be entirely discoverable - having that complete list in place for the user to select from would be helpful.

I’ve found docs on how to update a Thing, but not how to add or update a ThingType. Do you (or anyone reading) know where I can learn how to do that?

Also, I haven’t found the best place to create those ThingTypes… is there the equivalent of initialized() for the binding as a whole?