Selection and visibility are not refreshed in Basic UI - Similar to closed issue #165

[riegelbrau]

I am running openHAB latest (3.3.0) in Docker on a Synology NAS.
My sitemap "vclient" has three selection items with mappings and two setpoint items that are displayed depending on visibility parameters. Until around 2 weeks ago this sitemap was running like a charm in Firefox and in the Android App. A few days ago suddenly the selection entries and the visibility were not shown as expected. After waiting for some time the changed values appeared, may be related to a sitemap refresh from other items? At first I stripped down the number of mappings entries with no success. Then I isolated the desired frame into a separate sitemap but the issue persists. I checked several configurations like double quotes vs. no double quotes in the visibility and mapping entries, but nothing changed.
While searching for similar issues I found this closed issue #165, that describes exactly what I am facing. As written there I restarted openHAB and the issue was gone, the changed values appeared immediately. But only a few seconds or minutes later the same effects re-ocurred. This is the reason I open this issue.
Please see my vclient.sitemap here:

sitemap vclient label="Vclient" {
	Frame	label="vclient" {
		Selection	item=vclient_commandType		mappings=[get="get",set="set"]
		//Selection	item=vclient_commandGet			mappings=["getTempWWsoll"="TempWWsoll", "getBetriebArt"="BetriebArt", "getTempVListM1"="TempVListM1","getTempRaumNorSollM1"="TempRaumNorSollM1","getTempRaumRedSollM1"="TempRaumRedSollM1","getIsEinmalladung"="IsEinmalladung"]	visibility=[vclient_commandType == "get"] 		
		//Selection	item=vclient_commandSet			mappings=["setTempWWsoll"="TempWWsoll","setNiveauM1"="Niveau","setNeigungM1"="Neigung","setTempRaumNorSollM1"="TempRaumNorSollM1","setTempRaumRedSollM1"="TempRaumRedSollM1","setEinmalladung"="Einmalladung"] label="Set Befehl"	visibility=[vclient_commandType == "set"] 
		
		Selection	item=vclient_commandGet			mappings=[getTempWWsoll="TempWWsoll", getTempRaumNorSollM1="TempRaumNorSollM1"] label="Get Command" visibility=[vclient_commandType == "get"]
		Selection	item=vclient_commandSet			mappings=[setTempWWsoll="TempWWsoll", setTempRaumNorSollM1="TempRaumNorSollM1"] label="Set Command" visibility=[vclient_commandType == "set"]
		Setpoint	item=vclient_valueTempWWsoll			icon=temperature label="WW Temp. Soll [%.0f]" minValue=30 maxValue=60 step=5	visibility=[vclient_commandSet == "setTempWWsoll"] 
		//Setpoint	item=vclient_valueHeizkurveNiveauM1		icon=line		label="Heizkurve Niveau M1 [%.0f]" minValue=0 maxValue=10 step=1	visibility=[vclient_commandSet == setNiveauM1] 
		//Setpoint	item=vclient_valueHeizkurveNeigungM1	icon=line		label="Heizkurve Neigung M1 [%.1f]" minValue=0.2 maxValue=3.4 step=0.1	visibility=[vclient_commandSet == setNeigungM1] 
		Setpoint	item=vclient_valueTempRaumNorSollM1		icon=temperature label="Raumtemp. Soll [%.0f]" minValue=15 maxValue=25 step=1	visibility=[vclient_commandSet == "setTempRaumNorSollM1"]
		//Setpoint	item=vclient_valueTempRaumRedSollM1		icon=temperature_cold label="Raumtemp. reduz. Soll [%.0f]" minValue=15 maxValue=25 step=1	visibility=[vclient_commandSet == "setTempRaumRedSollM1"]
		//Setpoint	item=vclient_valueEinmalladung			icon=water 		minValue=0 maxValue=1 step=1	visibility=[vclient_commandSet == setEinmalladung]
		
		Switch		item=vclient_execute			label="vclient execute"
		// get
		//Text		item=vclient_Eingabewert		visibility=[vclient_commandType == get] 		
		//Text		item=vclient_Rueckgabewert		visibility=[vclient_commandType == get] 		
		//Default		item=vclient_LetzteAusfuhrung label="get Ausführung [%1$td.%1$tm.%1$tY %1$tH:%1$tM:%1$tS]"	visibility=[vclient_commandType == get] 		
		//Text		item=vclient_Ausfuhrung		label="vclient Set Ausführung [%s]" 	visibility=[vclient_commandType == "get"] 		
		Default		item=vclientCommand_ExecuteCommand
		Default		item=vclientCommand_result
		// set
		//Text		item=vclientSet_Eingabewert		visibility=[vclient_commandType == set] 		
		//Text		item=vclientSet_Ruckgabewert	visibility=[vclient_commandType == set] 		
		//Default		item=vclientSet_ZeitpunktderletztenAusfuhrung label="set Ausführung [%1$td.%1$tm.%1$tY %1$tH:%1$tM:%1$tS]"	visibility=[vclient_commandType == set] 		
		//Text		item=vclientSet_Ausfuhrung		label="vclient Set Ausführung [%s]" 	visibility=[vclient_commandType == set] 		
	}
}

Thanks for any help!
Regards Christoph

[wborn]

Is this still an issue @lolodomo?
If so, is it a core or Basic UI issue?

[lolodomo]

Until around 2 weeks ago this sitemap was running like a charm in Firefox and in the Android App. A few days ago suddenly the selection entries and the visibility were not shown as expected.

That is very annoying as we have made no changes regarding that since ages.

Is this still an issue @lolodomo? If so, is it a core or Basic UI issue?

I have not yet investigated as it is probably very difficult to reproduce.
Regarding live update not working, the more common error is to have a sitemap name not matching the file name. With the provided example, the file should be named vclient.sitemap. But as it is explained that it first works and then stops to work, I assume the filename is certainly correct.

[riegelbrau]

Thanks for your comment!
This issue still exists on my devices since then. Can this be a result from configuration changes? I do not document them in detail, so I cannot tell what might have been changed.

If someone tells me, how to trace or debug the behavior, I could provide some more details.

May the MariaDB, I am using for persistence, have influence to the live update?

Regards Christoph

[lolodomo]

Is one of your item linked to a channel having dynamic state options updated at a certain time?
What is the binding behind your items?
Is it possible to have a smaller sitemap without only 2 or 3 elements and explaining the scenario with successive items values I should set to reproduce your problem?

[riegelbrau]

All items in the sitemap vclient above (vclient.sitemap) are not linked to any channel and are only updated by the UI and the defined visibility and selection mappings. The result of a Selection e.g. item=vclient_commandType switched to "get" to does not display the depending Selection item=vclient_commandGet. After UI refresh the update is done.

I now created a small testing environment with different items as test_3186.sitemap:
sitemap test label="Test #3186" { Frame label="Test #3186" { Default item=Gas_ZaehlerSensor_time label="#3186 Gas sensor last event [%1$td.%1$tm.%1$tY %1$tH:%1$tM:%1$tS]" Default item=Gas_ZaehlerSensor_eventcount label="#3186 Gas meter eventcount [%.0f]" Default item=Gas_Zaehlerstand label="#3186 Gas meter actual count [%, .2f m³]" } }
These are the corresponding items, two of them linked to a mqtt channel:
Number Gas_ZaehlerSensor_eventcount "Zählersensor [%.0f]" <gas> (Gas_gMAP) { channel="mqtt:topic:ds218plus:sensor_gas:eventcount" } DateTime Gas_ZaehlerSensor_time "Zählersensor Aktualis. [%s]" <time> (Gas_gMAP) { channel="mqtt:topic:ds218plus:sensor_gas:time" } Number:Volume Gas_Zaehlerstand "Zähler aktuell [%.3f m³]" <gas> (Gas, Gas_gMAP)
The group "gas" is persisted via jdbc in MariaDB, while the two other items are persisted in mapDB.

See these two screenshots of the sitemap, the mqtt update and the item update:

1. initial
   
2. Two mqtt and item updates not visible on the sitemap:
   

FYI: I am running OH 3.4.2 in docker on a Synology NAS. Mosquitto is running also on the NAS in docker, while MariaDB is running as a Synology application.

Thanks for your assistance!

Regards Christoph

[lolodomo]

As I previously commented, the live update will not work if your sitemap filename and the sitemap name in the file are not the same. I know it is strange but it is like that since the beginning (more than 10 years).
If your file is test_3186.sitemap, use test_3186 as sitemap name inside the file (and not test) .
Let me know if the problem is solved.

[riegelbrau]

This new test_3186.sitemap was the only one with unequal naming. All others are correct but show the issue.
After changing the name like recommended, the problem keeps staying.

[lolodomo]

Finally with your last and simplified example, there is no question of selection or visibility, this is a pure problem of live update.
If I correctly understand, the MQTT binding updates an item named Gas_ZaehlerSensor_time and you don't see any update in BasicUI.
Is the value correct when you re-open your sitemap ?
Is it something you can reproduce only for a DateTime item ? I am asking myself if the problem could be the time format provided by MQTT with microseconds (6 digits).

[lolodomo]

I also see that you used "%s" as format on the item, I am not fully sure that it is appropriate.
I am trying to build a similar test, of course without MQTT.

[riegelbrau]

The test_3168 sitemap is only one example to describe the behavior. The problem occurs overall in all sitemaps. Just a few minutes ago, I faced it live: I just had closed the bedroom window, which has a Zigbee window contact. Looking on my main sitemap still showed the contact switch as OPEN. After manual refresh, the contact disappeared as configured in the visibility keyword. Looking on the model based location page, all updates to equipment points appear immediately. Regards Christoph Gruß Christoph Am 13. März 2023 10:21:53 schrieb lolodomo ***@***.***>:

…

Finally with your last and simplified example, there is no question of visibility, this is a pure problem of live update. If I correctly understand, the MQTT binding updates an item named Gas_ZaehlerSensor_time and you don't see any update in BasicUI. Is the value correct when you re-open your sitemap ? Is it something you can reproduce only for a DateTime item ? I am asking myself if the problem could be the time format provided by MQTT with microseconds (6 digits).— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[lolodomo]

Here are tests and results.

DateTime TestDateTime "Test date time [%s]" <time>

sitemap test3 label="Tests"
{
        Frame {
                Default item=TestDateTime label="Last event [%1$td.%1$tm.%1$tY %1$tH:%1$tM:%1$tS]"
        }
}

First I set a value (the value from your screen shot) through the console: openhab:send TestDateTime "2023-03-12T12:35:00.170707+01:00"
Then I open the sitemap:

Now I update the value through the console: openhab:send TestDateTime "2023-03-12T12:37:08.197505+01:00"
And finally I see the update in BaiscUI:

[lolodomo]

The test_3168 sitemap is only one example to describe the behavior. The problem occurs overall in all sitemaps.

Probably something specific to your setup.
What browser are you using ? On what OS ?

[lolodomo]

I am running openHAB latest (3.3.0) in Docker on a Synology NAS.

Very unusual server setup.
Maybe the SSE connection between the server and the browser is unstable with that setup ? Cut by the machine after a certain time ?
I don't know if you have the possibility to test your OH server setup run a Windows or Linux machine ?

Sorry, I will not investigate more, the problem is probably the infrastructure used to run your OH server.

[lolodomo]

You could rather ask help on the community forum for other users running OH server in docker on a Synology NAS.
As docker is now used by a certain number of users, if there was a general issue with BasicUI when server run in docker, this would be already known.
I would rather suspect the Synology NAS but this is just an hypothesis.

[wborn]

In Chrome it's easy to debug if/what events are received in by the browser.

1. Open the "Developer tools" (by menu or pressing F12)
2. Select the "Network" tab
3. Select the "Fetch/XHR" filter
4. Go to your Basic UI page as normally
5. Wait for some events to be received (you'll see the bar on top move and bars change in the "Waterfall" column)
6. Select the request with type "eventsource"
7. Select the "EventStream" tab

You'll start seeing something like this and new events get added to the view:

So you could check if the event is received. You'll also want to keep an eye on the "Console" to see if any errors occur.

[lolodomo]

I don't know what we can do with this issue as I can't reproduce it. Is it specific to docker or Synology context, I don't know.
At the same time, 2 PRs related to SSE were merged in January so maybe the situation is no more the same ?
openhab/openhab-webui#2280
openhab/openhab-webui#2282

[lolodomo]

@openhab/core-maintainers : please add the tag "awaiting feedback", I would like to know if the issue persists in OH 4.2. Then the issue will be closed in few months automatically if we have no feedback.

[riegelbrau]

Hello all,

some time last year, nudged by reading that I ran a "very unusual setup", I decided to switch to Openhabian on a Pi 4b with 4 GB RAM, while Mosquitto (Docker) and MariaDB (native) keep running on my Synology NAS. Since then, this issue did not occur anymore. Right now I'm running OH 4.1.1.

You may close this issue.

Regards
Christoph

[holgerfriedrich]

Thanks, @riegelbrau, for the feedback.