Ideas and Discussion: What Features Do You Want in openHAB 5.0?

[rlkoshak (Rich Koshak)]

I want to caution everyone threads like this are at best brain storming exercises. No request or feature is likely to be implemented without a volunteer to work it. This is just brain storming, nothing more.

@milo

I wanted to share an idea for openHAB 5.0: integrating the ESP32-S3 as a lightweight voice satellite for audio streaming to enable decentralized voice recognition.

Are you familiar with Willow - Open Source Echo/Google Home Quality Speech Hardware for $50?

I think an add-on could be created with this to make the integration better.

@JimH

I would like to see support for the Semantic Model in textual configuration files.

As mentioned, this is already possible but I don’t think it’s documented. An issue is open to add it to the documents waiting to be worked. All the info needed is in the issue if someone wants a good first issue to contribute.

@Udo_Hartmann

edit: And please get complete item and link configuration through yaml up and running…

A PR was started and abandonded. Who ever volunteers for this needs to either ignore the tons of discussion that will be generated and ge to an MVP or be ready to deal with a million contradictory opinions about how it should work.

But if that PR can be resurected, a good deal of work has already been done and it’s a much requested feature.

@Oliver2

In MainUI integrated and customizable logviewer so that we can drop frontail which is not maintained anymore and not available on Windows machines.

@Andrew_Rowe

+1
seems like this has been asked for at least a bazzillion times

As @milo links to, a PR has already been opened and I’m hopeful to get a MVP by 4.3 release in a few weeks. It’s already looking really good. Thanks @chris!

@gloeckner_ronny

In my opinion it should be possible the have a one time automated migration of the text based configuration into the “visual based” configuration.
If you still want to support those users who what to do things manually, then just provide an embeded text editor which allows them to modify the config items in text form but all gets stored into one DB.

This is not going to happen. There are too many users who prefer files for their config and some use cases where files are the only really viable option (e.g. those who run a business configuring and managing OH installations.

Before all the file based users freak out, this is not going to happen. Your file based configs are safe.

@Udo_Hartmann

Available since OH3.0

To be fair, the built in mechanism only supports .items files. For everything else there is no import mechanism though there are some scripts on the forum that do this I think (mayb they do the opposite and migrate managed configs to file configs, I don’t remember).

---

My wants in no particular order:

• Add a tool under Developer Tools to create Rule Templates. We already have a tool for Block Libraries and for MainUI Widgets. I don’t think it would be that much of a streatch to support Rule Tempaltes too. This will greatly improve the ability to test them prior to publishing them to the marketplace, or have the option to create a template without publishing it to the marketplace at all.

• Improve the upgrade process for rule templates, widgets, Block Libraries. Even if we can have a way to know when a template has been updated would be an improvement. For now you have to subscribe to the topic thread to discover that a tempalte has been updated and then one needs to remove the old template and readd the new and then delete the rules and recreate them in order to update. The same goes for MainUI Widgets and Block Libraries on the marketpalce.

• An add-on(?) that adds an LLM (Llama?) trained on OH that knows OH configs and OH rules and can help out with those since ChatGPT et. al. are so horrible with that and far too many are trying to use them anyway. As an add-on it can be integrated in the developer sidebar perhaps where one can ask it questions and get meaningful responses. It needs to be an add-on though since an LLM requires hefty hardware to be useful.

• Import/export for all OH configs in the same (or mostly same) YAML as shown in MainUI which of course requires support for YAML file based configs. Note for a lot of things JSON files are already supported but JSON is really hard to use as a human, especially for rules. I’m not sure JSON is supported for everything though. The overall intent is to provide a mechanism for users to move to and away from managed configs as desired.

• GraalVM Python 3

• Clojure, Scala, or any other functional rules language that doesn’t require jumping through lots of hoops (e.g. installing the marketplace Java Rules add-on first). I miss my parens, car and cdr. I also think the event driven nature of OH makes functional programming a good fit.

• A real built in scheduler akin to the Timeline Picker. Setting up a schedule for OH rules has come a long way but still has a long way to go. We should be able to create a schedule at least as easily as can be done for just about any smart thermostat.

• The ability to access stuff (e.g. newState) in UI rule actions and conditions and the ability to pass the result from calling one UI rule action to the next in the list. And while we are on the topic, a sleep UI rule action is much requested. UI only rules are OK but they can be made more capable than they are now. I think work is already underway to make Thing Actions more usable from UI only rules.

• Persistence viewer/editor to see what’s persisted in a table and “fix” entries, clean up no longer needed data, etc.

• With all the great new capabilities added to persistence I wonder if rrd4j is a good default any longer. Maybe SQLite would be a better choice. However, that would only be viable if the previous is also implemented so there’s an easy way to get rid of no longer needed data to avoid the DB from eating the whole file system over time.