Short answer: for machinery and any load that can move, heat, pressurize, or surprise someone, the safest normal behavior is for the RF receiver to restart with its outputs off and wait for a fresh, intentional command. Restoring the previous output state can be useful, but it should be a deliberate system requirement—not an accidental result of whatever the receiver remembers.
This question rarely appears during the first bench test. The remote works, the relay changes state, and the project moves on. Then the site has a short outage at 2 a.m., power returns, and a pump, gate, fan, or contactor behaves differently from what everyone expected. By that point the problem is no longer “wireless.” It is restart behavior, and restart behavior belongs in the control specification.
Relay mode does not answer the power-recovery question
Momentary, toggle, and latched modes describe how the output responds to radio commands while the receiver is running. They do not automatically tell you what the output will do after the supply disappears and returns.
A toggle channel may come back off, restore its last state, or briefly pulse during startup. A mechanically latching relay may physically remain in position without power, while a standard relay driven by stored software state will release during the outage and may energize again after the controller boots. Those are very different electrical behaviors, even if both products are described as “latching.”
When I review a receiver for a real machine, I want a separate answer to this question: after a complete power cycle, what is the guaranteed state of every output, and how long does it take to reach that state?
The four restart behaviors you are likely to encounter
1. All outputs restart off
This is the cleanest behavior for most industrial controls. The relay coils drop out during the outage and remain off after power returns. The operator must send a new command before anything runs.
The important word is “remain.” A good design holds the outputs inactive while the supply rises, the microcontroller resets, memory is checked, and the radio section starts. There should not be a short relay pulse during that interval.
2. The receiver restores its last commanded state
The controller records the state in non-volatile memory and reapplies it after reboot. This is useful for lighting, irrigation zones, ventilation, and other applications where continuity is more valuable than manual restart.
It is also where designers need discipline. Memory must only be written when the state genuinely changes, not continuously, or flash endurance can become the next failure. The stored record should survive an interrupted write, and an invalid record must lead to a known safe default.
3. The receiver requires an enable or reset sequence
Some systems restart with outputs off but will not accept an operating command until a separate enable, acknowledge, or local reset has occurred. This is often a sensible compromise for equipment used beyond direct sight.
It prevents an old or queued command from restarting the machine and gives the operator a clear indication that the system has rebooted. The extra step should be intentional and documented; otherwise users will treat it as a fault and begin bypassing it.
4. The output state is undefined during startup
This is not a feature, but it still appears in poorly integrated systems. A relay input may float before the processor configures its pins. A supply rail may rise too slowly. The radio board may reboot while the relay board remains energized. The result can be a click, a pulse, or a short unintended output.
If the supplier cannot state the startup output behavior, test it before connecting the receiver to a consequential load. “It did not happen on my desk” is not a restart specification.
Brownouts cause more trouble than clean power cuts
A complete outage is relatively easy: voltage disappears, relays release, and everything starts again from zero. A brownout is less polite. The voltage falls far enough to upset the microcontroller but not far enough to release every relay or discharge every capacitor.
During a brownout, different parts of the receiver can reset at different times. The radio chip may stop first, the processor may repeatedly reboot, and the relay driver may remain partially powered. A weak DC supply, long cable run, undersized transformer, or motor starting on the same supply can create exactly this condition.
I normally check three things:
Does the controller have a defined brownout-reset threshold?
Are the outputs forced off by hardware while reset is active?
Does the power supply recover cleanly under the worst load step?
If a receiver repeatedly resets when a contactor pulls in, changing the remote or pairing it again will not solve the fault. Measure the supply at the receiver terminals with the load operating. A multimeter may miss a fast dip; an oscilloscope is better when the failure is intermittent.
Choose the restart policy from the load, not the convenience
Motors, gates, winches, and moving mechanisms
Default to outputs off. Require a fresh command and preserve electrical or mechanical interlocks independently of the radio logic. If the equipment can continue moving because of inertia, gravity, or stored pressure, stopping the relay is only one part of the safe-state design.
Pumps and valves
Ask what happens to the process during the outage. A circulation pump may reasonably resume; a transfer pump filling an unattended tank may not. A valve may fail open, fail closed, or remain in place depending on its actuator. The receiver's relay state should match the process hazard analysis, not just the previous button press.
Lighting and non-critical auxiliary loads
Restoring the previous state is often acceptable and can be more convenient. Even here, consider whether dozens of receivers will all re-energize at once when site power returns. Staggered restart or a central enable can reduce inrush current.
Receivers connected to a PLC or machine controller
The RF receiver should usually provide a clean command input, while the PLC owns restart permission, sequencing, and interlocks. That division makes fault handling easier to understand. It also prevents a receiver's memory setting from quietly overruling the machine's established restart policy.
A practical power-cycle test
Do not test only one clean on-off cycle. Use the actual supply, actual enclosure, and actual load interface. Then record the output state instead of relying on the sound of the relay.
Command every output on and off in each supported operating mode.
Remove power for 30 seconds, restore it, and record every output during startup.
Repeat with power removed for only one or two seconds.
Cycle power several times quickly to imitate a poor connector or unstable mains supply.
Reduce the supply slowly through the receiver's operating range and then raise it again.
Repeat while the connected motor, solenoid, or contactor is switching.
Check whether paired transmitters, mode settings, timers, and interlocks are retained.
Confirm what the operator sees after recovery: ready, fault, unpaired, or waiting for enable.
For multi-channel units, watch all channels. A controller that restores channel 1 correctly may still pulse another output while its I/O pins initialize.
Questions worth putting on the purchase specification
What is the guaranteed output state during power-up and processor reset?
Does the receiver remember the last output state after complete power loss?
Is state retention configurable per channel or fixed for the whole receiver?
Are pairing data and operating-mode settings stored separately from output state?
What happens if power fails while memory is being written?
At what voltage does brownout reset occur?
Can any output pulse during startup or shutdown?
Is a new radio command, local reset, or enable signal required after recovery?
How is recovery indicated to the operator or host controller?
These questions are more useful than asking only whether a receiver has “memory.” Memory of paired remotes, memory of output state, and memory of configuration are three separate functions.
The field rule I use
If an unexpected restart could make someone step back, spill material, move a mechanism, or damage a process, the receiver should not automatically resume from one stored bit. Bring the outputs up in a known state, re-establish the interlocks, and require an intentional command.
Where automatic restoration is genuinely needed, document exactly which state is retained, how corrupted memory is handled, and what the equipment does while the controller is booting. Power recovery should be boring. When it becomes memorable, the design work was usually done too late.