Smarthome: Basic UI: value format lost on update

[kaikreuzer]

migrated from Bugzilla #483466
status NEW severity _normal_ in component _UI_ for _---_
Reported in version _0.8.0_ on platform _All_
Assigned to: Project Inbox

On 2015-12-02 07:07:05 -0500, Markus Rathgeb wrote:

If you navigate through the basic UI and an item is rendered the first time, the value is shown as expected (e.g. with unit etc.).
If the state of the item is updated and the UI is updated, only the new value is shown, the unit is lost.

Example:
The channel configure its patter this way:
The state is: -1.8
First the state is shown this way: -1.8 °C
After an update the state is shown this way: -1.8

[maggu2810]

@resetnow Have you seen this one?

[resetnow]

This is a known bug. Element values are updated through AJAX requests and Server-Side Events (SSE). As of now, these events do not provide any information about formatting or visibility of the widgets. This is most likely going to change in the future when sitemap-related event support is implemented. It also applies to a problem when widget's visibility is not updated until the whole page is reloaded.

[kaikreuzer]

Right, so we should think about adding specific events for widget changes, which the Basic UI should then pick up.

[lolodomo]

Really no chance to fix this annoying issue ?
It makes Basic UI not pleasant to use...

[kaikreuzer]

There clearly is a chance (see #674), we are merely lacking people who invest time to implement such features...

[foxytocin]

Also not working:

Items - String  Gui_Innentemperatur_Aussentemperatur    "Temperatur [%s]"
Sitemap - Text item=Gui_Innentemperatur_Aussentemperatur icon="temperature"
[WARN ] [ternal.render.AbstractWidgetRenderer] - Cannot escape path '2016-04-11T06:36:00.000+0200' in URL. Returning unmodified path.

That what's inside of the string item: Displaying 2 Values in one string.
sendCommand(Gui_Innentemperatur_Aussentemperatur, Temperatur_Wohnzimmer_Wand.state.format("%.1f")+ " °C / " +Wetter_Temperatur.state.format("%.1f")+ " °C")

Working finde with OH-App on iPhone, but not in designer or basic ui

[resetnow]

@foxytocin this is probably a separate issue, could you please create one?

[resetnow]

Also, I have tried to do something with this issue and I need to ask somebody (@kaikreuzer ?) whether or not my approach is acceptable.

1. Create a class implementing an EventSubscriber interface
2. Bind OSGi reference addSitemapProvider to keep track of the sitemaps
3. Keep a dependency map (item → widgets) based on visibility and color properties in the sitemap
4. Listen for ItemStateEvents. Send sitemap events with formatted widget values to the event bus.

[kaikreuzer]

Thanks @resetnow for spending your thoughts on that - I meant to implement it already all the time, but also noticed that it isn't as straight forward as initially thought and hence I never found the time yet to do it properly.

Your approach is in-line with my initial thoughts, yes. The problem that I am seeing here is that this would result in a terrible huge number of widget events (both on the OSGi event bus + through SSE). I therefore think that we need some logic to only create&send those events, if they are really needed.
My thoughts were that the UI should subscribe to a sitemap and only then such events are created&sent (until an unsubscribe or timeout). This is not necessarily nice, but I think necessary. Anyhow, this solution should be only used by the Basic UI and on the long run we will hopefully have the new sitemap concept with some proper eventing as an integral part of it.

[metbril]

+1 for resolving this. This is a showstopper for me actually migrating to OH2

[resetnow]

Just for the record, I tried to implement sitemap events the way I have described it earlier and it turned out to be a horrible mess of hashmaps, sets and workarounds so I abandoned it. I think I just don't know the internal architecture of ESH well enough to implement a more efficient solution which will not lookup the widgets by the item name every time some event happens (e7fe038960725981f95c34121c9607a6779ad3ab, c368344c674b26f5d016faadefa450df7c0de701)

[cajuncoding]

+1 for getting this resolved sometime. I'm just getting OpenHAB working and I stumbled upon this annoying bug within the first day of creating a small sitemap with the current date/time being displayed.

[kaikreuzer]

I agree. Will try to come up with some suggestion in the next two weeks and implement the server side, so that @resetnow can finally get that done in the UI.

[kaikreuzer]

@resetnow I have spent some thoughts on this and would like to have your feedback before going to implement anything.

My assumptions are:

• When navigating to a new page, you always do a request like /basicui/app?w=FF_Bath&sitemap=demo.
• It is enough to receive updates for widgets of the page that is currently shown.
• You only need the SSE connection for receiving updates of page/widget infos.

If this is correct, my suggestion would be to:

• Create a new url where you can subscribe for sitemap events through SSE. The first information that this SSE connection will give you is a subscriptionId. This is valid as long as the SSE connection is established - it is more or less a session id.
• You pass this subscriptionId as an additional parameter to the HTTP requests when you change a page.
• This will have the effect that the SSE events that are sent are now only events for the page that you have requested last.

I should be able to implement the server side for such a behavior. If this meets your requirements, that would be perfect. I hope I do not miss anything relevant...

[resetnow]

@kaikreuzer Yes, this will decrease the traffic on the SSE connection and
shouldn't be hard to implement client-side.

I assume this change would also introduce widget-related SSE events?

[kaikreuzer]

Yes, that's the idea - to send widget events that contain the same information about the widget as you get when requesting a complete page.
We might also require an event to trigger a full page refresh for cases where widgets disappear or are added (based on their visibility). I think a full refresh is the simplest solution, introducing events for added and removed widgets and their positions might become a bit too complex.

[kaikreuzer]

FTR: I have started some implementation in my fork, see https://github.com/kaikreuzer/smarthome/commit/c2af196a018a4bc2293d35b4a26fedee7cfdc622.
Still some work to do, but I hope this goes into the right direction.

[digitaldan]

FYI this will make it much easier to get the android client using sse as well

[kaikreuzer]

Right, I am designing it in a way that it is also consumable by the native (also iOS) clients which use merely the REST API (and thus we can get rid of the long-polling-fake solution for sitemap refreshs).