That by itself ain’t a request on OH5.
There already are a number of threads on specific issues, and there’s the forum search function. It just makes much more sense to expect users to search correctly-thoroughly than to have some voluntary human curate and sort all the available information.
Sure it might be annoying if you don’t find right away what you’re searching for but that’s either an issue of you searching not thoroughly enough then or that you have a really edge-casey issue.
Frankly, I haven’t heard of others to run a powerful x86 server and still have performance or stability issues. I don’t know of unstable bindings (unless you experiment with beta stuff), and “overly frequent rule triggers” is not an OH problem but caused by bad user understanding or programming. A UPnP flood like many other network issues has nothing to do with openHAB in the first place either.
You’re free to open a thread of yours at any time, but to be frank, fulfilling your requests is a complex task and would mean a huge amount of work and I don’t see the benefit to or even necessity for a large community, so it really sounds like a waste of time to me.
But hey, just my 2ct. In the end, it’s a contributor’s choice. If anyone has a different opinion here, nice, please step up get us docs PRs, we’re thankful for any contribution.
Hi
I see a lot messages related to configuration but didn’t find idea about merge text based and UI based configs.
UI config it is good and may be user friendly for new users but require a lot of the same steps for every configuration. Text based config require only copy paste with fix id and input/output number.
On my opinion the best idea is allow update via UI any item created in text config. Updates can be disabled for fields provided in text config.
As example:
I want to create item
This process will be significantly better in 5.0 - you will no longer need to copy-paste to duplicate similar things. It will be based on templates and you just create entities out of the template, replacing only relevant parts that you define (e.g. the thingid, item name, label). See: https://github.com/openhab/openhab-core/pull/4818
Although there is currently no active work on this, it will also be possible, perhaps for 5.1 or later, building on the work currently going into 5.0. It would be best if you could open a feature request here GitHub · Where software is built so it doesn’t get buried here. I would expect there will be a lot of debate for/against this though. I personally think it’s a good idea.
Attention here, do not assume everybody is talking about the same thing.
Most by “textual config” understand classic .things / .items files which is not what your PR is about, right?
When I run my dev environment (on my x86 laptop) I frequently encounter “performance issues”, and that in an installation with very few Things/Items etc. I can easily imagine that there are many, many potential reasons why “performance issues” can be a real problem in production environments. I’ve even had OH make the whole JVM hang badly, taking down Eclipse and everything else with it (by trying to install a marketplace add-on that had an invalid link). That shouldn’t be possible, but it did happen.
In my dev environment, I think the biggest problem is rules provided by scripting add-ons. The practice of using a “simple cron trigger” and then do the rest of the “trigger evaluation” in the “action code” itself leads to rules being “triggered” (but no action taken) very often, with some rules every second. To make it worse, disabling JSR223 rules doesn’t work across restarts, so the only way to prevent them doing this is to delete/move/rename the rule files themselves.
My current production installation runs on a RPi 4 and doesn’t really have much such problems. But, before the RPi I used to run OH from a dual-core i5 something running Windows. It was no rocket ship for sure, but the computer was otherwise “sufficiently capable” for most normal task. OH completely “killed performance” on that computer, making it sometimes hang the whole Windows network stack (so that I had to physically go to the computer to restart it). Starting up OH would take “ages”, and it was never guaranteed to succeed, often resulting in the hung network stack where a complete reboot was required.
I suspect that OH behaves worse on Windows than on Linux because Windows uses file locking while Linux doesn’t. This means that on Linux you can get away with not closing/cleaning up resources properly, files can still be deleted after use - but that’s not the case on Windows. This “developer laziness” regarding cleanup because they ever only test on Linux isn’t unique for OH, but I suspect that can explain at least some of the “difference in behavior” between Linux and Windows.
Your experience may vary, both when it comes to performance and stability, depending on hardware and bindings/configuration. OH is quite complex and depends on “cooperation” of a lot of relatively independent pieces of code, so I don’t think it’s unexpected or “blameworthy” for this to occur, I just don’t think it’s reasonable for it to be dismissed with “I haven’t heard of others..”. I’m sure that depends on who you ask/listen to.
Though if someone does volunteer I think we as a community would support the effort.
It’s not a bad idea per se, but I think much of that information is already there in the docs, particularly if you look at the openHABian troubleshooting docs and such. I’m skeptical that anything useful would come of it but often important things can be learned in the trying.
@lo92fr, creating a thread on the forum is almost free and has about the lowest barrier to entry and technical requirements. If you think this is an idea that can become something, please pursue it. I doubt anyone else is going to volunteer to do it though.
It’s brought up above and at least for the configuration syntax and formats work is ongoing in OH 5. There is a new translation service being added that will be used in MainUI to show your Items, Things, etc. in the original DSL syntax or in a new YAML syntax. This new YAML syntax can be copied to files and used as is as well, bringing a more unified config syntax. To put it shortly, what you see in MainUI will work in a text file and vise versa.
Major progress has been made, and I expect decent support for the big stuff (Items, Things, Rules) in OH 5.0 release with improvements and other stuff (transformations, persistence, etc) to come later.
No, but there are related PRs for translations. No longer is the translation between the actual JSON representation of stuff OH core keeps internally translated to just YAML in MainUI. That has been moved to core with a REST API endpoint, and it supports getting both DSL and YAML and MainUI calls that to get the translation. As a result, we’ll have a “DSL” and “YAML” tab in the “Code” section for any given entity where we can see either format.
In addition, a new file based config format is under development using YAML as the base instead of a custom Domain Specific Language (DSL). The PR mentioned above will eventually show this new file format when it shows the YAML version of the code instead of the straight JSON to YAML mapping. And for those who choose to create their file based configs in this new YAML format, they will have access to templates, variable substitutions and includes to more easily build up their configs without a lot of copy/paste/edit.
In general, what you see as code in MainUI will be usable in a text file config and what you see in a text file config will be usable in MainUI. I expect there to be added an import/export feature at some point once all these base pieces are merged.
But, what there isn’t active work on, as @jimtng mentions, is making it so you can edit your text based configs from MainUI. That’s not being worked on yet. It is still the case that anything loaded from a text file config is read only in MainUI and you can only edit managed configs from MainUI.
Actually, that is only “half true”, because the “new YAML format framework” does support writing files as well as reading them, but I haven’t tested it and there are probably parts missing for this to work at this time. But, support for converting internal objects both to and from YAML is being made, and with the “YAML framework” also supporting the idea of writable files, there shouldn’t be much “missing” to make it possible to edit these from the UI.
I think there’s a different problem that might be a bigger obstacle though. The way OH works is that it can only have one “managed” provider for a certain object type, but it can have any number of “unmanaged” providers. The reason for this is that only “managed” objects can be written from OH’s side, the rest are read-only. When OH receives instructions to write/update/save something, it is automatically assumed to belong to the one managed provider for that object type. So, in short, you can not have more than one managed provider, which are currently the ones based on the JSON DB. Unless this logic is redesigned, you can’t have both the JSON DB and writable YAML files in the same installation. So, you’d have to choose.
Personally, I don’t think it’s desirable that OH should write to the files. It would introduce a number of problems: how do you get OH to make a file structure that fits the user, how to decide what should live in the same file and what should exist in different files, etc. And, the formatting wouldn’t match, lines would be rearranged or formatted slightly different, making diffs difficult to use or completely useless. What is the point of a file-based system in the end if you can’t control how files are organized or how changes are made? Isn’t the existing JSON DB just as good then?
The ability to make an object in the UI and copy/paste the code into a file should be a huge step forward from how this works today, and I think it might be close to what I’d consider “optimal” for how to maintain a file-based configuration.
I said that I haven’t heard of it, and given my activity level level here on the forum that’s quite some. And I don’t dismiss anyone stating so.
I’m not claiming no such issues would exist, but the bottom line clearly is these, if so, are edge cases.
And asking for edge cases to be analysed/avoided/worked around upfront, i.e. before they even happen in userland, and even document how to treat them is a request I’m struggling to acknowledge calling it a ‘reasonable’ one. Not testing everything-everywhere-all at once isn’t ‘developer lazyness’, that’s not okay to indicate. I’d call doing so an attempt a waste of precious resources.
Still, just as Rich, too, said:
If you disagree and feel a specific test or docs paragraph is needed or beneficial to a significant number of people, then go for it yourself. We’ll happily add your PR to the docs. We’d even share our knowledge.
But none of us on this thread is taking that ball. And just like Rich I doubt anyone else will.
Not sure if already on the list of features for 5.0, but I would like to have a button to select e.g. all rules in the UI by one click, and not click one, by one. I would like to select all by one click e.g. disable them.
The same would be cool for Things. Select all and enable or disable them by one click.
This is already implemented. I think it was there in OH 4 actually but it’s definitely already in 5. On the Things menu, click on “Select” in the upper right then there’s a “Select all” in the top center and at the bottom options to delete, enable, and disable.
I tried to make a summary of this thread with AI. It failed to create a good summary while using copilot.
I did succeed in creating a proper CSV with all posts, see: openhab_posts3.csv i uploaded it here, maybe someone else can give it another try to create a summary of top 25 requested features.
