Basic UI: Player widget doesn't update automatically

[michaeljoos72]

Hi

In the new ESH builds automatic update of Sonos-Controller (Play, Pause) doesn't work anymore:

Player Sonos_Controller "Controller" (Sonos) {channel="sonos:PLAY1:living:control"}

sitemap demo label="Main Menu"
{
Frame label="Sonos" {
Default item=Sonos_Controller
}
}

To update the status a page reload is needed. Most probably it belongs to this issue:
https://github.com/eclipse/smarthome/issues/640

BR
Michael

[kaikreuzer]

I can confirm the issue. I can see the events correctly being received by the Basic UI, so I assume this is something for @resetnow to fix.

[kaikreuzer]

Note: This is completely unrelated to Sonos, it is not required to actually use any binding on the item/widget in order to reproduce it.

[vlad-ivanov-name]

I wasn't aware of existence of the Player widget. I assume next/previous buttons should also be non-selectable?

[kaikreuzer]

REWIND and FASTFORWARD are both states - so if this item is in one of these states, the according button should appear selected. The other two states of the item are PLAY and PAUSE.

[vlad-ivanov-name]

Ok, I found the problem, for some reason event widget ID and the id assigned when a page is rendered are different. I can see a numeric widget id in the event but at the rendering time itemUIRegistry returns item name as ID here:

        // if the widget is dynamically created and not available in the sitemap,
        // use the item name as the id
        if (w.eContainer() == null) {
            String itemName = w.getItem();
            id = itemName;
        }

[vlad-ivanov-name]

@kaikreuzer when a default widget is resolved to an actual widget type (resolveDefault in ItemUIRegistry.java), parent reference (eContainer) is lost. Should WidgetImpl be extended with setParent(Widget parent) which would call eBasicSetContainer?

[vlad-ivanov-name]

@michaeljoos72 as a temporary fix please consider using a Switch with an explicit mapping:

Switch item=Sonos_Controller mappings=[PREVIOUS="⏪", PAUSE="⏸", PLAY="⏵", NEXT="⏩"]

[xsnrg]

This might be a larger issue as I am seeing similar issues in BasicUI after #640 was merged. https://community.openhab.org/t/icons-no-longer-updating-in-basicui/15199/1

[lolodomo]

Is it something now resolved ?
I just tested with snapshot 554. My sitemap is defined like this:

Default item=SonosChambreControl

and I can confirm that the item state is updated automatically in Basic UI when I play with it outside (with the Sonos application).

[vlad-ivanov-name]

@lolodomo are you using Internet Explorer or Edge by chance?

[lolodomo]

@resetnow : no I am using Firefox on Windows.

[lolodomo]

I just tested, it works for me in android chrome too.

[vlad-ivanov-name]

@lolodomo did you use Default sitemap item type? Because I don't think the problem with Default was solved

[lolodomo]

@resetnow : here is how is defined my item:

Player SonosChambreControl "Sonos dans la chambre" (GMusiqueChambre,GVoice) {channel="sonos:PLAY5:chambre:control", autoupdate="false"}

and a snippet of my sitemap:

sitemap maison label="Accueil"
{
	Frame label="Audio & vidéo" {
		Text label="Musique chambre" icon="none" {
			Image url="http://ausdroid.net/wp-content/uploads/2014/12/Sonos-Logo-640x324.jpg" item=SonosChambreAlbumArtUrl
			Text item=SonosChambreArtist visibility=[SonosChambreArtist!=""]
			Text item=SonosChambreTitle visibility=[SonosChambreTitle!=""]
			Text item=SonosChambreAlbum visibility=[SonosChambreAlbum!=""]
			Text item=SonosChambreDetails visibility=[SonosChambreDetails!=""]
			Default item=SonosChambreControl
			Switch item=SonosChambreMute
			Slider item=SonosChambreVolume
			Switch item=SonosChambreStop mappings=[ON="Stop"]
			Switch item=SonosChambrePlayqueue mappings=[ON="Lecture file"]
			Switch item=SonosChambreShuffle
			Switch item=SonosChambreRepeat mappings=[ALL="All", ONE="One", OFF="Off"]
		}
	}
}

Sp yes I use default in sitemap.
I don't know if it is important but it is not the first element of my frame.

[lolodomo]

Just tested, it does not matter if the player is the first element of the frame or not.
Even if the player is alone in the frame, it works for me.

[lolodomo]

@resetnow: ok, I finally reproduced the issue, it only occurs when the player is on the main page.
When in a sub page, it is working as expected.

[lolodomo]

I am aware of your issue #2370 but how do you explain that it works when the default element is not in the main page ? Is this something that could help solving the problem for the main page ?

[vlad-ivanov-name]

If you already have your setup you can check if the player on the main page and subpage have different IDs (in HTML code)

[lolodomo]

In the two cases, I see data-widget-id="sonos_control" while "nonos_control" is the name of my item.
So it is compliant with your analysis, we get item names rather than numbers for widget ID.
But still it does not explain why it works in one case and not in the other.

[vlad-ivanov-name]

This probably means SSE events are different in two cases.

[lolodomo]

For the sub-page, I can see the following HTML code:

<main class="mdl-layout__content mdl-color--grey-100">
			<div class="page-content mdl-grid">
				<div
	class="mdl-form mdl-form--no-label mdl-color--white mdl-shadow--2dp mdl-cell mdl-grid mdl-cell--12-col"
	data-widget-id="%widget_id%"
>
	<h5 class="mdl-form__title mdl-cell mdl-cell--12-col">
		
	</h5>
<div class="mdl-form__row mdl-cell mdl-cell--6-col mdl-cell--8-col-tablet ">
	<span class="mdl-form__icon">
		<img data-icon="switch" src="../icon/switch?state=PLAY&format=svg" />
	</span>
	<span  class="mdl-form__label">
		Player
	</span>
	<span  class="mdl-form__value mdl-form__value--group">
		
	</span>
	<div
		class="mdl-form__control mdl-form__buttons"
		data-control-type="buttons"
		data-item="sonos_control"
		data-has-value="false"
		data-count="4"
		data-widget-id="sonos_control"
	>

The parent (div) has data-widget-id="%widget_id%" meaning there is no substituion. Is it normal ?

In the main page, the parent (div) has data-widget-id="04"

[vlad-ivanov-name]

Ok, maybe something changed from the last time I looked into it, I'll check again.

[lolodomo]

If I add a frame in the sub-page, it does not work anymore. So the problem seems to be the presence of a frame.
In the following example, only the second is correctly updated.

sitemap demo label="Main Menu"
{
    Frame label="Player" {
        Default item=sonos_control
        Text label="subpage" {
            Default item=sonos_control
        }
        Text label="subpage" {
            Frame label="player" {
                Default item=sonos_control
            }
        }
    }
}

[lolodomo]

I have the feeling that "Default" add an intermediary frame with no widget id. Or maybe that is the "Player".

I see no renderer class for the player, neither HTML snippet. Where is it ?

[vlad-ivanov-name]

Look up resolveDefault in ItemRegistryImpl

[lolodomo]

The code that adds a frame around children is here: https://github.com/eclipse/smarthome/blob/master/extensions/ui/org.eclipse.smarthome.ui.basic/src/main/java/org/eclipse/smarthome/ui/basic/internal/render/PageRenderer.java#L107
It is probably normal. But the "frame" snippet is used here without setting a widget id. Is it a problem ?

[lolodomo]

I can confirm that the problem is the widget id in the SSE event which is correct only in one of the 3 described cases:

• 0500 (page demo)
• sonos_control (page 0501) => OK
• 05020000 (page 0502)

[vlad-ivanov-name]

Events with numbers are actually correct and the one with item name isn't. Item name is used because when default widget is resolved to an actual widget, parent object reference (in EObject) is lost.

[lolodomo]

Ok, so the case that is working is in fact due to a double error, one in the SSE event and one in UI.

The widget id in sitemap event is ok when there is a frame probably due to this: https://github.com/eclipse/smarthome/blob/master/bundles/io/org.eclipse.smarthome.io.rest.sitemap/src/main/java/org/eclipse/smarthome/io/rest/sitemap/internal/PageChangeListener.java#L176

[lolodomo]

Do you know why this particular test on Frame is required in constructSitemapEvents ?
Are the widgets inside the frame not yet in the list of widgets ?

Edit: I understand why now ;) "Frame" is the only case where you have to go one step deeper.

[lolodomo]

This particular case with Frame in constructSitemapEvents explains why we have a correct ID in SSE event when the default element is inside a frame. In this case, the original widget is considered, not the "resolved" widget.

[lolodomo]

@SJKA @kaikreuzer : please close this issue, the merged PR #3471 fixed it.