SiteMap 'visibility' tag seems to disable SetPoint Items

[AndrewFG (Andrew Fiddian-Green)]

I have a SiteMap frame as shown below. It uses the state of a Switch Item as the ‘visibility’ tag for a respective SetPoint item. The visibility switch does indeed work (see screenshots below). However my problem is that under some circumstances(*) the SetPoint appears visible but its up/down buttons are disabled. In those circumstances, toggling the Switch Item that triggers the visibility tag, will re-enable the up/down buttons; (this is my current work around). But I would like to ensure that under all circumstances if the Item is visible, it is also enabled.

(*) as far as I can tell, the circumstances when the item is visible but not enabled are, on system start up, or when a new browser re-loads the SiteMap. So I am thinking that there may be some script code in the SiteMap page (either client side or server side) that has a bug whereby the buttons are not enabled until the visibility Switch Item code has executed. Or something like that. Any thoughts?

Frame item=g_Upstairs_Temperature {
  Switch item=Upstairs_Master_Thermostat_Occupancy_Mode_Present
  Text item=Radiator_Heating_Valve_Open
  Text      item=Front_Bedroom_Radiator_Room_Temperature
  Setpoint  item=Front_Bedroom_Radiator_Target_Temperature minValue=15 maxValue=27 step=1 visibility=[Upstairs_Master_Thermostat_Occupancy_Mode_Present==ON]
}

[rossko57]

I’ll guess the set point needs to know current state. It doesn’t work if the Item is actually NULL I think?
But when invisible, it gets left off the “mailing list”. Something to do with registering with host for updates.

[AndrewFG (Andrew Fiddian-Green)]

@rossko57

It doesn’t work if the Item is actually NULL
it gets left off the “mailing list”

@rossko57 many thanks for the feedback. I am not sure that the Item value is ever NULL (except on system start up).

The Upstairs Master Thermostat is acting a master for five individual upstairs rooms, and there is a Rule that runs behind the scenes that acts as follows…

• If the Upstairs Master Thermostat is set to occupancy mode present = ON, then the Rule sets all the five individual room thermostats to occupancy mode present = ON to match. And this allows the five room thermostats to control temperature individually according to their respective ‘occupied’ set points. It also makes the SiteMap setpoint visible, so that users can adjust the setpoint in their room.

• If the Upstairs Master Thermostat is set to occupancy mode present = OFF, then the Rule sets all the five individual room thermostats to occupancy mode present = OFF to match. And this forces the room thermostats to control temperature according to a frost protection set point. It also hides the SiteMap setpoint, so that users cannot interfere with the frost protection setpoint.

• So toggling the Upstairs Master Thermostat occupancy mode will toggle the respective individual room’s setpoint Items’ values between ‘normal’ and ‘frost’ control. But it never sets their values to null.

[rossko57]

I’m just saying the set point widget doesn’t work without an initial valid value.
So the likely mechanism here might be that it doesn’t get fed values while it is invisible, due to UI leaving it off the list to be updated.

This looks closely related -

Crazy bevavior in Basic UI OH3

Platform information: Hardware: Dell Server OS: Ubuntu 20.04 LTS Java Runtime Environment: 11 openHAB version: 3.0.0 stable I just remember a crazy bevavior of Basic UI sitemaps since updated to OH3: When opening Basic UI-Sitemap in a Browser, nealry everything works fine, except: Setpoints of heating devices. In OH2 I could push up or down to increase / decrease about 0,5° Web-Basic-UI dont react on this under OH3. Everything else works fine. Now the total crazyness: If I use the App, …

though it seems to lead us to invalid units from UI for “first use”. Pretty close to “becoming visible”.
All your misbehaved all Quantity types?

[AndrewFG (Andrew Fiddian-Green)]

@rossko57

This looks closely related

Yep. That’s the one for sure.

@rossko57

Pretty close to “becoming visible”.

It might not really be the visible toggling as such. It could perhaps be the consequent page refresh in the browser. My symptoms also tend to match that. It needs more digging, so I will report back.

@rossko57

All your misbehaved all Quantity types?

Yes they are Number:Temperature items. Note: the case I cited above is using Tado radiator thermostats (upstairs) but I have the same issue with NeoHub under floor heating thermostats (downstairs), and both of them provide proper values with UoM etc. so we can rule out a binding issue. And probably also rule out the values being NULLed in the core…

[JensH]

You can use a rule on system starts set presence to off if not already persistent.

So we could exclude a visibility failure

[AndrewFG (Andrew Fiddian-Green)]

@JensH

set presence to off if not already persistent

It is already persisted.

[AndrewFG (Andrew Fiddian-Green)]

The problem is not the visibilty flag per se. But in my case the visibility flag causes the page to reload. And the reload causes it to go from failing to succeeding.

Suggest to keep further discussion on your thread.

[AndrewFG (Andrew Fiddian-Green)]

Issue has been solved…

Fix changing temperature via Basic UI