HC3 QuickApp dropdown/select UI shows stale selections after updateView

[ChristianSogaard 75]

Hi Fibaro R&D team,

I am seeing a consistent issue with QuickApp select/dropdown elements in the HC3 Device Preview UI.

This is not a Lua state problem. The QuickApp state is correct, the debug logs show the correct values, and the save/action logic receives the correct data. The problem is that the rendered Device Preview UI can keep showing stale selected values after the QuickApp updates the dropdown programmatically.

Context:

I am building a configuration QuickApp where the user maps Logic Group Matrix buttons to different target systems such as Hue, Velux/Tahoma, and Sonos.

The UI contains dynamic dropdowns/selects for:

Destination type
Target device
Matrix device
Button mapping profile

Typical flow:

Select Hue
Select a Hue device
Select a Matrix device
Select button mappings
Save mapping
Switch destination type to Velux/Tahoma
Lua state is cleared correctly
Device Preview UI may still show old Hue/button selections, or otherwise stale dropdown state

The internal state is correct. The visual UI is not always correct.

 

We tested multiple approaches:

self:updateView("selectName", "selectedItems", {})
self:updateView("selectName", "values", {})

For single-select elements we also tested:

self:updateView("selectName", "selectedItem", "")
self:updateView("selectName", "value", "")

We also tested clearing and republishing options:

self:updateView("selectName", "options", {})
self:updateView("selectName", "selectedItems", {})
self:updateView("selectName", "values", {})

fibaro.setTimeout(80, function()
  self:updateView("selectName", "options", options)
  self:updateView("selectName", "selectedItems", values)
  self:updateView("selectName", "values", values)
end)

For multi-select we also tested clearing with:

self:updateView("selectName", "selectedItems", { "" })

 

The behavior remains unreliable. Sometimes the UI updates correctly, sometimes it keeps showing an old selection. If the user switches away from the Preview tab, for example to Variables, and then back to Preview, the UI often corrects itself. That strongly suggests a Device Preview render/cache issue rather than a QuickApp logic issue.

 

This is problematic for configuration QuickApps because the visible UI can no longer be trusted. The user may see a selected item that is no longer selected in the QuickApp state.

 

Questions for Fibaro R&D:

What is the officially supported way to clear a QuickApp dropdown/select from Lua?

Is there a difference between clearing single-select and multi-select elements?

Which properties are officially supported and recommended: selectedItem, selectedItems, value, values, or a combination?

Is the Device Preview cached in a way that can prevent immediate visual updates after updateView?

Is there a supported way to force the Device Preview UI to re-render a select element?

When options are updated dynamically, is the previous selection expected to be preserved, cleared, or validated against the new options?

Is the behavior different between legacy viewLayout and the newer UI?

Can Fibaro provide a minimal supported example showing how to:

Create a select/dropdown
Select an item
Clear the selection programmatically
Replace the options dynamically
Handle both single-select and multi-select correctly

 

Expected behavior:

When updateView changes or clears a select value, the visible Device Preview UI should immediately reflect the actual QuickApp state.

 

Actual behavior:

The QuickApp state changes correctly, but the Device Preview UI can continue to show stale selected values until the Preview tab is reloaded or reopened.

From a developer point of view, this looks like either an undocumented API detail or a Device Preview rendering/cache bug. A clear statement from Fibaro R&D on the supported API and expected behavior would be very helpful.

[w.rys 8]

Hi,

 

We can confirm that there is a problem with refreshing the selection after updateView calls, and it requires reopening the devices preview. It acts the same way in web UI and Yubii Home APP. A bug has been reported. Web part should be fixed in the next beta update (5.212).

 

I agree that the naming of what needs to be used in updateView may not be clear, and does not match the actual naming of properties in the view.

I've attached simple examples of how to use single and multi-selects 

Please login or register to see this attachment.

 

Please login or register to see this attachment.

 

I'll also try to clarify the naming and usage: 

•  selection in single select, use "selectedItem" and provide a string value. eg  self:updateView("modeSelector", "selectedItem", "auto"). You can clear it out by providing an empty string. eg self:updateView("modeSelector", "selectedItem", "").
• selection in multi select, use "selectedItems" and provide an array of string values. eg. self:updateView("modeSelector", "selectedItems", {"auto", "manual"}). You can clear it out by providing an empty array. eg. self:updateView("modeSelector", "selectedItems", json.array()).
• Why json.array() and not {}? An empty Lua table ({}) is a bit ambiguous. By default, it's encoded as an empty object since Lua tables are associative arrays (https://www.lua.org/pil/2.5.html). Of course, non-empty Lua tables are encoded correctly depending on the content. You can try it by printing this

Please login or register to see this code.

• after updating selector options, you don't need to update the selection. Those properties are independent, and selected options are preserved. So update the selection only if you need to. I know that right now the web UI clears the selection when options are updated, but that will also be fixed. Selection will disappear only if the selected option is not present in the new options list.
• I don't see any way to force the refresh of the device preview, but I'll look into it a bit more.

 

Hope this helps  

 

edit: I forgot to mention - old view ("Use the new views in mobile application" checkbox unchecked) already works fine with provided code samples.