OpenBeken, Tasmota, OEM Switches: Set Power-On State Always ON for Smart Relays

User question

Gostaria de redefinir o power on state de um Switch para sempre on

Artificial Intelligence Response

Direct answer to the question

• Goal: Make the switch always turn ON after any power-up (power restored or cold boot).
• Quick actions (pick the one that matches your firmware):
  • OpenBeken (BK7231x): Web UI → Configure → Startup → set the channel’s Start Value to 1 (Always ON). Or in Console: StartupState 1 (older builds may use setPowerOnState 1).
  • Tasmota: Console → PowerOnState 1.
  • OEM apps (if not custom firmware): Look for “Power-on state” (a.k.a. Estado ao Ligar) and set to ON, or Last State if that’s preferred.

Detailed problem analysis

• What “Always ON” changes:
  • Cold power-up default: The relay (or output channel) is forced to ON as soon as the device boots, regardless of the previous state.
  • Distinction vs “Last State”: “Last State” restores the state stored before the last power loss; “Always ON” ignores history and forces ON.
• Firmware-specific behavior:
  • OpenBeken
  • Per-channel startup: For each relay/output channel, a “Start Value” can be set to:
    • 0 = Always OFF
    • 1 = Always ON
    • −1 = Remember Last (restore)
  • Console equivalents: StartupState 1 (global) exists on most recent builds; some older builds used setPowerOnState 1. When uncertain, prefer the Web UI per-channel Start Value.
  • Failsafe scripting: If needed, add to autoexec.bat: setChannel 1 1 (repeat for each channel as required).
  • Tasmota
  • Global setting: PowerOnState X applies to all relays (multi-gang devices follow the same default unless scripted).
    • 0=Keep OFF, 1=Always ON, 2=Toggle, 3=Restore Last (default on many templates), 4/5 special modes.
  • MQTT interactions: Retained commands from your broker/automation can override the boot state right after connect; see “Practical guidelines”.
  • OEM ecosystems (eWeLink/Sonoff, Tuya/Smart Life, etc.)
  • Many devices expose “Power-on state: On / Off / Last State”. Not all models support it; some only support “Last State”.
• Hardware implications:
  • Inrush and contact stress: Forcing ON on boot can hit the relay with inrush (PSUs, LED drivers, motors). Verify the relay/contact ratings and consider inrush limiting if needed.
  • Brownouts/rapid cycling: On unstable mains, repeated ON cycles may occur. Consider adding a power-on delay in firmware or via automation if the load is sensitive.
  • Decoupling wall button (if you need the circuit “always hot”):
  • If the goal is to keep a smart bulb permanently powered, detach the local button from the relay (logical decoupling) and use the button only to send a command (MQTT/HTTP/scene) instead of cutting power.

Current information and trends

• Most recent OpenBeken builds expose per-channel Startup values in the Web UI and also accept a global StartupState. Tasmota maintains PowerOnState with the same semantics. Many OEM apps now ship a “Power-on state” toggle, but availability still varies by model and region.

Supporting explanations and details

• Example configurations:
  • OpenBeken (per-channel via UI): Configure → Startup → Channel 1 Start Value = 1 (Always ON). Repeat for Channel 2, 3… if multi-gang.
  • OpenBeken (failsafe script): autoexec.bat lines:
  • setChannel 1 1
  • setChannel 2 1
  • Tasmota (console):
  • PowerOnState 1
  • Optional: Delay or pulsing can be managed via Sleep/PulseTime in specific use-cases, but not needed for simple “always on”.
• Verification routine (recommended):
  • Apply setting → Power-cycle at the breaker (cold start) → Confirm relay energizes within a few seconds of Wi‑Fi boot (or earlier, if local logic handles it before Wi‑Fi up).

Ethical and legal aspects

• Safety first: Forcing ON can unexpectedly energize appliances, heaters, pumps, or machinery after an outage—this may be unsafe for people and property.
• Code compliance: Local electrical codes (e.g., NEC/IEC) and product certifications (UL/CE) may require certain equipment to remain OFF on restoration. Use “Always ON” only where it is safe and compliant.
• Warranty/approval: Custom firmware and modified behavior can void approvals and manufacturer warranties.

Practical guidelines

• Choose the right policy:
  • Always ON: Use for upstream-fed smart equipment that must resume service (network gear, non-hazardous lighting, low-risk loads).
  • Last State: Use where user intent should be preserved without surprises.
• Prevent automations from undoing your setting:
  • MQTT retain: Clear retained cmnd topics on your broker and ensure your automation (e.g., Home Assistant) publishes commands with retain=false to avoid forcing the device back to a previous state right after boot.
• Multi-channel devices:
  • OpenBeken: Set Start Value per used channel.
  • Tasmota: One command covers all channels; add rules only if you need per-channel exceptions.
• Troubleshooting:
  • Setting doesn’t stick: Update firmware; in OpenBeken, check flash save status; in Tasmota, ensure config saving is enabled (default).
  • Boot gets overridden: Check broker retained messages or cloud scenes sending immediate OFF.
  • Button keeps toggling the relay you want “always on”: Detach the button from the relay in the GPIO/role config and handle it via automation.

Possible disclaimers or additional notes

• Firmware naming differences: OpenBeken command names have evolved; when console rejects a command, prefer the Web UI per-channel Startup setting or use autoexec.bat with setChannel.
• Device limitations: Some OEM models don’t expose “Power-on state”; custom firmware may be required to achieve deterministic boot behavior.

Suggestions for further research

• Review your exact model/firmware release notes for the precise command names and any per-channel nuances.
• If integrating with HA/MQTT, read best practices on retained messages and startup synchronization to avoid unintended overrides.
• Consider adding inrush limiting (NTC, soft-start) if your load causes nuisance trips or relay stress at power-up.

Brief summary

• For OpenBeken: Set each relay channel Start Value to 1 (Always ON) in Configure → Startup, or run StartupState 1; as a failsafe, add setChannel X 1 to autoexec.bat.
• For Tasmota: Use PowerOnState 1.
• Verify with a true power-cycle and ensure MQTT/cloud automations aren’t sending retained OFF commands that negate your setting.
• Confirm safety and compliance before forcing equipment to energize automatically.

If you share your device model and firmware (OpenBeken/Tasmota/OEM app), I can provide the exact clicks/commands and, if needed, a ready-to-paste autoexec/script tailored to your channels.

Disclaimer: The responses provided by artificial intelligence (language model) may be inaccurate and misleading. Elektroda is not responsible for the accuracy, reliability, or completeness of the presented information. All responses should be verified by the user.