Overriding a built-in binding

I’m working on some changes to a built-in binding. I have my own jar built and installed in /usr/share/openhab/addons. Even though they have the same package name, they appear as two separate bindings in bundle:list. I can stop the built-in one (which moves it to Resolved) and keep mine Active, and this seems to persist across OH restarts.

I just did an upgrade though, from OH3 M5 to RC1. After starting up, both bindings appear as Active. I had to stop the built-in one again and restart OH (twice, I think) for my binding to start working.

When you stop a binding (by id number), where is this persisted? I can’t find it anywhere.

For binding developers, is this the recommend approach, to put the updated jar in the addons directory and stop the conflicting built-in binding? Is there a way to make it automatically mask the built-in one with the same package name, so I don’t have to manually stop it?

Did you consider to just uninstall the ‘built-in’ binding?

3 Likes

Yeah, but I followed the recommendation in the docs to define all of my Things via the UI (PaperUI originally in 2.5) and my Items in an items file. This means that my Things are all in jsondb, and when you uninstall the binding, it automatically deletes them all.

Is there a way to uninstall the binding without deleting the Things? Just leave them orphaned and waiting for a new matching binding to come along?

Deleting the related things when a binding gets uninstalled seems to me as a binding specific behaviour.
Why can’t you create the things from your version of the binding?

AFAIK they are not deleted and should be visible in PaperUI -> Configuration -> Things, but not in Control tab.

Well they definitely were gone, but I’m on OH 3 now so I guess I’ll try again and see if it’s still happening. Worst case, I can restore the jsondb file from a backup. Although I’m still really curious about where it persists the binding state as I haven’t been able to find it anywhere!

That’s a behavior I have never seen. Which binding is that?

It’s the Powermax binding, for the Visonic Powermax alarm system. You first create a Bridge Thing and it detects all of your zones and puts Zone Things in the inbox. Then you can create the Things and give them labels (e.g. powermax:zone:<bridge id>:1 = Front Door Contact). If you remove the binding, all of those Things disappear, and in my experience, they don’t come back. After reinstalling the binding, I had to create a new Bridge, and all of the zones came back to the inbox without their labels. It’s sort of a pain to keep recreating them.

I also have several Zone Things for unused zones which I ignore from the inbox (usually using inbox ignore via the ssh console). Any time I mess with the binding, including deploying an updated jar, those ignored zones all come back.

I just figured this was typical, that when you uninstall a binding, all of its Things automatically get removed. Maybe it’s something specific to this binding though.

As I understood you did only do changes on the binding, if those changes did not remove the thing and bridge creation parts you should be able able to create them with your version.

Yes I understand. I was really hoping to not have to recreate all of the Things when switching back and forth between the built-in binding and my custom version (it takes several minutes to recreate everything). I know I could move the definitions to a things file or restore from a jsondb backup. I was hoping that wouldn’t be necessary though. Oh well, not a huge deal.

Of course the powermax binding is not removing any thing.
A binding has not this ability at my knowledge.

You’re right, I’m no longer able to reproduce this with 3.0. I had it happen multiple times with 2.5 that I uninstalled the binding and after reinstalling, all of the zones appeared in the inbox as new. I’m fairly new to OH and I just figured this was intentional, that uninstalling the binding would delete the Things. But there must have been something else going on. With 3.0 I can uninstall and reinstall with no impact.

Never mind then, sorry for the noise and thanks for your help.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.