<![CDATA[LogicMachine Forum - Visu]]> https://forum.logicmachine.net/ Wed, 14 Oct 2026 23:16:04 +0000 MyBB <![CDATA[End user Visu scenes]]> https://forum.logicmachine.net/showthread.php?tid=6570 Mon, 05 Oct 2026 18:23:14 +0000 gtsamis]]> https://forum.logicmachine.net/showthread.php?tid=6570
I saw that you uploaded a video demonstrating end-user scenes:
https://www.youtube.com/watch?v=8qCMONZ-q8c

In my installations, the button does not appear anywhere. Is there a setting I need to enable, or does this feature require firmware that has not been released yet?

Thanks!
George]]>
I saw that you uploaded a video demonstrating end-user scenes:
https://www.youtube.com/watch?v=8qCMONZ-q8c

In my installations, the button does not appear anywhere. Is there a setting I need to enable, or does this feature require firmware that has not been released yet?

Thanks!
George]]> <![CDATA[Widget Centering | VISU]]> https://forum.logicmachine.net/showthread.php?tid=6567 Tue, 29 Sep 2026 14:04:40 +0000 _BG_]]> https://forum.logicmachine.net/showthread.php?tid=6567 I have a question regarding New Visu.
The visualisation will be used mainly on a mobile phone (Tile view only).
Is it possible to center the widgets on the screen, or make them automatically scale to the phone’s screen width?

Custom widget size:320x430, 3x4
Switch widget size: 3x1

Or I just need to add some CSS or JS to achieve this?

I also have a question regarding “Tile view width” in Admin Visu. Does this parameter have any impact on the final appearance of the application? 

Thanks in advance!
BG


.png   Visu_issue.png (Size: 53.17 KB / Downloads: 54)
]]> I have a question regarding New Visu.
The visualisation will be used mainly on a mobile phone (Tile view only).
Is it possible to center the widgets on the screen, or make them automatically scale to the phone’s screen width?

Custom widget size:320x430, 3x4
Switch widget size: 3x1

Or I just need to add some CSS or JS to achieve this?

I also have a question regarding “Tile view width” in Admin Visu. Does this parameter have any impact on the final appearance of the application? 

Thanks in advance!
BG


.png   Visu_issue.png (Size: 53.17 KB / Downloads: 54)
]]> <![CDATA[Decimal separator]]> https://forum.logicmachine.net/showthread.php?tid=6562 Wed, 23 Sep 2026 07:12:21 +0000 stianj]]> https://forum.logicmachine.net/showthread.php?tid=6562
I have finally grown tired of . (period) being the decimal separator in Visu when , (comma) is the correct one in my part of the world. But searching the forum or the internet seems to suggest that I am the only person with that issue.

Either I'm the only one who cares, or everyone else has found a solution. Is there a way..?]]>
I have finally grown tired of . (period) being the decimal separator in Visu when , (comma) is the correct one in my part of the world. But searching the forum or the internet seems to suggest that I am the only person with that issue.

Either I'm the only one who cares, or everyone else has found a solution. Is there a way..?]]> <![CDATA[INSPIRATIONAL VISUALIZATION DESIGNS]]> https://forum.logicmachine.net/showthread.php?tid=6559 Mon, 21 Sep 2026 18:52:36 +0000 stemic01]]> https://forum.logicmachine.net/showthread.php?tid=6559 It would be great to see more inspiring graphic user interfaces made in the Logic Machine / KNX wiser to get inspired and see what is possible and how we can push ourselves into making great and user friendly designs. 

Please post your inspiring designs.]]> It would be great to see more inspiring graphic user interfaces made in the Logic Machine / KNX wiser to get inspired and see what is possible and how we can push ourselves into making great and user friendly designs. 

Please post your inspiring designs.]]> <![CDATA[access visu pages without login]]> https://forum.logicmachine.net/showthread.php?tid=6558 Sun, 20 Sep 2026 09:41:57 +0000 KoBra]]> https://forum.logicmachine.net/showthread.php?tid=6558 <![CDATA[long press --> ciclyc sending]]> https://forum.logicmachine.net/showthread.php?tid=6549 Wed, 16 Sep 2026 13:52:35 +0000 toujour]]> https://forum.logicmachine.net/showthread.php?tid=6549
Can I use a long press to trigger a repeating send action as long as I hold down the button? (without logic, but using JavaScript) 

KR,
Alberto]]>
Can I use a long press to trigger a repeating send action as long as I hold down the button? (without logic, but using JavaScript) 

KR,
Alberto]]> <![CDATA[CSS - frame - VISU]]> https://forum.logicmachine.net/showthread.php?tid=6547 Tue, 15 Sep 2026 13:44:24 +0000 toujour]]> https://forum.logicmachine.net/showthread.php?tid=6547
 I have a problem with remote VISU and the CSS.
In local I see the correct CSS (I want red) but in remote is the deafult.

.png   Screenshot 2026-09-15 154321.png (Size: 214.16 KB / Downloads: 51)

.png   Screenshot 2026-09-15 154332.png (Size: 92.02 KB / Downloads: 51)


Can you help me ?

BR,
Alberto]]>
 I have a problem with remote VISU and the CSS.
In local I see the correct CSS (I want red) but in remote is the deafult.

.png   Screenshot 2026-09-15 154321.png (Size: 214.16 KB / Downloads: 51)

.png   Screenshot 2026-09-15 154332.png (Size: 92.02 KB / Downloads: 51)


Can you help me ?

BR,
Alberto]]> <![CDATA[Visu localbus.js reconnect behaviour, reuse object registry, reconnect without delay]]> https://forum.logicmachine.net/showthread.php?tid=6543 Sat, 05 Sep 2026 16:47:55 +0000 savaskorkmaz]]> https://forum.logicmachine.net/showthread.php?tid=6543
PROBLEM

On some corporate networks a middlebox (IPS / application control / proxy / NAC policy) resets established TCP sessions a few seconds after they open. Visu's live-data WebSocket is hit by this; the classic HTTP-polling visualization is not. With the current client logic the visible effect and the server load are much larger than necessary:

- on every WebSocket close, localbus.js waits 1 s,
- then re-downloads the FULL object registry via POST /apps/localbus.lp (about 285 KB in our project, 2832 objects),
- and only then reopens the WebSocket.

So each reset costs the user ~3 s of "reconnecting" spinner with frozen values, and costs the LM a full registry regeneration.

Field symptom that started this: WebSocket killed 1-1.5 s after open, floor plan stays rendered, spinner flashes every ~3 s, values freeze. A laptop on the same LAN (not subject to the policy) worked fine.

WHAT WE MEASURED

Lab: a transparent TCP relay between client and LM that kills every session after N seconds.

1) Current client, Android panel, kill after 5 s
  WS lifetime 5.0 s, visible gap 2.9-3.0 s per cycle, ~37 % of the time disconnected,
  server work per cycle: registry POST 285 KB + WS handshake.

2) Current client, Android panel, kill after 2 s
  The registry POST never completes, page stays blank with a permanent spinner.

3) Patched client (see below), desktop Chrome, kill after 5 s
  WS lifetime 5.06 s, visible gap 22-37 ms, < 1 % disconnected, server work: WS handshake only (~4 KB).

4) Patched client, desktop Chrome, kill after 1.5 s (the field case)
  WS lifetime 1.55 s, gap avg 25 ms / max 29 ms, 1.5 % disconnected, live values keep flowing.

5) Control, kill only after 15 s idle
  No disconnects at all: the client "ping" every 10 s keeps the socket alive, so idle timeouts >= 11 s are not the cause.

Also verified: the server ACCEPTS a new WebSocket in the same session without a preceding registry POST (opened in 21 ms, live messages received).

OBSERVED CLIENT LOGIC (localbus.js)

onclose -> setstate(false) -> onerror() -> setTimeout(init, 1000) -> init(): POST /apps/localbus.lp (full registry) -> register() -> start(): new WebSocket.
No backoff. The registry is re-fetched on every reconnect although objectstore already holds it.

REQUESTED CHANGE (small)

1. On WebSocket close, if objectstore is already populated, reopen the WebSocket directly (start()), without the 1 s delay and without re-downloading the registry.
2. Keep the full init() path only when the registry is empty or the previous session was rejected (lived < ~300 ms), so an expired session still recovers.
3. Add a simple cap/backoff (e.g. max 60 fast reconnects per minute, then 1 s delay) to protect the server under persistent resets.
4. Optional: expose reconnect counters (count, last lifetime, last gap) on the localbus object for diagnostics.

WHY IT MATTERS FOR THE SERVER TOO

Under a 1.5 s reset policy with 20 panels the current logic makes the LM regenerate about 1.4 MB/s of registry JSON continuously; the patched logic reduces that to WebSocket handshakes (about 60 KB/s). On healthy networks the change has zero effect.

REFERENCE IMPLEMENTATION (tested as Visu Custom JS, wraps start/onerror only)

(function () {
  var CFG = { FAST_LIMIT_PER_MIN: 60, SLOW_WAIT_MS: 1000, REJECT_LIFE_MS: 300, WAIT_FOR_LOCALBUS_MS: 30000 };
  if (window.__sonaLb) return;
  window.__sonaLb = { version: 'V1', active: false, fast: 0, slow: 0, full: 0, lastLifeMs: null, lastGapMs: null, sessions: 0 };
  function install() {
    var lb = window.localbus;
    if (!lb || typeof lb.start !== 'function' || typeof lb.onerror !== 'function' || typeof lb.init !== 'function') {
      console.warn('[sona-lb] unexpected localbus structure, patch not applied'); return;
    }
    var S = window.__sonaLb, hist = [], startT = 0, closeT = 0;
    var origStart = lb.start, origOnError = lb.onerror;
    lb.start = function () {
      startT = Date.now(); S.sessions++;
      if (closeT) { S.lastGapMs = startT - closeT; closeT = 0; }
      return origStart.apply(this, arguments);
    };
    lb.onerror = function () {
      var now = Date.now();
      clearTimeout(this.inittimer); this.inittimer = null;
      closeT = now;
      S.lastLifeMs = startT ? now - startT : null;
      var haveRegistry = this.objectstore && Object.keys(this.objectstore).length > 0;
      var rejected = S.lastLifeMs !== null && S.lastLifeMs < CFG.REJECT_LIFE_MS;
      if (!haveRegistry || rejected) { S.full++; return origOnError.call(this); }  // default path: 1 s + POST + WS
      hist = hist.filter(function (t) { return now - t < 60000; });
      var self = this;
      if (hist.length >= CFG.FAST_LIMIT_PER_MIN) {                                  // cap: wait, but no POST
        S.slow++;
        this.inittimer = setTimeout(function () { self.inittimer = null; self.start(); }, CFG.SLOW_WAIT_MS);
        return;
      }
      hist.push(now); S.fast++;
      this.start();                                                                  // fast path: new WebSocket now
    };
    S.active = true;
    console.info('[sona-lb] fast reconnect active (' + S.version + ')');
  }
  if (window.localbus) { install(); return; }
  var t0 = Date.now();
  var timer = setInterval(function () {
    if (window.localbus) { clearInterval(timer); install(); }
    else if (Date.now() - t0 > CFG.WAIT_FOR_LOCALBUS_MS) { clearInterval(timer); console.warn('[sona-lb] localbus not found'); }
  }, 200);
})();

We can share the raw measurement logs and the relay tool used to reproduce this.]]>
PROBLEM

On some corporate networks a middlebox (IPS / application control / proxy / NAC policy) resets established TCP sessions a few seconds after they open. Visu's live-data WebSocket is hit by this; the classic HTTP-polling visualization is not. With the current client logic the visible effect and the server load are much larger than necessary:

- on every WebSocket close, localbus.js waits 1 s,
- then re-downloads the FULL object registry via POST /apps/localbus.lp (about 285 KB in our project, 2832 objects),
- and only then reopens the WebSocket.

So each reset costs the user ~3 s of "reconnecting" spinner with frozen values, and costs the LM a full registry regeneration.

Field symptom that started this: WebSocket killed 1-1.5 s after open, floor plan stays rendered, spinner flashes every ~3 s, values freeze. A laptop on the same LAN (not subject to the policy) worked fine.

WHAT WE MEASURED

Lab: a transparent TCP relay between client and LM that kills every session after N seconds.

1) Current client, Android panel, kill after 5 s
  WS lifetime 5.0 s, visible gap 2.9-3.0 s per cycle, ~37 % of the time disconnected,
  server work per cycle: registry POST 285 KB + WS handshake.

2) Current client, Android panel, kill after 2 s
  The registry POST never completes, page stays blank with a permanent spinner.

3) Patched client (see below), desktop Chrome, kill after 5 s
  WS lifetime 5.06 s, visible gap 22-37 ms, < 1 % disconnected, server work: WS handshake only (~4 KB).

4) Patched client, desktop Chrome, kill after 1.5 s (the field case)
  WS lifetime 1.55 s, gap avg 25 ms / max 29 ms, 1.5 % disconnected, live values keep flowing.

5) Control, kill only after 15 s idle
  No disconnects at all: the client "ping" every 10 s keeps the socket alive, so idle timeouts >= 11 s are not the cause.

Also verified: the server ACCEPTS a new WebSocket in the same session without a preceding registry POST (opened in 21 ms, live messages received).

OBSERVED CLIENT LOGIC (localbus.js)

onclose -> setstate(false) -> onerror() -> setTimeout(init, 1000) -> init(): POST /apps/localbus.lp (full registry) -> register() -> start(): new WebSocket.
No backoff. The registry is re-fetched on every reconnect although objectstore already holds it.

REQUESTED CHANGE (small)

1. On WebSocket close, if objectstore is already populated, reopen the WebSocket directly (start()), without the 1 s delay and without re-downloading the registry.
2. Keep the full init() path only when the registry is empty or the previous session was rejected (lived < ~300 ms), so an expired session still recovers.
3. Add a simple cap/backoff (e.g. max 60 fast reconnects per minute, then 1 s delay) to protect the server under persistent resets.
4. Optional: expose reconnect counters (count, last lifetime, last gap) on the localbus object for diagnostics.

WHY IT MATTERS FOR THE SERVER TOO

Under a 1.5 s reset policy with 20 panels the current logic makes the LM regenerate about 1.4 MB/s of registry JSON continuously; the patched logic reduces that to WebSocket handshakes (about 60 KB/s). On healthy networks the change has zero effect.

REFERENCE IMPLEMENTATION (tested as Visu Custom JS, wraps start/onerror only)

(function () {
  var CFG = { FAST_LIMIT_PER_MIN: 60, SLOW_WAIT_MS: 1000, REJECT_LIFE_MS: 300, WAIT_FOR_LOCALBUS_MS: 30000 };
  if (window.__sonaLb) return;
  window.__sonaLb = { version: 'V1', active: false, fast: 0, slow: 0, full: 0, lastLifeMs: null, lastGapMs: null, sessions: 0 };
  function install() {
    var lb = window.localbus;
    if (!lb || typeof lb.start !== 'function' || typeof lb.onerror !== 'function' || typeof lb.init !== 'function') {
      console.warn('[sona-lb] unexpected localbus structure, patch not applied'); return;
    }
    var S = window.__sonaLb, hist = [], startT = 0, closeT = 0;
    var origStart = lb.start, origOnError = lb.onerror;
    lb.start = function () {
      startT = Date.now(); S.sessions++;
      if (closeT) { S.lastGapMs = startT - closeT; closeT = 0; }
      return origStart.apply(this, arguments);
    };
    lb.onerror = function () {
      var now = Date.now();
      clearTimeout(this.inittimer); this.inittimer = null;
      closeT = now;
      S.lastLifeMs = startT ? now - startT : null;
      var haveRegistry = this.objectstore && Object.keys(this.objectstore).length > 0;
      var rejected = S.lastLifeMs !== null && S.lastLifeMs < CFG.REJECT_LIFE_MS;
      if (!haveRegistry || rejected) { S.full++; return origOnError.call(this); }  // default path: 1 s + POST + WS
      hist = hist.filter(function (t) { return now - t < 60000; });
      var self = this;
      if (hist.length >= CFG.FAST_LIMIT_PER_MIN) {                                  // cap: wait, but no POST
        S.slow++;
        this.inittimer = setTimeout(function () { self.inittimer = null; self.start(); }, CFG.SLOW_WAIT_MS);
        return;
      }
      hist.push(now); S.fast++;
      this.start();                                                                  // fast path: new WebSocket now
    };
    S.active = true;
    console.info('[sona-lb] fast reconnect active (' + S.version + ')');
  }
  if (window.localbus) { install(); return; }
  var t0 = Date.now();
  var timer = setInterval(function () {
    if (window.localbus) { clearInterval(timer); install(); }
    else if (Date.now() - t0 > CFG.WAIT_FOR_LOCALBUS_MS) { clearInterval(timer); console.warn('[sona-lb] localbus not found'); }
  }, 200);
})();

We can share the raw measurement logs and the relay tool used to reproduce this.]]> <![CDATA[Disable context menu in chrome]]> https://forum.logicmachine.net/showthread.php?tid=6538 Thu, 27 Aug 2026 10:25:35 +0000 Ceros2112]]> https://forum.logicmachine.net/showthread.php?tid=6538
is it possible to disable the context menu that opens with long press in a chrome browser? I'm using PC/Tablet visualization and my customer complains about that  Rolleyes

thank you]]>
is it possible to disable the context menu that opens with long press in a chrome browser? I'm using PC/Tablet visualization and my customer complains about that  Rolleyes

thank you]]> <![CDATA[Index image on VISU]]> https://forum.logicmachine.net/showthread.php?tid=6519 Thu, 23 Jul 2026 13:12:12 +0000 Frank68]]> https://forum.logicmachine.net/showthread.php?tid=6519 is it possible in the new view to have an image that changes based on an analog value, like the additional images in the old system?
Thank you very much.]]> is it possible in the new view to have an image that changes based on an analog value, like the additional images in the old system?
Thank you very much.]]> <![CDATA[Change the Trend URL]]> https://forum.logicmachine.net/showthread.php?tid=6512 Fri, 17 Jul 2026 11:29:09 +0000 sjfp]]> https://forum.logicmachine.net/showthread.php?tid=6512 We have various buttons Btn1, Btn2, Btn3 etc, which we have named which widget page to show, like M1-Energy, M2-Energy.
At present when the button is pressed, the correct widget is shown over the top of the Energy Trend Frame, and when the button is pressed again it then shows a Trend Frame for all Meters.
Question is, would it be possible rather than showing the default Trends page for all meters, we could only show the trend page for relevent meters.
Example if we press Btn2, Widget M2-Energy is shown, when Btn2 is pressed again then Trend Page M2-Energy is shown.

Any help or advise would be great.]]> We have various buttons Btn1, Btn2, Btn3 etc, which we have named which widget page to show, like M1-Energy, M2-Energy.
At present when the button is pressed, the correct widget is shown over the top of the Energy Trend Frame, and when the button is pressed again it then shows a Trend Frame for all Meters.
Question is, would it be possible rather than showing the default Trends page for all meters, we could only show the trend page for relevent meters.
Example if we press Btn2, Widget M2-Energy is shown, when Btn2 is pressed again then Trend Page M2-Energy is shown.

Any help or advise would be great.]]> <![CDATA[Frame Trend logs from Neighbour]]> https://forum.logicmachine.net/showthread.php?tid=6505 Thu, 09 Jul 2026 15:59:42 +0000 function]]> https://forum.logicmachine.net/showthread.php?tid=6505

Is it possible to use the Frame widget to view a Trend logs URL from a neighbour with the new Visu?
I've tried but runs into a problem where i have to login to the frame.]]>

Is it possible to use the Frame widget to view a Trend logs URL from a neighbour with the new Visu?
I've tried but runs into a problem where i have to login to the frame.]]> <![CDATA[Import page]]> https://forum.logicmachine.net/showthread.php?tid=6501 Mon, 06 Jul 2026 04:33:30 +0000 dezza@sdme.it]]> https://forum.logicmachine.net/showthread.php?tid=6501 <![CDATA[Enabling the Old Visualization Menu via script]]> https://forum.logicmachine.net/showthread.php?tid=6498 Thu, 02 Jul 2026 09:34:26 +0000 savaskorkmaz]]> https://forum.logicmachine.net/showthread.php?tid=6498 One of our partners restored a backup from a project created with the old visualization system on another LogicMachine to a new LogicMachine running the 2025 firmware.
Normally, the old visualization menu is activated automatically when an old backup is restored, but this did not happen on this device.
Could you please provide us with a script to enable the old visualization menu?
Thx]]> One of our partners restored a backup from a project created with the old visualization system on another LogicMachine to a new LogicMachine running the 2025 firmware.
Normally, the old visualization menu is activated automatically when an old backup is restored, but this did not happen on this device.
Could you please provide us with a script to enable the old visualization menu?
Thx]]> <![CDATA[Tile view layout broken (large empty gaps) for thermostat widgets on mobile Safari —]]> https://forum.logicmachine.net/showthread.php?tid=6491 Tue, 30 Jun 2026 12:11:41 +0000 andreaemanuelli]]> https://forum.logicmachine.net/showthread.php?tid=6491
Firmware: LM5p2-KCDZ, 20251204
Visu version: new Visu (2025.11)
Browser: Safari on iOS (also reproduced via LM Home app, same engine)

ISSUE
A Category containing 7 native "thermostat" type widgets (tile_width=2,
tile_height=2 each) renders with large empty vertical gaps between rows
on iPhone, both in portrait and on first load. Widgets are present in
the DOM (confirmed via remote Web Inspector — all 7 elements have
display:block, visibility:visible, correct getBoundingClientRect()),
but visually appear scattered with huge blank spaces between them.

The same Category with simple "switch" type widgets (lights, in the
same Visu, same device) renders perfectly with no gaps.

WORKAROUND FOUND
Rotating the device screen once (portrait -> landscape -> portrait,
or just to landscape) immediately fixes the layout — all widgets
snap into a correct, gap-free grid.

DIAGNOSIS
This strongly suggests a Muuri grid layout calculation race condition:
the thermostat widget's internal SVG (circular arc, +/- buttons) takes
longer to reach final rendered dimensions than a simple switch icon.
If Muuri's initial layout() call measures widget dimensions before the
SVG has settled, it computes wrong absolute positions (translateX/
translateY) for those items, leaving gaps. A manual resize event
(screen rotation) forces Muuri to recalculate using final dimensions.

ATTEMPTED WORKAROUND (did not work)
Tried dispatching window.dispatchEvent(new Event('resize')) via
custom JS at multiple delays after page load (600ms/1200ms/2000ms/
3500ms) to replicate the rotation effect. This did NOT fix the issue —
suggesting Muuri's internal layout recalculation is not triggered by
the generic window resize event, but by something else (ResizeObserver
on the container, or an internal viewport-change handler specific to
orientation change).

QUESTIONS
1. Is this a known issue with the thermostat widget (or any widget
  with internal SVG) in tile view on narrow viewports?
2. Is there a way to programmatically trigger Muuri's layout() /
  refreshItems() from custom JS, since the Muuri instance isn't
  exposed on window?
3. Is there a recommended fix (CSS containment, explicit width/height
  constraints, etc.) to prevent this race condition?

Happy to share screenshots, exported widget JSON and console output
if useful for reproduction.

Ctrl+F5 already tried, no effect (this isn't a cache issue — confirmed
via fresh hard reload).]]>
Firmware: LM5p2-KCDZ, 20251204
Visu version: new Visu (2025.11)
Browser: Safari on iOS (also reproduced via LM Home app, same engine)

ISSUE
A Category containing 7 native "thermostat" type widgets (tile_width=2,
tile_height=2 each) renders with large empty vertical gaps between rows
on iPhone, both in portrait and on first load. Widgets are present in
the DOM (confirmed via remote Web Inspector — all 7 elements have
display:block, visibility:visible, correct getBoundingClientRect()),
but visually appear scattered with huge blank spaces between them.

The same Category with simple "switch" type widgets (lights, in the
same Visu, same device) renders perfectly with no gaps.

WORKAROUND FOUND
Rotating the device screen once (portrait -> landscape -> portrait,
or just to landscape) immediately fixes the layout — all widgets
snap into a correct, gap-free grid.

DIAGNOSIS
This strongly suggests a Muuri grid layout calculation race condition:
the thermostat widget's internal SVG (circular arc, +/- buttons) takes
longer to reach final rendered dimensions than a simple switch icon.
If Muuri's initial layout() call measures widget dimensions before the
SVG has settled, it computes wrong absolute positions (translateX/
translateY) for those items, leaving gaps. A manual resize event
(screen rotation) forces Muuri to recalculate using final dimensions.

ATTEMPTED WORKAROUND (did not work)
Tried dispatching window.dispatchEvent(new Event('resize')) via
custom JS at multiple delays after page load (600ms/1200ms/2000ms/
3500ms) to replicate the rotation effect. This did NOT fix the issue —
suggesting Muuri's internal layout recalculation is not triggered by
the generic window resize event, but by something else (ResizeObserver
on the container, or an internal viewport-change handler specific to
orientation change).

QUESTIONS
1. Is this a known issue with the thermostat widget (or any widget
  with internal SVG) in tile view on narrow viewports?
2. Is there a way to programmatically trigger Muuri's layout() /
  refreshItems() from custom JS, since the Muuri instance isn't
  exposed on window?
3. Is there a recommended fix (CSS containment, explicit width/height
  constraints, etc.) to prevent this race condition?

Happy to share screenshots, exported widget JSON and console output
if useful for reproduction.

Ctrl+F5 already tried, no effect (this isn't a cache issue — confirmed
via fresh hard reload).]]>