I want to focus on one feature I had been waiting for for a long time and which, in my opinion, could give openHAB development a real boost.
Starting with 5.2, UI elements — pages and widgets — can be created not only in the online editor and stored in internal database, but also as regular configuration files, similar to how Things and Items can already be managed.
This small change fundamentally changes the workflow:
Everything you create can be stored in Git, without having to worry about database backups.
You can use a proper IDE.
Most importantly, UI development becomes much easier to do with AI-assisted coding.
The third point could be especially important for openHAB’s future.
It is no secret that Home Assistant is significantly more popular than openHAB. One reason is that Home Assistant provides a much easier out-of-the-box starting point, while openHAB is still more of a low-level platform where users often have to build a lot themselves. UI development in particular has always required a significant amount of time, effort, and experience.
But once UI definitions can be represented as files and handed over to AI tools, this may change substantially.
Here is what I managed to build over the weekend using Codex:
Of course, I have no illusion that openHAB will suddenly catch up with Home Assistant in popularity. However, perhaps openHAB interfaces can finally stop looking like they were “made by programmers.”
Well, OH also has been providing graphical tools such as the wizard on first start (enhanced in 5.2, too!) or the marketplace to provide ready-made widgets and I doubt the average user will use AI to generate OH UI code instead now but yes, it could become a game changer for those that understand the potential. Your example clearly is on the PLUS side of things.
And I second your statement that this new ability in fact is much greater than you would think at first sight.
It also enables some experienced operator to deploy OH instances and services to friends & family or even customers of his. People could even make a business of operating OH for other people. Like in website hosting, fully automatable deployments make the key difference here.
Full text config allows to combine pre-configured, operator-provided unchangeable basic setups that ensure the system works with user configurable extensions such as individual rules.
Exactly. An important and underestimated feature is that yaml/*.yaml can now be used to assemble complete bundles containing essentially everything, and those bundles can be moved between openHAB instances in just 1 file.
The interface I showed above is actually built as one of these bundles. It includes supporting Items, supporting rules for collecting historic JSON data and rendering SVGs, and packages everything into a single entity, even with a demo/test page included.
Once you understand the potential, this changes a lot.
I want to sincerely thank the developers once again for such an incredible feature. I hope future releases will also add support for subfolders, because I suspect I’m going to end up with a lot of files there
I just wanted to metntion:
One thing that is even more interesting is using the brand new MCP Binding.
Just install the MCP Binding, add the MCP Server to your ChatGPT / Claude / whatever and let the AI directly work on your MainUI Pages and Rules without even copying anything
Sorry, I’ve always believed—and still believe—that MCP is a dead-end approach to AI development, so I try not to use it. I focus on agent-based development instead
There are already plenty of discussions about this on YouTube, so I don’t see much point in repeating the same arguments. If you’ve already reached your own conclusion, you probably don’t need more justification. If you disagree, that’s fine too—use it if it works for you.
In my view, MCP is a workaround that emerged early in the evolution of AI. By itself, it doesn’t really solve anything; it mainly introduces another layer of complexity and another point where things can go wrong. My AI agent has been working with my OpenHAB setup for over a year without any MCP, and adding MCP wouldn’t give it any new capabilities.
In my view, MCP is an attempt to standardize and constrain something that shouldn’t be standardized or constrained in the first place. The alternative is simply CLI + APIs + search.
A modern AI agent has no trouble learning how to work with a service on its own. OpenHAB has an excellent, extensive, and well-self-documented API. A modern agent can figure out how to use it within minutes and then build its own instructions and workflows tailored to its owner’s specific tasks for future use
I have no practical experience at all about this but it sounds really interesting. Could you give us a further glimpse how it’s being done to make your agent understand the REST API of openHAB and your smart home structure?
I use OpenClaw with the Codex model. On the hosts where OpenClaw and openHAB are running, I have a Tailscale network set up to provide private and secure communication between them.
Then I gave OpenClaw a prompt along the lines of: “I have a smart home running on this host with openHAB. Figure out how you can integrate with it.”
It explored the system, found the API, created a token for itself because it had access to the SSH console, reviewed the API, identified the key endpoints it needed, and that was basically it. It then created its own md files and python scripts with the relevant instructions and flows.
After some time, I noticed that it was fetching the current list of items every time. So I changed the setup so that once an hour it saves a JSON snapshot of the items into its instructions and does not query openHAB constantly.
Based on item labels and semantic metadata, it understands where everything is located and handles requests such as “turn on the light in the office,” “what is the current solar generation,” or “increase the ventilation” without any problems or unnecessary follow-up questions.
And, of course, everything is in Ukrainian, since it is my native language.
This is what the “integration” between OpenClaw and openHAB currently looks like. OpenClaw wrote it for itself while independently exploring the system. And, surprisingly, it actually works
One particularly strange experiment comes to mind. At one point, I asked it—she is female, by the way—something like: “I’m seeing unusual water pressure fluctuations in the system. Analyze what might be causing them and whether this looks like a leak.”
It spent quite a long time investigating the issue, around 30 minutes, and burned through a huge number of tokens. In the end, it said that the pressure fluctuations were synchronized with the boiler recirculation pump turning on. Its conclusion was that the water was cooling down cyclically, causing the boiler to switch on, which in turn made the pressure rise and fall.
That answer probably cost me far too much money, but as an experiment, it demonstrated a lot about the potential of this approach.
No, at this point I do not see any real practical use for them beyond analyzing patterns in a highly formalized format.
Perhaps it would be possible to run an agent on a local LLM and give it some very simple, asynchronous tasks, since they would take a long time to complete. But I do not really have any suitable tasks like that, so no—I have neither the experience nor the desire to experiment with it. Maybe in another ten years
I know someone who uses a local LLM that he fine-tuned himself to predict trends. Apparently, the results are significantly better than random, but I do not currently have any tasks like that.
I think you’re exaggerating the gap between local and premium paid ones. I’m not saying that they’re the same, but there is more to the story.
First of all, there’s a huge difference among “local LLMs”. Some people run 3B models and think that they will get something useful out of that - that’s highly unlikely unless in very specialized circumstances.
I’ve recently done some “probing” into local LLMs to see if I could find a compromise between price and usefulness that’s worth it - I’m still not sure if I have, but here’s the thread: VS Code and Copilot free plan
I can run 7-8-9B models in my current VRAM (11 GB). That makes them plenty fast, in fact, it “feels” like I get answers quite a lot quicker than when using the free Copilot earlier (I’ve stopped doing that after they gutted it beyond any usability). That isn’t fair though, because I bet that Copilot did a lot “more thinking”, which explains the longer time to come up with an answer, but these models certainly aren’t slow.
I found them to be just “too stupid” for coding assistance, that doesn’t necessarily mean that they can’t perform more generic analysis tasks quite well - I don’t know, it’s not what I’ve tested.
So, I’m currently running Qwen2.5-Coder 32B. It consumes around 20GB VRAM or so, which forces a lot of “swapping” to system RAM, which makes the whole thing extremely slow. But, that is only because I lack enough VRAM, if I put another “cheap” 4060 16G card in there, I would easily be able to run that at full speed.
I’m still trying to decide if it’s worth it, if the quality of what I get from a 32B model is good enough. The slowness of using it means that I don’t always have the patience to test it, and just do it myself instead. It is claimed to “match” GPT-4o for coding tasks. I have no view on whether that is true.
But, there are larger models you can run locally. The Qwen3-Coder-Next gets a lot of praise from some people, it’s a 80B model that somehow only loads parts of the model (the parts needed I for the type of work I assume) into VRAM, and can run on a lot less VRAM than a 80B model would normally require. I haven’t tested it, so I can’t speak to it - but the point is, you can run local models in pretty much any size you want. If you have 250GB VRAM, you can run a 480B model of Qwen3 locally. I doubt that is any less capable that many of the models people use online today, chances are that it’s better than many of them.
So, local models themselves shouldn’t be brushed aside. What it really comes down to is the insane price you have to pay for VRAM. This is because Nvidia pretty much controls the market completely, and they intend to milk people dry for however much money then can. The prices rise exponentially when you want more VRAM, it has nothing to do with the cost of the RAM itself. Compare the price of an Nvidia A100 80GB with a 16 GB 4060Ti, and you’ll see that the difference in pricing is just insane. And largely, all the other stuff with the number of cores and all that is of less importance, using a local LLM for a single user doesn’t require that much processing. My 11GB 2080Ti is plenty fast once something fit in VRAM. So, it ends up simply being about VRAM. And it’s priced extremely insanely because there’s effectively a monopoly.
But, the VRAM market situation shouldn’t be used “against” the local models themselves, it’s unrelated to their capabilities. And, even if VRAM is insanely priced, so is the cost for tokens - and that will only get worse in the time to come. Many companies have already found that buying tokens to do a task is more expensive than paying humans to do it. So, if you plan on dumping a lot of money on the cloud providers, that won’t show you any “gratitude”, and will only keep squeezing you for more, you should consider if there’s a way to get a decent amount of VRAM locally for this money instead.
There’s nothing that is within the budget of what I’m willing to pay at the moment, but I’m not willing to pay anything to the cloud providers either. If this calculus is different for others, then perhaps getting a pair of second hand RTX 3090 24GB cards isn’t out of the question either. And yes, if your motherboard has the slots, you can combine multiple GPUs and the VRAM is “combined”. So, with dual (most motherboards have room for two GPUs, some more) 24GB cards, you’ll have 48GB VRAM available. It’s enough to run full 70-80B models.
I can’t speak to what the quality of those are, but I wouldn’t dismiss it out of hand. Everybody should consider where to put their money - in instant consumption where the money is just burned, or in investing in hardware that will let you “compute for free” (minus the electricity).
It’s difficult at the moment because of the monopoly situation, but if that changes, I think local models will become more attractive rapidly.
Yes, it uses that model, but the connection is not through the API; it goes through their Codex CLI. OpenClaw supports this, and the prepaid plans there are significantly more cost-effective than API usage, at least for now.
As for how much it costs me, that is difficult to estimate because I also use Codex for my work as a developer, so I cannot separate my “home usage” from my work-related usage. I pay $20 per month for the Plus plan and usually purchase another $40 in additional credits. Usage varies from month to month, but that is generally enough to cover both my personal and work-related tasks.
As for the cost of that particular experiment, something that extreme could probably burn through $10, $20, or even $30 worth of tokens quite easily.
