Hello all,
I’m developing an OH3 binding which connects to PLC and dynamically generates the whole thing structure. So far I can read out the PLC program, analyse it’s structure, create things and also chanels for them and pass label and metadata etc.
Here’s an example showing a burglar system located in the location “Security”.
My question is, if there is a way to automatically / programmatically add a location to the semantic model and also automatically “create equipment from thing” as if it was done by clicking the respective function on the UI.
In my case the PLC program has all the necessary meta data and can provide them to the binding so it could save the user a lot of configuration work if these information were reused.
IMHO this functionallity could be useful also to other bindings (i.e. in the Homematic world the components also have a location and other meta data in the CCU).
The Location in the Thing config is a vestigial property left over from OH 2’s PaperUI and is not used anywhere in OH 3 and it has nothing to do with the semantic model. There was a recent discussion about removing it, or at least removing it from the UI. It doesn’t do anything except cause confusion.
There is no way I know of to create Items from Things. In fact I think any knowledge about Items is forbidden to be used by Bindings. But maybe that is limited to Item states.
Finally, your Thing may have almost all the information it needs but not all the information it needs. It cannot predict what Item Names I want to use (and those can’t be changed after the fact). It doesn’t know what Item labels I want to use. And my semantic model might be configured in a way that is different from what you would do (e.g. I could tag my light switches as Control/Light or Switch/Light or even something else off the wall for that matter). Your binding doesn’t know that. Maybe I only want to use three of the 100+ channels that are offered (which is the case for the OWM binding). Am I stuck with your binding creating them all? And as already discussed, that Location property is not related to the Semantic Model in any way so your Thing doesn’t know where I want to put it. Your PLC controls stuff, let’s say a Light. Maybe I want to create my model using lights and not even reference the PLC at all. After all, it’s the light I care about, not the specific technology that controls the light. Maybe I want my light switches to be Points directly on the Location and not Points that are part of an Equipment.
The whole point of the semantic model is to allow us to build a human friendly representation of our home automation which in turn build up the automatic generated cards of the overview pages. And I doubt any binding can predict and support everyone in that regard.
From a usability perspective this really very much looks a lot like Simple Mode from OH 2.5 returned. The amount of time that has been spent by users and helpers on this forum undoing all the stuff that Simple Mode did was huge. And it was far more time than any time that was saved by automatically creating the Items. It’ll take a whole lot of convincing to make be stand behind bindings automatically creating Items.
And with “Create Equipment from Thing”, generating the Items is already really easy and really fast. And I could get behind the binding providing hints to that feature to provide better defaults. But everything needs to be overridable by the user prior to the Items being created.
But regardless, there is no such function available.
I’m getting the point from the perspective of Smart Homes being built based on universal devices like Hue, Shelly, etc.
My use case is indeed aiming for a “OH3 ready simple mode” We’re delivering Smart Home Solutions for new buildings; these are pre-built electrical cabinets ready to be wired. The PLC software is also pre-shipped and as I said it has almost all metadata for a default configuration of a semantic model.
In the openHAB 2.5 world we generate the whole Smart Home configuration in less than 5 Minutes: create a bridge, run autodisovery for “software defined things” with auto-approval… and the the binding even has an built-in functionality to generate a persistence-file and also a sitemap including labels, icons, etc.(!).
Believe it or not… 90% of our users do not have any IT and/or smart home related skills (and also do not care about those things) and they are totally happy with the automatically generated “default configuration”.
We even provide state descriptions and tags etc. from the PLC to openHAB so our PLC based Smart Home can even be controlled by Alexa or Siri without any additional effort on openHAB side.
Skilled users do not use the “simple mode”, they build they Smart Home as described by you.
So IMHO there are special use cases where automatic generation makes sense - even if you loose flexibility because i.e. the items get some “strange” names. For users who do not care those things simply do not matter.
Is there an API function or core functionality which can be extended or (re)used for those use cases?
So why not deliver the OH config prebuilt too? Generate the configs once and then just reuse them?
Not to my knowledge. I’m sure you can open an Issue or even better a PR, but it’s pretty hard to get something like this into the core. The core moves slowly for a reason, it’s why OH overall is pretty stable.
And since you are the skilled users in this case, you can create an exemplar OH config and reuse them in part or in whole prior to your deployment. You have full control over all of that.
This is how I started some years ago, but there are at least two reasons to generate the OH configuration dynmanically (on-the fly) with the customer:
Each electrical cabinet is unique. We build them using (software and hardware) building blocks to best fit the building and the demands of the customer. This makes reuse of any OH config really hard
Our PLC software (the software building blocks) moves fast; we provide new releases at least twice a year with new functions and enhancements while the hardware remains the same. With OH2 this is “automagically” reflected in the OH configuration. Our customer love this feature. Here an example
