Add support to create things from automation script

[ThaDaVos]

Just like one can do with items already, would love to be able to create things from JavaScript/Typescript too - this way I could use the automation addon to fully define my system - better said, use script to automate the definition - for example use arrays and logic to create stuff instead of repetitive defining them in files.

Your Environment

• openHAB version used (check Main UI -> About):
• openhab-js version used (run console.log('openhab-js ' + utils.OPENHAB_JS_VERSION) from a JS script): N/A
• Operating System and version (e.g. desktop or mobile, Windows 10, Raspbian Buster, ...): N/A

[florian-h05]

I admit this sounds very interesting, but might be a bit challenging.
Anyway, before implementing this in the library layer, we should have a good mechanism in place in core that handles the lifecycle of what is provided by scripts. I have just finished my work on openhab/openhab-core#4513 for that - it starts with an ItemRegistry delegate that tracks the lifecycle of the script providing the Items, which allow to programatically provide Items which will be removed once the script unloads and cannot be modified through the UI.
Once this is merged, I can implement the same for the ThingRegistry and dive into the library code as a final step.

[ThaDaVos]

Thank you for picking this up @florian-h05 - guess it's targeted at OpenHAB 5?

[florian-h05]

Yes this is targeting openHAB 5, but probably might be 5.1 if I don't make it until July.

[ThaDaVos]

Ah so July is OH 5 release, if you need help, ping me - I'll be focusing on my own OpenHAB upgrade project soon again

[florian-h05]

Okay I just went ahead and implemented the ThingRegistry delegate as well in core.
If you build openhab/openhab-core#4513 and deploy it to a recent openHAB 5 snapshot instance, you will be able to create Things like this (currently only through the raw Java APIs):

var thingRegistry = require('@runtime/provider').thingRegistry

var ThingBuilder = Java.type('org.openhab.core.thing.binding.builder.ThingBuilder')
var ThingTypeUID = Java.type('org.openhab.core.thing.ThingTypeUID')
var ThingUID = Java.type('org.openhab.core.thing.ThingUID')
var Configuration = Java.type('org.openhab.core.config.core.Configuration')

var thing = ThingBuilder.create(new ThingTypeUID('astro:sun'), 'local')
  .withLabel('Astro Sun Local')
  .withConfiguration(new Configuration({
    geolocation: 'xxx, yyy'
  }))
  .build()

thingRegistry.add(thing)

[jpg0]

FYI when I initially wrote this openhab-js library, moving everything (e.g. not needing to configure anything in the UI) was a goal. I did use it to create Things and Items, so it's certainly possible.

@florian-h05 I found that it was simpler to avoid using managed providers where possible, and instead plugging in ephemeral providers from the scripts.

Also, although I've now moved on from using this library, I do continue to configure almost everything from code. One thing to be aware of is that there are places in the UI which assume that configuration can come from the UI or files only. They are generally only cosmetic, but it would be great to have real configuration-as-code support in openHAB.

[florian-h05]

I found that it was simpler to avoid using managed providers where possible, and instead plugging in ephemeral providers from the scripts.

I remember seeing the code in openhab-js.
My motivation behind openhab/openhab-core#4513 was provide a super simple way for scripts to provide stuff without having to implement a provider themselves, so far this seems to work fine, and all I need to change in openhab-js is to import the Item and Thing registry from a different scope. That’s nearly everything that needs to be changed on the script side (except for providing convenience methods of course).

They are generally only cosmetic, but it would be great to have real configuration-as-code support in openHAB.

If you open an issue in the WebUI repo and list what you have noticed so far I would be happy to look into this and see how we can improve.

[jpg0]

I have no problem with your approach; I just found that I encountered errors now and then if the lifecycle of the script didn't match the lifecycle of the item or thing, because of a crash or failed startup etc. Ultimately I had planned for the API to abstract away any custom provider creation so that the API would be as simple as possible either way. Anyway, just wanted to let you know in case you too encounter similar errors.

As for the UI issues, there are places which say: Note: This Item is not editable because it has been provisioned from a file.. I can certainly file a bug for this, but I assumed that it would be rejected because scripts are files? I certainly interpret this as configuration files, although in my case these are provisioned from an OSGi bundle, not a file.

[florian-h05]

I just found that I encountered errors now and then if the lifecycle of the script didn't match the lifecycle of the item or thing, because of a crash or failed startup etc

I am using a non-persistent provider in core so that after a restart all Items have to be provided again. In addition to that, my core PR tracks the lifecycle of the script providing something and removes it once its unloaded. I think this should be enough.

I can certainly file a bug for this, but I assumed that it would be rejected because scripts are files?

Fortunately its up to me to decide whether to reject this or not ;-)
Scripts are files, but when talking about files I would think of .items, .things etc in this context.
What about changing to [...] a file or script?

[florian-h05]

@ThaDaVos So the required core changes will be part of the upcoming 5.0 release, however I haven't been able to finish the openhab-js side of the implementation. Luckily you can upgrade openhab-js independent from openHAB itself, so you don't need to wait for openHAB 5.1.