Next generation design: A Paper UI replacement proposal

[David_Graeff]

Friday weekly progress update

Changes: + 3886 insertions / - 2466 deletions

• All lists (addons, rules, things, items, scheduled tasks, inbox, …) are now fully dynamic.
  • The content is fetched from a backing store. Just one-step away from a real openHAB instance.
  • Predefined filters work.
  • Prepared for sorting.
  • All actions (Remove, Install etc) are connected to the backing store.
  • A limited amount of items (150) is displayed by default with a “Show more” button at the end. Even large installations should render super fast.
  • A warning is shown if you are currently editing an Item/Thing and openHAB changed the same in the meantime.
• The Thing channel configuration page received some progress.
• A language switcher on the maintenance screen
• A dark-theme switcher on the maintenance screen
• Changed the items layout.
  • By using tabs the overall layout should look more clean on the Items screen
  • A new separate control tab as recommended by a user
• Map component. See usage in the Maintenance->Configuration screen

Next

The following tasks are going to happen next. As I’m doing this in my free time I can’t say anything about the due time.

• Cache system + actual connection to openHAB instance

As usual I’d be happy about contributions (text/images for the tutorial part, design suggestions with screenshots or detailed explanations or even pull requests) or funding.

Cheers, David

[KobiKobsen]

I´m not sure if this is the right place for this kind of bug / ui-reports:

If you are on a long list - for example add-ons and you scroll down and then click on documentation, this content is loaded into the right sidebar but on top of the page. The sidebar should be position:fixed; so it is always in view.

Best,
Mario

[David_Graeff]

@KobiKobsen

The sidebar should be position:fixed;

That’s unfortunately not that easy, because the sidebar is part of a grid layout.
If you can come up with a solution, I’ll happily integrate that.

[KobiKobsen]

Yes I have already checked it but I can help with a solution. I do mostly front-end in my daily job. I am glad if I can assist you. I get back to you tomorrow.

[vespaman (Micael)]

Maybe there should be a companion thread about textual configuration; I am also worried about this being mentioned as change proposals in this thread. To me, textual configuration is a much bigger feature than web UI, and I worry that most of us textual users might not even open this thread. I chose OH because of this feature over other home automation set-ups. This was in the early days of OH2…

While I applaud the effort to update Paper, I just hope the current (or similar) textual configs are not at stake here. (I would see item configurations in multi line as something really worrying).

Just saying.

[David_Graeff]

@vespaman

Maybe there should be a companion thread about textual configuration;

There is: Configuration of openHAB

In the OP there is not a single proposal to remove text files. Where do you get that from?

[vespaman (Micael)]

In the OP there is not a single proposal to remove text files. Where do you get that from?

I got it from your advocating it in this thread.
Just voicing my concerns…

Edit: thanks for the link, it is indeed the companion!

[KobiKobsen]

Hi David, you could use position:sticky on the content element of aside. I think I would add a wrapper div as direct child of aside and apply the positioning to this div.

Only an example:
aside > * { position: sticky; top: 0; }

This has to be modified for your “reload / home” and “close” button also. Sticky-Positioning will work for the most of our current browsers. So I would not polyfill for the older ones as they will ignore it.

[David_Graeff]

@KobiKobsen

position: sticky;

Works really well.

[rlkoshak (Rich Koshak)]

It just occurred to me that there is nowhere to configure persistence in the UI. I suspect this is because there is nothing in the core to support that, but we will need it.

I’m OK with sitemaps going away to some extent, though until and unless the phone apps start to work with HABPanel I don’t know how good of an idea that is. But we need a way to configure persistence.

Should I open an issue on the study, on the core, or wait a bit for the merge with ESH to be completed?

---

This is probably worthy of a separate discussion unto itself, but I really really dislike simple mode. There is so much that is not workable when using simple mode that IMHO it causes way more problems than it solves. Should we do away with it?

---

I love the ability to control Items from the Items page.

---

Similar to the above, there is no way to configure a Profile on an Item through the UI. But looking at the REST API there doesn’t appear to be a way to do it through the REST API either, unless Profiles are stored in metadata. So should I create the issue on the study, the core, or wait?

---

Over all I like the changes and improvements. I’ve opened a few new issues as well for some things I noticed. Great work!

[David_Graeff]

@rlkoshak

Should we do away with it?

That’s out of control of the UI. The core decides if simple mode is on or off. And yes I’d vote for removing that as well. The UI can have a button “Create links for all visible channels” or so. It is really just for UI users anyway, a text file user will not use simple mode.

@rlkoshak

But looking at the REST API

There is. A profile is a “configuration” on a Link. Those can be configured in my design study on the thing channels page like in Paper UI.

@rlkoshak

I’m OK with sitemaps going away to some extent,

This UI should just be for “Setup & Maintenance”. Sitemaps are for the layout of the “Control” part already. A separate sitemaps layout app might make sense or sitemaps should be editable by all apps that can visualize sitemaps, like the iPhone, android and classicUI app.

@rlkoshak

just occurred to me that there is nowhere to configure persistence in the UI. I suspect this is because there is nothing in the core to support that, but we will need it.

I have no idea how persistence works. I have never used it. But I know that there is a REST interface and I agree that it deserves a place in the UI somewhere. Maybe as sub-page within “Maintenance”.

[rlkoshak (Rich Koshak)]

@David_Graeff

There is. A profile is a “configuration” on a Link .

Ah, I was looking in the wrong spot. Thanks for pointing me to the right location.

@David_Graeff

This UI should just be for “Setup & Maintenance”. Sitemaps are for the layout of the “Control” part already. A separate sitemaps layout app might make sense or sitemaps should be editable by all apps that can visualize sitemaps, like the iPhone, android and classicUI app.

One could make the same argument for Rules and Scripts. Sitemaps are required for the phone apps and support for building them needs to be in some UI if we are ever going to get to the possibility for UI only users (to all the text users, I’m not saying to get rid of text based sitemaps).

It’s unclear to me how much long term support there will be for sitemaps in their current form anyway. It uses the same Xtext based parser so if we are going to get to where we can drop those libraries something is going to have to replace the file format at the very least. If it weren’t for the fact that the phone apps are based on them I’d be fine with deprecating them when .items and .things files as they exist now are deprecated. But it will be pretty odd to have a system where everything can be done through a UI but if you want to use the official phone app you have to manually create text configs.

@David_Graeff

I have no idea how persistence works. I have never used it. But I know that there is a REST interface and I agree that it deserves a place in the UI somewhere. Maybe as sub-page within “Maintenance”.

That sounds like a reasonable. While there is a REST interface to interact with persistence there is no REST API I can find to actually configure the persistence strategies. Basically a REST end point to set:

Strategies {
  default = everyChange
}
Items {
        gChart*,gIndoorTemps,gIndoorHumidity,vIsCloudy : strategy = everyUpdate
        gHistory*: strategy = everyChange
}

Save every update to members of gChart, and the values of gIndoorTemps, gIndoorHumidity and vIsCloudy. Save every change to members gHistory.

or

Strategies {
  default = everyChange
}
Items {
        * : strategy = everyChange, restoreOnStartup
}

Save every change to all Items and restore all Items on startup.

It looks like everything else is possible but I see no way to set the strategy.

Also note that one can define their own strategy using a cron expression. For rrd4j everyMinute is a requirement.

Strategies {
    // for rrd charts, we need a cron strategy
    everyMinute : "0 * * * * ?"
}

Items {
    // persist items on every change and every minute
    * : strategy = everyChange, everyMinute
}

Maybe the ability to configure the strategies is under one of the other REST endpoints?

[David_Graeff]

Could you sketch a rough interface for persistence, so that I get an idea?
Seems like the strategy and an item selection, based tags or regex matching is required at least.

@rlkoshak

It’s unclear to me how much long term support there will be for sitemaps in their current form anyway.

There was a PR that changed the storage for sitemaps to jsondb and added REST endpoints as well.
As far as I remember it wasn’t completely finished. But for OH3 it can be picked up as a starter, I guess.

[hilbrand (Hilbrand Bouwkamp)]

All persistence implementations are openHAB 1 implementations (probably explains why you didn’t know them ) I did some fiddling with implementing rrd4j as oh2, but never finished it as I had the impression nobody was looking for it. I might have some code laying around somewhere.
I guess it can be implemented with a specific trigger and some kind of persistence action. But don’t know if that would be the correct approach, architectural wise.

[rlkoshak (Rich Koshak)]

@David_Graeff

Could you sketch a rough interface for persistence, so that I get an idea?

Let me ponder because it seems like there are two parts and perhaps they should be represented separately.

The first part is defining the strategies themselves. Here we have a few predefined strategies (everyChange, everyUpdate, restoreOnStartup) and perhaps some predefined time based ones (everyMinute, everyHour, everyDay) but then we need the ability to create a custom strategy. Cron expressions are used for now.

It seems, assuming the core can support it, that we should be able to define the strategies separately from the next part. Then we can select them from a list.

The next part is mapping Items/Groups to a strategy for a given persistence engine. For example, above map gChart*,gIndoorTemps,gIndoorHumidity,vIsCloudy to the everyUpdate strategy on the InfluxDB persistence engine. I map all my Items to the everyChange and restoreOnStartup strategy on the mapDB persistence engine.

So maybe the UI isn’t so hard.

I gotta run but will post a drawing here later today or tomorrow. My fear though is, as Hilbrand says, persistence is OH 1 through and through and there is no REST endpoint yet to support setting the strategies.

[vossivossi]

@hilbrand

All persistence implementations are openHAB 1 implementations

As persistence is really one of the very strong features of OH it seems funny to see that there are only 1.x implementations. Apparently there was nothing to improve?

[David_Graeff]

@hilbrand

All persistence implementations are openHAB 1 implementations

Can’t we just declare the OH1 persistence interface to be the OH2 one and add some REST endpoints . Those are basically services, aren’t they. So they just need a service description xml file. But yeah I really have no idea, never seen the code.

[hilbrand (Hilbrand Bouwkamp)]

Its probably because, If I’m correct, there is no oh2 way to configure them and no specifications that I know off on how to do it the oh2 way. Which would explain why there are no oh2 implementations. If that is in place it can be implemented as oh2 , which does include copying most of the internals of the presistence implementations as there is probably not much to improve.

[5iver (Scott Rushworth)]

@hilbrand

Its probably because, If I’m correct, there is no oh2 way to configure them and no specifications that I know off on how to do it the oh2 way. Which would explain why there are no oh2 implementations.

There is an ESH MapDb persistence bundle.

@hilbrand

which does include copying most of the internals of the presistence implementations as there is probably not much to improve.

There are also a number of OH2 item types that are not supported (Player, Image, Location, etc.).

[unparagoned]

@David_Graeff

A big concern at the moment is that we have a dual system of configuration. You either use the UI or files. And you cannot change to the other option without a massive time investment.

Please have a look at how I see this solved. Every thing/item/rule/timer has a “storage association” (aka filename). The backup service will consider those for exporting to several storage units (aka files).

Every thing/item/rule/timer has a list, grid and textual view mode. The latter one allows find/replace, batch editing. For the format I have settled on YAML for now. Please have a look and tell me if you like that syntax. Maybe there is a better suited format that I have not yet considered.

The current way openhab is kind of special and very confusing. Paper UI items and things are completely different to the config items. Since bindings use the paper ui setup, but if you want to have any non-trivial setup it’s really confusing to try and work with the two completely separate setups. The config files should mirror the paperui items, and vise versa. It took me months to understand why paperui wouldn’t let me edit some config items.

I used YAML with homeassistant and hated it. I thin the main issues was that it’s all based on whitespace which is hard coming from a c background, and the fact I didn’t have an editor which raised any issues. You also had to restart oa after any changes so it was just too much of a pain in the ass. But if there is proper vscode support for the syntax then it shouldn’t be so bad.