Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tamWhy
led_enableAll 1
Turns a lamp off when executed?
• led_enableAll 1 turns your lamp off because, in the particular device you are using, the LED-enable line is wired as active-low.
• A logic HIGH (1) disables the LED driver, while a logic LOW (0) enables it, so the command values appear “reversed” from what you might expect.
Active-Low vs. Active-High logic
• Active-High: 1 = ON, 0 = OFF – most intuitive.
• Active-Low: 0 = ON, 1 = OFF – the enable pin (often labelled EN¯, EN#, or ~ENABLE) is internally inverted.
– The microcontroller pin idles HIGH through a pull-up resistor.
– Pulling it LOW closes the driver’s MOSFET or transistor, completing the LED current path.
Why designers pick active-low for LED enable lines
• Fail-safe default – If the MCU is in reset or the line is left floating, the pull-up keeps the lamp OFF.
• Open-drain compatibility – Many MCUs or driver ICs only sink current; an external pull-up produces the HIGH (OFF) state.
• Noise immunity – Long lines sitting at VCC are less susceptible to spurious LOW-level noise.
• High-side switch topology – A P-channel MOSFET often needs its gate driven HIGH (close to VCC) to switch off the load.
How this reaches you in firmware
• In OpenBeken / Tasmota-derived builds the shell command led_enableAll <level> writes the raw logic level to the GPIO that gates the LED driver.
• No automatic inversion is added unless the board file (or a run-time pinMode flag such as PIN_INVERTED) explicitly requests it.
• Therefore, two bulbs from different vendors can exhibit opposite behaviour:
– Bulb A (active-high): led_enableAll 1 → ON
– Bulb B (your case, active-low): led_enableAll 1 → OFF
Quick verification
• Issue led_enableAll 0 – the lamp should come on.
• Measure the enable-pin voltage: ≈ 0 V when ON, ≈ VCC when OFF.
Online community pages for OpenBeken (Elektroda, GitHub, Tasmota forums) document both variants:
• Users add led_enableAll 1 to autoexec.bat to make some bulbs light up after reboot (active-high hardware).
• Others, exactly like your report, must write led_enableAll 0 instead (active-low hardware).
Recent firmware commits (mid-2024) introduce a per-pin invert flag so that scripts can stay human-readable (1 = ON) independent of hardware. Up-to-date builds expose it via the pinSetInverse command.
Typical circuits
• Low-side N-MOS (active-high): MCU HIGH → NMOS ON → LED ON.
• High-side P-MOS (active-low): MCU LOW → PMOS ON → LED ON, MCU HIGH → PMOS OFF (lamp OFF).
Example timing diagram
MCU pin -------____--------- (LOW pulse)
LED current ___----_________ (lamp ON during LOW)• No special ethical concerns; just ensure mains-connected bulbs remain off by default for safety.
• Observe CE/FCC and local electrical codes if you modify hardware.
led_enableAll 0 to turn the lamp on, led_enableAll 1 to turn it off. pinSetInverse <gpio_number> 1 or compile with PIN_INVERTED.Potential challenges
• Mixed-polarity boards (RGB enable active-low, white-channel enable active-high) – handle each pin separately.
• Firmware older than 2022-11 may lack the inversion flag; update first.
• Behaviour is board-specific; always consult the module’s schematic or datasheet if available.
• Some bulbs tie the enable pin to the PWM lines internally; led_enableAll may then act as a global mute rather than a hard switch.
• Study your bulb’s driver IC (e.g., SM2135, BP1658CJ). Its datasheet will label the enable pin polarity.
• Follow OpenBeken pull requests on GitHub for the new enablePolarity abstraction.
• Explore IEC 60730 classified fail-safe design practices for consumer lighting.
led_enableAll 1 switches your lamp off because the enable pin in your device is active-low. The firmware merely passes the value you give it straight to the GPIO; a HIGH disables the LED driver, a LOW enables it. Use led_enableAll 0 or invert the pin in software to restore the intuitive “1 = ON” behaviour.