I’ve been an openHAB user for over 10 years and experienced the community’s shift away from the conf folder towards UI-based configuration. I understand the reasons behind it.
Now things have changed again. With AI tools, generating configurations (items, things, rules, widgets) would be much faster—and more precise—when working with config files.
Using AI, file-based configuration would allow generating and applying complete setups within minutes. Also changes.
So from a technical perspective, wouldn’t a stronger focus (again) on file-based configuration make sense in the context of AI-tools?
I know the topic of „letting an agent getting its hands on openHAB“ is controversial (I could not find the thread from some days back discussing this), but I kept having the same thoughts.
There are some ideas that I wanted to implement for quite some time now (combination of „rule needed“ + „visualisation needed“). Having the possibility to tell an agent „here’s the one rule you can edit, and here’s the visualization you can edit“ (as a containment strategy) would be neat.
Well, there’s good reasons for both, UI and text config, but they have all been discussed before.
AI essentially does not change anything about it and to reanimate these discussions is pretty much a waste of time.
But if you take a closer look at the latest documentation, you will notice that openHAB maintainers have gone to great lengths meanwhile to ensure that both, UI and text input are well documented, for various languages, so everybody can make his personal choice him- or herself.
Per component, actually.
So feel free to click your own things and have some agent write your rules. Or vice versa.
We have developments in progress to facilitate conversion between UI and config file for rules and sitemaps.
It is already there in place for items and things.
There is tons of work ongoing to make OH work with AI better. There’s a PR to add MCP to the OH API for instance.
In my experience, the AI agents are as capable of producing proper OH JSON as they are producing .items files et. al. If using agentic AI, even without the MCP they are capable of generating the REST API calls to add them to a managed config as they are of producing files based configs. (So far AI still remains not so good at writing rules but it’s getting better.)
There already is a very strong focus on file-based configuration. We have a new YAML format that lets you define everything and supports stuff not supported in any other file format, such as rule templates and simple UI rules (eventually I would expect this file format to support everything). A new translation service was added to the API awhile back which can convert from one format (e.g. .items files) to another (e.g. yaml) and it can be used to export a managed config to either format.
I’m only dabbling in openHAB, and I’m currently setting up a system together with several other people. A fully file‑based setup would be my preference, because it allows us to work in parallel without stepping on each other’s toes. We mostly use VS Code, and the combination of a stable platform with modern AI tooling gives us possibilities that simply weren’t realistic a few years ago.
During development we run multiple openHAB instances, and having everything file‑based makes it extremely easy to test and deploy individual sections.
The fact that pages and widgets aren’t file‑based is a bit inconvenient for our workflow. It’s not only about transferring them between instances—if I understand correctly, the YAML view is just a representation of the JSONDB, and that seems to be why comments disappear whenever a widget or page is saved.
It’s not a deal‑breaker, just a friction point. I’m often genuinely impressed by how quickly openHAB reacts to changes in .items, .things, and other file‑based configs.
Very grateful to be using openHAB.
PS: We use openHAB in a project‑based course on Data Acquisition. The goal is to teach students how to enter an unfamiliar domain, get frustrated, and still remain productive. About 220 electromechanical engineering students set up a Raspberry Pi with a Grove HAT, sensors, MQTT, and openHAB. They complete challenges to earn virtual money for their team. openHAB is what we use to visualize task completion and the current state of their virtual wallets.
JSON doesn’t have support for comments. Full stop. So any comments you add to the YAML view get removed because JSON doesn’t have a way to save them.
However, JSON is very forgiving. You should be able to add a “comment” element to your YAML which will become a comment: element of the JSON and thus be preserved. As with all things, YMMV.
Thanks a lot for all the replies — really helpful.
I do think it’s great that openHAB still offers the option to use files in conf . I’m also working with VSCode and git, as others have mentioned. JS rules are already a good example for me of the benefits of file-based configuration, especially since I am regularly using Claude or Codex to create and maintain them.
Where it gets a bit tricky for me is pages and widgets. For quite some time, I had the idea to replace my old sitemaps with a custom widget library and build pages around it. However, I never followed through, mainly because doing all of this via the web UI turned out to be quite time-consuming.
If I compare that to how quickly I can build and iterate UI-heavy apps (e.g. Angular or XAML) in a file-based setup with AI support, the difference is quite noticeable.
So that’s really where my original thought was coming from — that maybe the ui part could be considered by the openHAB maintainers in the future somehow also.
Hi @rlkoshak thanks a lot — I was not aware of this feature.
This will definitely help me in the future to move parts into the items folder, especially where I make frequent changes or where it helps to provide better context for AI (e.g. knowing the exact item definitions to be used within rules)
The code tab in Main UI just presents a representation of the object in any supported config file format. The comments or unexpected YAML fields in the original file will not be presented.
I don’t quite follow you here. There’s nothing “simple” about the YAML rules, they are the only file-format that can utilize all the capabilities of the OH rule system. I don’t know what more you’d want the format to support (if you mean rules-wise, if you mean other “entities” then I agree).
I’m working on extending the “translation service” apply to rules and rule templates as well, and it’s nearly feature-complete in the REST API. There are some details still to figure out exactly how to handle, but the majority of the remaining work on this is implementing it in the UI.
With this, it’s easy to export “UI”/managed rules to files, if the rules use DSL for their actions, you can export them to .rules files, for all other languages (or if you prefer, also for DSL) you can export them to YAML files.
This is quite different for widgets, they don’t adhere to “strict definitions” in core the way Things, Items and Rules do. Core don’t “understand” widgets, it only stores them, they are rendered by MainUI. This means that there is no “scrubbing” of irrelevant information, and you can define a key that holds a comment if you like to.
Still, it would be better with actual comment support, but that would mean moving JSON DB from JSON to JSON5.
“Simple rule” is what we’ve always called UI rules that have actions/conditions that are not inline script actions/conditions. They are simple in that no code need be written by the end users.
Can you give examples of when this yaml rules will be needed / used / preferred over the “traditional” rule files such as jsscripting, jruby, python, or even dsl?
That depends on your needs. The YAML rules can do everything a rule can do, which none of the other file-based formats can, so if you want to use some of these capabilities, they are a natural option. That is things like using rule templates, having multiple actions, conditions, scripted conditions, using non-scripted actions etc. They can also be used to move existing “UI rules” to file-based storage. In addition, you can use them for all kind of rules if you happen to prefer the format.
It also has the advantage that, once you get the hang of it, it’s very easy to turn a rule into a rule template if you use YAML. As soon as you find yourself “copying and modifying” rules that are almost the same, you should consider if it would be easier to turn it into a rule template, and have “rules” (I call them rule stubs) that only set the placeholder values.
But, like with all this “YAML stuff”, it’s fully optional, all the other ways of doing things can also be used if that’s preferred.
The two advantages you get by using rules created by scripts (“file-based” JS, Ruby, Python etc.) are IDE context support and shared context. YAML won’t give you that, so if that means more than the other possibilities, stick with the existing system.
I always stayed with my file-based configuration. This is IMHO the best approach as
it allows an almost effortless and safe backup (just store the files elsewhere). This helped my numerous times, especially when OpenHAB system versions changed significantly and broke my system. Also when moving from a RasPi3 to an RaspPi4 this helped a lot
you have a complete overview of all configurations at a glance
and yes, it allows AI-based enhancements, debugging, etc. I even let Codex 5.3 directly work on my RasPi (Samba mounted). It helped me creating capabilities I shyed away until now due to effort and complexity. It can do everthing: .things, .items, .rules, .sitemaps, …
I’ve created a PR for creating file based Pages and Widgets. If/once that’s merged, I think we’ll have full parity of file-based config with UI config.
There are some things still missing as far as I can tell: Transformations and blocks come to mind. In addition, “Scripts” and “Scenes” have less than ideal support, even thought they strictly work as YAML rules.
Sorry, I misread. I “read” full parity of YAML based config with UI config. I’ve always expected that eventually, transformations will make their way into YAML as well.
I don’t use Blocky so I really don’t know what is what there, but you have blocks on the marketplace, I imagine it’s somewhat similar to a library for a programming language. Pre-defined components that you can reuse. They currently exist using “old YAML” on the marketplace, and is installed into the JSON DB:
Why would they be any more or less relevant in file-based configs? A “Script” in OH is simply a rule without a trigger, one that can be called explicitly but never fires itself. A “Scene” is a “simplified form” to set multiple Items to a predefined state.
As I said, they will both work as YAML rules, but the way they are presented in the UI isn’t as rules, but as “their own thing”. This isn’t reflected in the YAML format, and especially scenes look very “foreign” and completely different from the “YAML” shown in the UI.
If triggerless DSL rules are allowed, the “Script” concept deprecated (instead, just “admitting” that they are triggerless rules), “Scripts” will be “fully integrated” into file-based config.
Scenes on the other hand can never be expressed as DSL (since they have multiple actions), and some work is needed to figure out exactly how they should be represented in “new YAML”.
