I’m, looking for features for my more than one time usage, e.g. “select all rules”, or select all things, enable, disable.
Or having a feature to export a rule to a file and import it on a other system.
Or having possibiliy to backup only things, or rules, all or only selected once.
Background: I have three 1:1 systems. One has all the rules active. So when making a 1:1 backup from the configuration on my PRO System, and copy the backup to the TEST System, and restore the backup, I have all the time to select 90 rules and disable them by hand. So it would be nice, to have a “select all feature” and by one click disable them.
Or I have implemented a new thing, e.g. a shelly switch, I have to do this three times manual.
So it would cool, to do this only one time, and the backup this thing a restore it on the other machine.
The same for pages. I need to generate a new page on every machine. So export the new “icon”
on the homepage UI and restore on the other machine would be cool.
Or the new logfile viewer is very hard to mark some lines and copy and past them in a normal browser. The save to CSV is nice, but then I have to open Excel…
Here it would be also cool to have a feature for logging. So like a watchdog.
Then something happens in the log, e.g. set the tracelevel to debug, and e.g. record all for the next 1min…
When something happens which I cannot start or simulate, I have to sit there watch the logfile viewer and wait until this happens.
So keep three “dogs, or cats” under the some control is more work, that only one
All stuff could be a wishlist for 5.x.x
In the mean time, to disable all your rules it’s just a couple lines of JS you can run from a script.
var { ruleRegistry } = require('@runtime/RuleSupport');
ruleRegistry.getAll().forEach( r => rules.setEnabled(false, r.getUID().toString() );
Note this will also disable Scripts and Scenes. You can put the above in a script you run maunally to disable all the rules in one go. -Scratchpad- is a special Script you can get through the Developer Sidebar which is perfect for this sort of thing.
Note, this is advanced rules stuff and I wouldn’t expect the average user to figure these out or even need them. But you are doing advanced level stuff so you need them.
This is already possible. I don’t know when it was added. Navigate to the Things page and click “Select” in the upper right.
At the bottom you have the option to enable/disable/copy/delete.
The same is true for Items and will be true for rules when the PR above gets merged.
The restore part isn’t quite there except for Items. But I suspect it would be added if someone opened an issue to request it. So OH 5 around half way there.
But now you can get a “copy” of any individual Thing or Item from that entity’s page. You have to option to get it in the new YAML format or traditional DSL.
On the Things or Items pages you can select multiple or all Things or Items and get a copy of all of them in one “file” (copied to the clipboard) in either the new YAML or traditional DSL format.
To have a better option for backup and restore, you can get all the Thing, all the Item, all the Rules et al as JSON using the API Explorer. Copy that JSON from one and then use the API Explorer on the other instance to import that JSON. Each type of entity needs to be done individually (i.e. all Items, then all Things, etc.).
It would be kind of handy to have an “import from clipboard” option when clicking the + icon. Then you could get a copy of all your Things in one browser tab, go to the other browser tab with the other instance running and import them all.
It depends on what you mean by “backup” but these are all already stored separately. If you just want a backup of all your Things, back up /var/lib/openhab/jsondb/org.openhab.things.Things.json. And of course, you can use the select all → copy described above to paste them into a text file for backup.
But again, the restore isn’t there yet. But the files can be used as is so it’s possible to have a fully managed config on your testing/development instance and then export everything to files using the “copy” option for your production instance. For now though this will only work for Things and Items with Rules on the way and everything else coming eventually. The overall goal is to have a way to do everything that can be done in the UI though the new YAML file format but right now only Tags, Items and Things are supported.
For a long time now there has been a “Duplicate Thing” option. Create the one Thing as normal then at the bottom of the Thing’s page there is a “Duplicate Thing” option which will create a new Thing and let you edit just the stuff that’s different. You don’t need to manually create each Thing 100% from scratch.
This is a different use case. But backup and restore of an individual Thing was discussed above.
Pages and Widgets are not as portable. However, all of that stuff is saved in the JSONDB in the files that start with uicomponents. You can copy all pages, or sitemaps, or widgets, etc. by copying those files.
For individual ones, click the code tab, copy the YAML, then create a new on the other instance and paste the YAML. Not great but until he new YAML format is extended there isn’t another option yet.
One of the additions in OH 5 is a new text only mode. It should be easier to copy lines and parts of lines that way:
That’s the icon selected on the far right to switch between the two views.
This can be done with a rule.
If the event is something that can be used to trigger a rule (e.g. a Thing going offline) use that trigger a rule. If not and it’s something that appears in the logs, use the LogReader binding to watch the log and trigger the rule. Then use a condition to further narrow down the event (you can trigger the rule for all ERROR log statements but need to narrow it down if you want a specific ERROR log statement to trigger the rule). Then it’s just two lines of JS to set the logger level and set it back in a minute.
Use org.openhab as the logger name and all of openHAB will go into TRACE level logging.
If it’s not something that can be used to trigger a rule, even with LogReader, well there’s really nothing that OH would be able to use to do it from the log viewer anyway.
Doing stuff like this is one of the major reasons why file based configs are and will continue to be supported. Even if all of the above were 100% implemented, a file based approach is always going to be more amenable to this sort of use case than managed configs.
There is still a long way to go for sure, but there has already been a lot done that is in OH 5 to make most of you use case easier.
It nearly got, but I wasn’t able to review before the feature freeze, and I didn’t want to risk breaking anything wrt to the search in the rules page.
There is a Draft PR in core introducing new API endpoints to allow the UI converting between DSL, YAML and the REST API representation of Items, Things etc.
This will allow the UI to align its YAML format with in the code tab with the YAML format of the YAML config files, and with this we can also add a add from YAML functionality and replace our small DSL parser implementation with openHAB core‘s.
it’s over on kind of you that you’re trying to find answers here for all my inquiry. Really thank you very much for this.
That helps. So, I was not aware, although I have been using OH since version 2.x, that I can select all items. I’ve never seen that before. In other words, it is once again so hidden in the UI that you don’t see it right away.
The fact that there is a GitHub entry on the topic of rules is also great. But the average mortal doesn’t think so. Again, I expressed my desire to implement the Select all features.
The fact that you make me a suggestion on how to program is great, but it is not really an innovation in the UI.
All roads lead to Rome, but I would just like to take the shortest and fastest way, as I may not have the time and leisure for the beautiful country roads.
So I stick to seeing all my suggestions for simplification in the UI for 90% of users. I realize that without programmers and that’s how I mean the editing of files, it doesn’t work for one or the other. But that cannot and should not be the solution for the average consumer.
Why do I love the OH so much? Well, it simply offers me, as a non-developer, the opportunity to do what I would have needed to train as a programmer in the past. So a system like OH is becoming popular and more and more users are finding its way into it. The concept with binding is great, but it doesn’t help if it can’t be used.
Take Broadlink Binding, for example. I think Anton does a brilliant job here, but if it takes 10-15 steps to teach a single command of a remote control, it is questionable whether this is really user-friendly. Technically, it works, but how, when, what, where is necessary is far too complicated.
Again, I’m glad that it works 100%, and I’m happy that Anton did it and even works after the update from 4.3.6 to 5.0.0, but I won’t install it beyond two commands, because it’s really not fun in the current handling.
Therefore, my request to everything OH to continue to develop, but to make it easier for the normal mortal user.
Another personal example. I was involved in development at Nokia Mobile Phones for more than 20 years.
In my time, Nokia had a world market share of 43% of all mobile phones sold. Why is that no longer the case today? It’s not like that anymore, because Apple did NOT have the better technology, we already had Symbian as an OS with touch and had language dialing, or our battery lasted two weeks, no, it was the simplicity of the mobile phones that suddenly every mere mortal could do things for which he had to be a programmer years ago as I said or go deep through menus. Nokia is history. I hope that OH does not suffer the same fate. Our competitors such as ioBroker, IFTT, or HA, “also have beautiful daughters”. According to the Internet, HA has about 500,000 installations. I don’t think we have that many.
So why are they so successful here? Maybe since they have a simpler UI?
Look at new cars. In the past, you had a switch/regulator for everything. Heating on, how fast should the fan turn, sunroof open / closed. etc. Today? 27,000 menus for every possible function. I was recently present at the delivery of Mercedes vehicles. Do you think older riders understand the complete MBUX? Where, how what is to be set. Can voice control be the solution? This is also anything but reliable. My Benz also talks to me, but can he move the seat forward or backward by voice? No, I must use buttons again. But I can open the sunroof in % steps, WOW…
I can even store rules in MBUX… Do I need that? How did I do this in the past? Questions upon questions…
So here again the appeal to further develop OH, and to focus on simple UI and other features in upcoming releases, which help users to implement personal wishes faster.
But this is out of scope here. It is an „issue“ with the binding and should be solved there. If changes in the UI or core are needed for a solution, Binding developers should address this in the repositorys in Github.
I would not call it hidden if all you need to see the “Select all” button is to open the selection menu … IMO that’s quite a logic place to put select all.
I think the big thing missing to address @scheuerer’s use case that is not addressed by that draft PR though is files. A way to export to file and get a YAML file back instead of just copying to the clipboard. Then have a way to import that file or the contents of the clipboard on another OH.
That’s the part I was thinking about to open an issue for, because I don’t think that’s captured by the current PR. Of course, it would depend on the draft PR being merged first I think since MainUI would need to ultimately translate that file or DSL into JSON to make the REST API calls to create/update the entities.
I’ve never liked how UI elements get hidden. But I’m not the designer and there are challenges making a UI responsive from massive monitors down to narrow phone screens. It is what it is I guess. But this “click select at the upper right to select more than one” has been there since the beginning in OH 3. It’s not some new feature snuck in. It is covered in the docs (e.g. Settings - Things | openHAB):
Delete Things
Select multiple Things using the top Select button and use the Remove buttons at the bottom or use the Delete Thing button on the individual Thing pages.
Enable/Disable Things
Select multiple Things using the top Select button and use the Enable or Disable buttons at the bottom or use the pause button on the individual Thing pages.
It’s not merely an entry. The code is written and done, only awaiting review. Once that PR gets merged the feature will be part of OH from that point going forward.
No but it helps solves your problems right now until that feature does get added. Or you can just continue to click on 90 rules and disable them one by one.
Running separate development, test, and production instances of openHAB is not something the average user is doing. It’s not even something most advanced users are doing. It’s not fair to come up with some very complex and advanced configuration and then complain it’s too hard for the “average consumer”. Especially when your argument is using examples and advocating for simpler UIs. Apple’s solution for this would be “sorry, you can’t do that.” Is that the better answer? Are you willing to give up use cases for a simpler experience?
Or is the better answer “here’s how you can do it most efficiently now, and we are actively working to make it easier in the future.”
So this thread isn’t about how you can improve your personal work flow using what is already available, some of which you may not have known about. It’s just a place to complain. Got it.
My only goal is to help users make the most of OH that they can with what exists today and point out what is actively being worked on to improve things in the near future. If you just want to complain that it’s not good enough I need not waste my time on that. I’ll just say “yup”.
Nothing I point out about what you can do with it now or what is actively being worked on is ever going to matter. OH is never going to be good enough. And you are apparently not interested in actually addressing your own problems with what exists now.
This is the most frustrating part. We do! We didn’t release OH 5 and say “Now it’s perfect! We are done!”
The way that selection works in MainUI is not super intuitive. So I sympathize with @scheuerer on that point. You can’t really just look at the UI and understand what can be done on that page.
The “Selection” element really isn’t a menu though. It changes the whole UI to a different mode.
It’s not intuitive to think to look in the upper right of a screen for something functional or something that changes the whole way the current UI works. That’s usually where stuff like Help and Exit go.
Furthermore, until you actually start selecting stuff, it’s not clear what you can do with the selection because some of those buttons are hidden until you select something that the button can do (this is mostly on the rules page right now).
It’s certainly not the worst design in the world, but it is also not the most intuitive. You basically have to already know it’s there and what it can do before you can actually see the UI elements that do it.
Because these are lists that can be clicked on, I’ve always wondered why we couldn’t use the usual conventions. ctrl-click to start and add individual elements to a selection, shift-click to add everything between what’s currently selected and the new click (and the mac equivalents of course), on a phone using long press to start the selection process the short clicks to add to the selection. That’s how it works from everything from file browsers to podcast players to spreadsheets. It’s how we all have been trained to interact with lists, but we can’t do it in OH. There we have to click a word in the upper right corner to change the UI mode to selection mode. It’s different and therefore not intuitive.
I have a vague recollection of trying to make these arguments way back in OH 3 to no avail, so I’ve just lived with the way it is. And again, it’s not horrible, jit’s ust not as intuitive as it could be.
That is kind of a catch-22 though. To know that the ? icon exists up there you have to know to look up there. And if you’ve looked up there hopefully you see the “Select” link there already. It may or not be apparent that it’s a clickable element though, because it’s just a word.
If I don’t know anything and I just open the Things page. If I don’t think to look in the upper right corner, a place where usually functional UI elements are not placed, I wouldn’t see the context sensitive help either.
I do realize that I’m arguing both sides of the case here.
But if I go a few months without using this feature, even I with all the years of experience I have, I end up searching all around the page, scrolling to the bottom, etc. until I remember it’s in the upper right corner to enable selection. This just happened last week when I wanted to experiment with the new rule template stuff. I spent a couple minutes at the bottom of the page trying to remember how to enable multiple selection.
If I forget, there has to many users who never learn, especially if they don’t read the docs, and no one really reads all the docs. I at least have the advantage that I know I need to click “Select” to enable selection mode.
Yep. I forget too, but that’s mostly because I just use the ctrl + click shortcut. And I’m not sure that’s mentioned anywhere except maybe one old post from Yannick around the beginnings of OH3.
Ctrl+Click on (my) mac, defaults to right click, so I never knew about this
What I think it should do:
Display the checkboxes all the time
When the row is clicked, go to the item, the same way if the selection mode isn’t active right now. I might refine this further, so don’t criticise this detail yet.
Only “tick / untick” the checkbox if the checkbox itself is clicked. Or maybe the whole “checkbox column / box”, so you don’t have to be super precise.
Display “select all / deselect all” all the time. Or maybe add a checkbox in the column header to do that, similar to gmail inbox. Maybe in addition to the words “select/deselect all”.
Remove the “Select/Done” in the top right corner as it will no longer be necessary
This is similar to e.g. Amazon shopping cart.
Furthermore, to allow shift+select to select the range from last click to now, we need to add “current selection” on the last clicked item and make it visually identifiable, e.g. a slight highlight.
But: this may make it harder for phone UI - have to think about this too.
Personally, I really like the current way that these two functions are separated. I am not only not “super precise”, I barely achieve marginally precise on a good day. I work with too many other interfaces on a regular basis where I accidentally select when I mean to activate and activate when I mean to select.
I agree that the way to switch between the two modes could be made more visible/intuitive/flexible or a hint about ctrl + click could be added directly to the page, but I’m not sure that revamping the entire behavior is currently the best solution.
Edit: All (I think) of the configuration pages have the lower left corner open for a FAB that could control selection mode and quick action select/deselect all.
Is there a way to search using the developer tool find that I could find multiple words?
Example lowbattery and control?
Is there an AND or OR function in the search?
I had to change a lot of these the other day after migrating to version 5 and it would have been easy if I could do that as the ones I changed would disappear from the list as they wouldn’t have the 2 words that I was searching in them anymore.
Currently not, but it can be implemented. I’m starting to work on it for the developer sidebar, but it can/should also be done across all searchbars for consistency.
Pinning the Items will prevent that. That also gives you more control over what you can do and see from that Item in the sidebar.
To simulate an OR you can search for the first term, pin those entities, then search for the second term and pin those. Clear the search and you have access to all the pinned entities with the ability to control them from the sidebar.
That’s not to say an AND/OR feature in the search function wouldn’t be helpful.
For the Developer Sidebar: Here is a PR to support and (space separated), or (using pipe |), exact search (="exact phrase"), negation (!excludeme), etc.
Check the link in the PR for the full syntax.
A simple feature suggestion:
Enable users to set an add-on’s log level to OFF from the UI.
While all other log levels can already be selected there, turning an add-on completely silent still requires the Karaf console.
