The Problem

Many IoT relay modules are excellent for turning things on and off, but they assume the controller is always alive.

That works for a lamp or a small hobby project. It becomes a problem when the controlled equipment must maintain a known physical state.

Imagine:

• A valve that should remain open during a short power interruption.
• A bypass circuit that must stay selected while a controller restarts.
• A motorized system where an unexpected relay change could create a dangerous movement.
• An installation where cloud services should never decide whether equipment operates.

Traditional relays usually require power to hold their position. When the controller loses power, the output disappears and the system may return to an unwanted state.

Reliable automation needs something different: hardware that remembers.

No holding current, no state loss on a brownout, no surprise re-homing after a reboot.

That's the specific problem Make Things Happy's IoTextra Octal3 module is built around, and it's why I wanted to get it working end-to-end with the existing IoTflow and IoThome software stacks before it's even fully out the door.

The Hardware

The IoTextra Octal3 combines two important pieces of automation hardware into one compact module:

• 4 isolated digital inputs
• 4 bistable (latching) relay outputs

The isolated inputs allow external sensors, switches, and control signals to connect safely without directly exposing the controller electronics.

The bistable relays are the key feature. Instead of keeping a coil energized continuously, they use a pulse to mechanically change position. Once switched, they stay there without consuming additional power.

This provides several advantages:

• State retention during power outages
• No wasted energy holding relay coils
• Predictable recovery after reboot
• Reduced risk of unexpected switching

The result is a modular I/O building block rather than a one-purpose relay board.

Wiring it into the stack

The two software layers this integrates with solve different problems:

• IoTflow is the no-code orchestration layer: a MicroPython kernel on the MCU side, MQTT as the transport, and Node-RED flows for the actual automation logic. It's the natural fit if you're coordinating the Octal3 alongside other IoTextra nodes on a network, or building out a Node-RED dashboard for manual/automatic valve control.
• IoThome sits on top of Tasmota instead, using Berry script drivers and pre-built GPIO templates so a node runs standalone — no broker, no server, fully on-device — which is the better fit for a single smart-home gate or blind controller that needs to keep working even if your home network has a bad night.

Controllers used:

• IoTsmart a compact System-on-Module (SOM) board based on ESP32-S3, RP2350A, and other MCUs that plug directly into IoTextra modules. These are designed for IoT-based distributed sensing and control.
• IoTbase a robust controller platform with better thermal management, more mounting options, and serial debugging capability during operation. You'd migrate to IoTbase when you need more I/O expansion, professional enclosure mounting, or are deploying in harsher environments.

Where this fits: IIoT, telecom, farming, home

The reason to reach for latching relays specifically, instead of the cheaper Relay2 or SSR modules already in the IoTextra lineup, comes down to what happens during the moments you're not actively controlling anything:

• Industrial automation — pneumatic valves and dampers on a packaging line that must not move during a brief control-power dropout or a PLC/controller reboot. A stuck-open or stuck-closed valve at the wrong moment can mean scrapped product or a jam; a latching relay simply can't drift.
• Telecommunications — physical bypass and backup-line switching in unattended cabinets. Once a bypass path is selected, it needs to stay selected for years without anyone maintaining...