Merge branch 'main' into rosetta

Author: sumitshinde-84

src/_data/featureCatalog.yaml

@@ -597,6 +597,31 @@ sections:
           enterprise:
             value: true
 
+      - id: immersive-editor-drawer
+        label: Customisable Immersive Editor Drawer
+        description: "Pin, move, resize, or full-screen the immersive editor drawer — your preferences are remembered between sessions."
+        docsLink: null
+        changelog:
+          - url: /changelog/2026/04/immersive-editor-drawer/
+            release: '2.30'
+        solutions: [mes, scada, edge-connectivity]
+        showOnPricing: false
+        tags: [cloud, self-hosted]
+        cloud:
+          starter:
+            value: true
+          pro:
+            value: true
+          enterprise:
+            value: true
+        selfHosted:
+          starter:
+            value: true
+          pro:
+            value: true
+          enterprise:
+            value: true
+
       - id: pipelines
         label: DevOps Pipelines
         description: "Set up different environments for development, testing, and production Node-RED instances to support a full software delivery lifecycle."

src/blog/2026/04/diagnosing-modbus-degradation.md

@@ -24,7 +24,7 @@ Except "working" and "working correctly" are different things in Modbus polling,
 
 The mistakes aren't exotic. They're the same ones across almost every installation: polling everything at the same rate, ignoring timeouts, stacking too many registers into single requests, or hammering slow devices with back-to-back queries they were never designed to handle. None of these are obvious from the outside because Modbus doesn't complain. It just silently drops a frame or lets the device go quiet — and your polling stack fills in the gap by returning the last successfully read value, making the problem invisible until someone notices the data has stopped changing.
 
-This article isn't about the basics of how Modbus works. If you need that, start [here](/blog/2026/01/why-modbus-still-exist/). This is about the specific configuration decisions that separate a polling setup that stays stable for years from one that causes problems at the worst possible time. Part 1 covers the three mistakes made at commissioning. Part 2 covers what happens after the system is running.
+This article isn't about the basics of how Modbus works. If you need that, start [here](/blog/2026/01/why-modbus-still-exist/). This is about the specific configuration decisions that separate a polling setup that stays stable for years from one that causes problems at the worst possible time. It covers the three mistakes made at commissioning. The next article covers what happens after the system is running.
 
 ## The Myth of the Universal Scan Rate
 
@@ -139,4 +139,4 @@ The three problems this article covers, scan rate uniformity, timeout miscalcula
 
 The fix for all three is the same kind of work: deliberate, once, documented. Tier your scan rates to match how fast your data actually changes. Calculate your timeouts from the physics of your network rather than accepting defaults. Read the register map before you batch. None of this takes long. None of it requires downtime. It just requires treating these as decisions rather than defaults.
 
-If you've made these changes and your installation is still misbehaving, the problem is in the operational layer: how your polling architecture handles the network and devices once they're running. That's what Part 2 covers: serial versus TCP failure modes, unresponsive device handling, live diagnostics, and how to fix what you find without taking production down.
+If you've made these changes and your installation is still misbehaving, the problem is in the operational layer: how your polling architecture handles the network and devices once they're running. The next article covers that: serial versus TCP failure modes, unresponsive device handling, live diagnostics, and how to fix what you find without taking production down.

src/blog/2026/04/images/exception-table-modbus.png

@@ -0,0 +1,24 @@
+---
+title: Customisable Immersive Editor Drawer
+description: The immersive editor drawer is now pinnable, switchable, and resizable — with your preferences saved between sessions.
+date: 2026-04-29 12:00:00
+authors: ['noley-holland']
+tags:
+  - changelog
+issues:
+  - https://github.com/FlowFuse/flowfuse/issues/6267
+---
+
+The drawer in the immersive editor used to float over your canvas, blocking parts of your flow whenever it was open. Now it sits inside the editor layout, so FlowFuse tools stay visible alongside your work in Node-RED. You can also set it up the way you like, and it stays that way every time you come back:
+
+![Pinning, moving, and full-screening the immersive editor drawer](./images/immersive-ui-drawer.gif){data-zoomable}
+*Pin, switch sides, or go full-screen from the drawer header — your settings persist between sessions.*
+
+- **Pin the drawer** to dock it alongside the canvas, and the Node-RED editor resizes to fit.
+- **Switch sides** to move the drawer to the left or right of the screen.
+- **Go full-screen** to hide the FlowFuse topbar and give the canvas maximum space.
+- **Resize the drawer** to whatever width works best for you.
+
+The drawer opens by default the first time you visit the editor. After that, your browser remembers your choices between sessions.
+
+This feature is available to all FlowFuse Cloud users and Self Hosted users from v2.30.