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

There is the ‘"’ button (“pause”) on the Thing page, what’s not sufficient with that?

Aah. Very cool. I have used it many times but never thought of using it for this purpose .
Thanks for the tip.

I created a PR to add it to the JS docs. Update README.md to include file extension by rkoshak · Pull Request #18230 · openhab/openhab-addons · GitHub

In MainUI from the Settings → Things page click Select → the Thing you want to disable and then disable at the bottom.

Or from Settings → Things → Thing you want to disable click the pause button (which is what @mstormi is referring to).

Or from the Developer Sidebar (alt-shift-d) search for the thing, pin it and click the pause button there.

image

Or in a JS rule or script use the line:

things.getThing("uid:of:thing:to:disable").setEnabeld(false);

jRuby has a similar line. I don’t think this is a block to do this through Blockly, but one can use the inline script block with the line from above, and it’s definitely not possible through Rules DSL except by calling the REST API.

1 Like

Please add an energy dashboard like HomeAssistant has - this should come out of the box without fiddling around yourself, thank you!

Demo link: Home Assistant Demo

5 Likes

This dialogue here (when adding a cell etc.) should be a list where you can filter - if you have a long list of widgets, the navigation in this endless list is really annoying:

2 Likes

Also sorted?

Okay, let’s set up a whish list for Santa:

  • It should be a list with headers, where you can sort asc/desc based on the name
  • The list needs two columns: name of the widget and type (standard/private)
  • There should be filter for the name and the type available
    :slight_smile::

YES!

I don’t mess with the UI much and when I do I apply the widget as “default standalone widget” metadata so end up using “add from model” to get around this. But this list is really annoying if you have more than just a few widgets. Any of the mentioned suggestions should help. Being able to filter on tag could also be nice though that can just be to make the search tag aware.

2 Likes

Something else:
Renaming of items (the technical names)

Would be useful sometimes - and would be also okay to have it as separate function in the backend.

I’ve been thinking about this for a long time.

  • Rename item
  • Rename Thing + channel
  • Rename rule uid → although this can be done by creating a copy
  • Rename page id → I’ve submitted a PR to create a copy, so ditto

It’s do-able. Yes, the related links and metadata will need to be updated, but rules won’t be.

You can already create a copy of existing Items and Things.
Just create a copy, give it a new name and delete the original, but don‘t forget to unlink it first…

Display system time next to the date on Overview page.

Yes, this is possible - but all persisted data is gone then too :frowning:

You just need to rename the persistence files to the new name.

I use InfluxDB. Never done a rename there; is it possible at all? Thanks!

This is a complete different story.
Even if there will be a way to rename an item directly in openHAB, it would not directly rename anything in influx.

Yeah, this is a problem. @mherwege, how hard would it be to add item renaming api to persistenceextensions?

Depending on the amount of persistence data that needs to be modified, the operations sometimes don’t complete but time out … when I renamed items, I did rename the data through the InfluxDB console in one-year slides.

There might be another possibility. Instead of renaming in persistence, we could change the alias without changing anything in the storage itself. The alias has been there for a long time, but currently does not work properly. But I have an outstanding PR to start fixing that. This would also work for non-modifiable persistence services.

See Persistence aliases by mherwege · Pull Request #4363 · openhab/openhab-core · GitHub

I can see building in that PR to automatically set an alias when changing the item name. There is one constraint that the old name still needs to be unique. So we may have to refuse changing if an alias already exist pointing to that name. But in a second step, one could go in the underlying DB, change the name there (and that is service specific) and remove the alias, all manually.

How difficult is it, to implement for openhab version 5 two different internal IDs?
Say one is a GUID which is not visible to the user and links to other tables/databases and one which is visible to the user (what we have today as the item name), but can be edited. Does that make sense?