New Blind

• @cgjgh/node-red-dashboard-2-ui-scheduler
  3.3.7

• @flowfuse/node-red-dashboard
  1.30.2

• @sammachin/node-red-matter-bridge
  0.12.3

• @sammachin/node-red-matter-controller

0.1.6

•  node-red-node-email

Alexa routines triggered by virtual contact sensors require a state transition (changing explicitly from true to false or vice-versa) to fire, a single static state will fail to re-trigger a routine during a retry loop.

The "Flicker" Function Node fixes this by quickly pulsing the mattercontactsensor to the opposite state and back again, ensuring Alexa always registers a fresh edge-trigger, even if the target state hasn't changed.

The "Flicker" Function Node Code

javascript

// 1. Send the instant inverse state to clear Alexa's transition requirement

let flickerMsg = {

    payload: !msg.payload

};

node.send(flickerMsg);

// 2. Clone the original message to preserve its properties and target payload

let targetMsg = RED.util.cloneMessage(msg);

// 3. Wait 1 second (1000ms) internally, then send the actual target state

setTimeout(function() {

    node.send(targetMsg);

}, 1000); 

// Return nothing directly at the bottom since node.send handles it asynchronously

return;

Here is the complete, finalized automation report.

It is specifically structured as a single, clean markdown document optimized for Google Sites. Because Google Sites strips out raw markdown horizontal rules (---) and native container dividers when pasting, this layout uses bold, bordered text spacing and clear structural blocks so it mimics a professional desktop report layout the moment you insert it into a text box or embed element.

NODE-RED SYSTEM AUTOMATION & INFRASTRUCTURE REPORT

MODULE: ROLLER BLINDS INTEGRATION AND STATUS VERIFICATION

=========================================

1. SYSTEM ECOSYSTEM & HARDWARE TOPOLOGY

=========================================

The roller blind automation framework operates within a hybrid smart home ecosystem, bridging local physical sensors, regional hardware routing layers, cloud environments, and Node-RED logic engines.

• Physical Blinds Control: The motorized blinds are operated natively via a standalone hardware remote control. Additionally, they are exposed to the Amazon Alexa smart home ecosystem as native appliances, having been added to Alexa directly through the manufacturer's Aqara App.

• Ecosystem Visual Deficit: A critical limitation of both the native Aqara application layer and cloud-based Alexa voice routines is an inability to track real-time physical states. Commands sent over these connections occasionally drop or fail without feedback. This Node-RED framework serves as the definitive "eyes and ears" to address this limitation.

• The Ikea MYGGBETT Sensor: Mounted physically on the roller blinds to determine the true state value (OPEN vs. CLOSED). These hardware sensors communicate over the Matter-over-Thread wireless mesh network protocol.

• The Local Network Bridge: The physical MYGGBETT Thread sensors route their radio signals directly into an Aqara Thread Border Router. This router translates the local Thread mesh packets onto the home network.

• Node-RED Implementation Layer: The flow integrates the custom @sammachin/node-red-matter-controller and @sammachin/node-red-matter-bridge node suites. The node labeled Blind_UpDown (mattercontactsensor) operates as a Virtual Matter Contact Sensor Device. This virtual appliance is exposed by Node-RED onto the local network, allowing Alexa to discover it and run targeted routines based on its state changes.

=========================================

2. FUNCTIONAL OPERATIONS PIPELINE

=========================================

The automation software logic is divided into four distinct phases designed to prevent duplicate signaling, handle timing windows, and verify hardware completions.

• Phase 1: Boot-Time Variables Initialization
  On system startup, an initial change node clears and formats essential flow-context properties (flow.loopStatus, flow.Origin, flow.UpDown). This sweeps away residual data to ensure a clean tracking foundation.

• Phase 2: Triggering and Intent Pre-Checks
  Actions are initialized either by a user altering the dashboard interface manually or by the background ui-scheduler firing a timed entry. Before routing forward, a switch node verifies the payload against flow.UpDown. If the incoming instruction matches the last confirmed position, the request is discarded to protect the blind motors from unnecessary strain.

• Phase 3: Central Execution and Retry Mechanism
  Once an unmatched target intent is validated, the central ui-switch passes the instruction down into the verification engine. It establishes a busy status context and routes the transaction message into a 55-second background delay node. If the hardware fails to report back within this 55-second window, the system increments a counter, logs a "Somfy Call" attempt, and re-fires up to a maximum of 3 recursive loops before terminating.

• Phase 4: Hardware Verification and State Synchronization
  When the blind begins to open or has completely closed, the physical MYGGBETT sensor captures the state change and issues a Thread packet through the border router. Node-RED intercepts this event via a live Matter subscription node. This sensor update changes flow.loopStatus to "stop", flags the UI template animations as "idle", updates the dashboard tracking log, and updates the virtual Alexa bridge.

=========================================

3. CORE DESIGN CHARACTERS & PERSISTENCE

=========================================

The Dashboard 2 "Passthru" Characteristic

The dashboard switch node (4f634ad28a27076f) operates simultaneously as an interactive control panel element and a state display mirror. By enforcing "passthru": true, any message hitting the node's back input (such as manual overrides or Alexa commands) instantly passes through to the front output. The flow uses a flow.Origin filter string to safely separate automatic looping triggers from background hardware notifications.

Message Snapshotting Behavior Across Delays

When an active transaction message enters the 55-second delay node (30bd14e9f329b25b), Node-RED freezes its exact payload state (including msg.retryCount) on a temporary memory shelf until the timer expires. Because these properties are frozen during the countdown, downstream nodes must actively purge or clean up historical message context strings to prevent stale values from executing after the loop successfully terminates.

Pageview Synchronisation Handling

A Detect Page Load (4391abf62ce041f6) event node listens for dashboard client instances. When a browser tab is opened or refreshed, it fires a "$pageview" topic trigger that polls the live blind status using a matterreadattr attribute node.

This synchronization path is essential to convey the actual blind status in the event of operation by the standalone remote control. Because standalone remotes function outside of Node-RED's core logic, this pageview trigger bridges the gap, forcing the browser to read the true state of the room via the MYGGBETT sensor and correctly position the desktop switch widget.

3. CORE DESIGN CHARACTERS & PERSISTENCE

=========================================

The Dashboard 2 "Passthru" Characteristic

The dashboard switch node (4f634ad28a27076f) operates simultaneously as an interactive control panel element and a state display mirror. By enforcing "passthru": true, any message entering the node's back input is instantly passed through to its front output.

The messages hitting the node's back input come from two separate hardware tracking paths:

• The mattersubscribe path: Fires automatically whenever the physical MYGGBETT sensor registers a change in the blind's position.

• The matterreadattr path: Fires on demand due to events initiated by manual remote overrides, a desktop display refresh ($pageview), a recovery attempt following a failed request, or verbal Alexa commands.

Because every single one of these back-input events causes the switch to spit a message out of its front output, the downstream flow relies heavily on the Filter Origin gateway. This filter reads the flow.Origin text string to separate routine background status reflections from active, automated loop requests.

Complete, Updated Section 3 & 4 (Optimised for Google Sites Copy/Paste)

=========================================

## 3. CORE DESIGN CHARACTERS & PERSISTENCE

=========================================

### The Dashboard 2 "Passthru" Characteristic

The dashboard switch node (4f6 control panel element and a state display mirror. By enforcing "passthru": true, any message entering the node's back input is instantly passed through to its front output. 

The messages hitting the node's back input come from two separate hardware tracking paths:

* The mattersubscribe path: Fires automatically whenever the physical MYGGBETT sensor registers a change in the blind's position.

* The matterreadattr path: Fires on demand due to events initiated by a failed request a desktop display refresh ($pageview), so that the ui-switch is resynchronised to the correct state irrespective of whether the blinds have been operated by a manual remote or elsewhere.

Because every single one of these back-input events causes the switch to spit a message out of its front output, the downstream flow relies heavily on the Filter Origin gateway. This filter reads the flow.Origin text string to separate routine background status reflections from active, automated loop requests.

### Message Snapshotting Behavior Across Delays

When an active transaction message enters the 55-second delay node (30bd14e9f329b25b), Node-RED freezes its exact payload state (including msg.retryCount) on a temporary memory shelf until the timer expires. Because these properties are frozen during the countdown, downstream nodes must actively purge or clean up historical message context strings to prevent stale values from executing after the loop successfully terminates.

### Pageview Synchronisation Handling

A Detect Page Load (4391abf62ce041f6) event node listens for dashboard client instances. When a browser tab is opened or refreshed, it fires a "$pageview" topic trigger that polls the live blind status using a matterreadattr attribute node. 

This synchronization path is essential to convey the actual blind status in the event of operation by the standalone remote control. Because standalone remotes function outside of Node-RED's core logic, this pageview trigger bridges the gap, forcing the browser to read the true state of the room via the MYGGBETT sensor and correctly position the desktop switch widget.

=========================================

4. SYSTEM DIAGNOSTICS & METADATA OVERLAPS

=========================================

During system optimization, an inconsistency was discovered where a freshly created simulation schedule would display "Success," but a live, recurring production schedule would display "FAILED" on the UI layout despite the blinds physically opening correctly.

The diagnosis revealed a metadata conflict caused by the scheduler node's configuration:

"storeName": "local_file_system"

"commandResponseMsgOutput": "fanOut"

When a production schedule runs as a stored calendar item, the @cgjgh/node-red-dashboard-2-ui-scheduler node attaches historical payload metadata tracking variables (msg.scheduler.config) to the message.

While the 55-second delay timer is counting down, a successful local sensor event changes flow.loopStatus to "stop". When the original delayed message wakes up, it correctly registers this stop instruction and forwards the transaction to the successful completion block (DONE node).

However, because the message still carries the persistent file-system calendar configuration object, the Dashboard 2 dynamic layout renderer misinterprets the metadata as an active instruction or UI layout change. This causes the widget container to reject the text string, defaulting back to its structural fallback state: FAILED.

=========================================

5. SYSTEM OPTIMIZATION PRESETS

=========================================

To safeguard the flow against metadata pollution and multi-platform timing overlap, the following structural adjustments are applied to the core change blocks:

• 1. Metadata Erasure Rule: Inside the successful completion node (DONE, 479c7a5b62027f63), an explicit Delete msg.scheduler instruction is executed. This completely strips the calendar footprint from the message container before it updates the interface layout.

• 2. Counter Cleanup Rule: The success node also executes a Delete msg.retryCount instruction. This purges frozen loop states, ensuring the rendering engine only evaluates current parameters.

• 3. Text Payload Enforcement: The success node explicitly forces msg.ui_update.label to "Success in: " and msg.ui_update.color to "black". This forces a clean visual confirmation on the desktop panel regardless of system background updates.

Proactive Next Steps

If you want to enhance this layout inside Google Sites, you can use the Embed Code option (</>) on your page and paste this text directly into an HTML/Embed Window. This will preserve the exact system layout and font choices beautifully. Let me know if you would like me to generate the raw HTML code block for that embed window instead!