Install bindings programmatically (or via console) without clicking

Hello,

My setup is an OpenHAB version 3.0.1 in a private Kubernetes (k3s) cluster. Everything works fine and is up and running. Now I could start using the cool new web interface to start installing bindings, discovering things,configuring items, sitemaps, etc.

However, I would like to configure my whole OpenHAB instance using the Karaf console, the REST API and whatever is there to use code instead of graphical user interfaces. My ideal scenario is to have an OpenHAB running that was completely set up programmatically without a single click. :slight_smile:

Now I am struggling with the best way to install bindings and configure them in the right way. I couldn’t find any documentation about this.

Could someone please point me to the right documentation or describe the next steps of the path I would like to follow? You know, installing bindings, discovering things and all nice stuff you can do with OH.

Thanks a lot in advance!

Everything that is done through the UI has a REST API endpoint. The interactive docs for the REST API can be found under Developer Tools. You can see all the end points and experiment with them right there in the docs.

Beyond that, almost everything can also be done through configuration files which would probably be a more appropriate approach here. You can define the bindings that get installed using conf/services/addons.cfg. The comments in the stub of the file that should already be there explains what needs to go where.

The inbox management is a little more challenging but again, you can interact with the REST API to figure out how to get the list of discovered devices and accept them. Though that’s going to require a good deal of JSON processing and editing since you’ll want to make changes to the Thing, at a minimum the label, before accepting the Things. So again, it might be better to use .things files instead.

Dealing with Items and sitemaps are all pretty well supported with config files and the REST API.

Persistence strategies can only be configured via .persist files.

Rules will be very awkward to create through the REST API. That is getting really close to basically writing code to write code which never really works out all that well. Remember that OH is a programming environment and framework upon which one builds a bespoke home automation. All of the configs are really more code than configuration. So I personally am always very skeptical when users say they want to do everything without the benefit of the tools built into OH to make programming your home automation better.

You’d never remotely program a web site through an awkward API; you’d use an IDE with tools to help you. You’d never program a phone app by writing code to write your app for you; you’d use an IDE with emulators specially created for that purpose. So why use an awkward API to code a home automation application? There may be some good reasons but over all it’s making it way harder on yourself and home automation is already hard enough.

tl;dr:

  • Use text configs where possible
  • Look at the REST API docs
  • If you really want to use the console, see The Console | openHAB and Runtime Commands | openHAB and Bundle Management | openHAB
  • Reconsider what your real goal is. If it’s to experiment and learn how to remotely configure something, perhaps a different software would be a better choice than openHAB. If your goal is to build a home automation, consider whether making doing so even harder than it already is is worth what ever benefit you hope to get by not using the config files nor the UI.

Thanks a lot for the very detailed answer!

I fully agree that it doesn’t make sense to make my life harder by ignoring the tools that are available. My main goal is to use OH as a platform that provides me with all the great integrations for my home automation devices. Additionally, I want to be able to throw all the installed code away and restart it on some different machines in just a few minutes. Adding things, items etc. means adding text in config files. This “infrastructure as code” approach is very important to me. And that actually includes config files (sorry for not mentioning that in my initial question).

So for my purposes using config files and putting them in the right place upfront using some bash scripts seems to be the best way for me.
Actually, I really missed the point that searching for “bindings” also meant searching for “add-ons”. Starting with conf/services/addons.cfg sounds just like right. Thanks again!