Configuration of openHAB

Development
241

Or not using any parsers and migrate to a file format that has native libraries. Just saying.

242

I also have been reading up on this, and I believe it is agreed upon, even by David, to have a migration path in place to allow existing installations an easy transition over. Sorry, related to a post 10 days ago, probably should have quoted you.

243

It’s not necessary to quote when you use the reply button of the specific posting. You’ll notice on the top right side of the reply the name of the person you replied to. When you click on this name, then the posting which was replied to will automatically appear :slight_smile:

For the config files I don’t see much of an issue with migrating those to another format. That should be relatively easy to do. For the rules I see more challenges though since these contain logic. There have been suggestions of automatically migrating them to Groovy or making Xtend a first class JSR223 citizen (if possible).
I write my rules in Jython so for me losing the DSL rules would not be a problem. However the majority are still using DSL based rules and for them this could be a painful excercise.

1 Like
244

I use the dsl, and yes, I agree. But, I would hope that before anything is set in stone, there would be a proper plan in place; at least that’s my hope.

245

Isn’t this also the Home Assistant approach? Wouldn’t it be nice to have configuration and/or rule exchange between the OH and HA?

Maybe it’s too far away, but this would create a kind of standard in the open source smart home world


1 Like
246

Yes, they use the same file format for configuration. However how the configuration is structured in the yml files is/might be very different.
Also they use Jinja2 templates as the default rule engine which is also part of the configuration. In OpenHAB there is an (imho better) differentiation between configuration and logic.
So even tho it might be the same file format, it doesn’t mean exchanging information is possible.

247

Sorry, maybe wrong thread, I just wanted to point that OH3 would maybe be the good time to integrate Astro as a service, instead of being a binding. This would help deliver its features accross all other bindings.

1 Like