feat: Using setValue to update UI immediately for WebAPI devices

[ShadowBr0ther]

Implements setValue functionality for WebAPI devices, enabling immediate UI updates when values are changed programmatically via WebSocket or scripts, bypassing the polling interval.

Problem

WebAPI devices did not support setValue. When updating tag values programmatically through WebSocket commands or scripts, the UI would not reflect changes until the next polling cycle, causing delays of several seconds depending on the polling interval.

This made real-time interactions (e.g., script runs for calling external actions) feel unresponsive like in the case of issue #1590

Use Case Example

A WebAPI device is configured with a polling interval (e.g., 5 seconds) to regularly fetch data. Additionally, a WebSocket connection is established with a script (similar to the WebSocket integration described in the FUXA wiki HowTo Websockets) that receives real-time push notifications from the WebAPI server when values change.

How it works:

1. WebSocket pushes update → Server sends real-time value change notification
2. setValue() is called → FUXA processes the update and immediately refreshes the UI
3. Polling continues → Regular polling runs in the background as a fallback to guarantee data consistency

Benefits of the possibility of this hybrid approach:

• Real-time responsiveness: UI updates instantly via WebSocket push notifications
• Guaranteed reliability: Polling acts as a fallback mechanism to catch any missed WebSocket messages
• Best of both worlds: Low latency when possible, with guaranteed eventual consistency

Related Issues

Fixes #1590

[unocelli]

@ShadowBr0ther Hi, I don't understand the scope to update the UI value without post to device, you will see a wrong information that don't reflect the device value.

[ShadowBr0ther]

Hi @unocelli,

you’re absolutely right that blindly updating the UI without writing to the real device can lead to inconsistent data. I don’t want to argue against that in general – the point of this change is a bit more specific.

In our concrete WebAPI + WebSocket setup it works like this:

• The WebAPI device is a heavy pull endpoint (large JSON, costly backend processing, etc.).
• In parallel, we have a WebSocket connection from the same backend that pushes authoritative value changes in real time.
• When such a WebSocket message arrives, we call setValue() so that FUXA updates the UI immediately, instead of waiting for the next poll.

So we are not inventing values in the frontend and we’re not bypassing the real device logic. The value has already changed on the backend / device side – the WebSocket is just the faster notification channel. Polling stays enabled as a fallback, so eventual consistency is still guaranteed even if a WebSocket message is lost.

Without this behavior, to achieve the same responsiveness we’d have to:

• drastically lower the polling interval (which would hammer the WebAPI endpoint), or
• accept several seconds of lag between a real device change and the UI.
  Both of this options are real pain points.

With this hybrid model:

• Real-time responsiveness comes from WebSocket pushes + setValue() updating the UI,
• Reliability comes from the existing polling that keeps the state in sync over time
• The values themselves are identical – just delivered more efficiently and with lower latency.

Of course this can be misused (e.g. scripts setting arbitrary fake values), but that requires someone to explicitly implement that misuse in their script. For legitimate WebAPI/WebSocket setups the feature simply exposes what the backend already knows, faster and with much less load on the infrastructure.