Tasmota: Fade setting ignored when mains power is applied

[TimelessNL]

PROBLEM DESCRIPTION

When mains power is applied, FADE 1 and SPEED 15 settings are ignored and instead turns on at dimmer level brightness immediately.

REQUESTED INFORMATION

• ✅ Read the Contributing Guide and Policy and the Code of Conduct
• ✅ Searched the problem in issues
• ✅ Searched the problem in the docs
• ✅ Searched the problem in the forum
• ✅ Searched the problem in the chat
• ✅ Device used (e.g., Sonoff Basic): Any device with at least 1 PWM channel
• ✅ Tasmota binary firmware version number used: 8.2.0
  
  
  
  • ⛔️ Pre-compiled
  
  
  • ✅ Self-compiled
  
  
  • ✅ IDE / Compiler used: ArduinoIDE SDK 2.6.3
  
  
• ✅ Flashing tools used: Web OTA
• ✅ Provide the output of command: Backlog Template; Module; GPIO 255:

23:51:33 CMD: Backlog Template; Module; GPIO 255
23:51:33 RSL: RESULT = {"NAME":"LSC RGBW LED","GPIO":[0,255,0,255,0,0,0,0,181,0,180,0,0],"FLAG":15,"BASE":18}
23:51:34 RSL: RESULT = {"Module":{"0":"LSC RGBW LED"}}
23:51:34 RSL: RESULT = {"GPIO0":{"0":"Geen"},"GPIO1":{"0":"Geen"},"GPIO2":{"0":"Geen"},"GPIO3":{"0":"Geen"},"GPIO4":{"0":"Geen"},"GPIO5":{"0":"Geen"},"GPIO9":{"0":"Geen"},"GPIO10":{"0":"Geen"},"GPIO12":{"181":"SM2135 Dat"},"GPIO13":{"0":"Geen"},"GPIO14":{"180":"SM2135 Clk"},"GPIO15":{"0":"Geen"},"GPIO16":{"0":"Geen"}}

• ⛔️ If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:
• ⛔️ Provide the output of this command: Status 0:
• ⛔️ Provide the output of the Console log output when you experience your issue; if applicable:

TO REPRODUCE

1. Flash Tasmota 8.2.0
2. Command reset 5
3. Configure device to have atleast 1 PWM channel.
4. Command backlog fade 1; speed 15; restart 1;
5. Unplug power.
6. Apply power.
7. See that it turns on at configured brightness without fading.

EXPECTED BEHAVIOUR

Just like FADE is used during soft ON/OFF commands, I expect the device to 'wakeup' and uses FADE when power is applied. This worked in v8.1.0.

SCREENSHOTS

N/A

ADDITIONAL CONTEXT

N/A

[s-hadinger]

This is on purpose, Fade does not work well when you restart the Tasmota device. The fading would start then freeze after a fraction of second (wifi scan?) and restarts again. So by default it is disabled to avoid annoying behavior.

You can simulate this with rules, and start the fading right after wifi scan. To see what it looks like you can try PowerOnState 0 and Rule1 ON Power1#Boot DO Power On ENDON and Rule1 1. Then you can adjust as you wish.

[TimelessNL]

Ah ok, maybe I've missed it but it would have been nice to read it somewhere on the WIKI or Commit history that the behavior has changed.

As for me, I always liked the slow start feature so it mimics a fluorescent bulb. Even if there is a small hickup in the animation. Would it be possible to make it a setoption setting so people can decide if thet want fade on startup or not? Maybe something like setoptionX 0 is off and setoptionx > 0 is the speed for the startup fade, that way we can have an independent speed for normal and startup fade and thus the hickup is less noticeable.

Thanks for the rule suggestion, only downside is that it causes 1 additional flashwrite since the powerstate is toggled every boot. Except when you set setoption0 off

EDIT: When a scheme is set to run at powerup (_for example_ scheme 3) it will still slowly fade in as it did on v8.1.0. Which means there is different behavior when a light is configured as color 1 or scheme 3.

[TimelessNL]

You can simulate this with rules, and start the fading right after wifi scan. To see what it looks like you can try PowerOnState 0 and Rule1 ON Power1#Boot DO Power On ENDON and Rule1 1

I tried your given rule, and my SM2135 devices seem to fade-in just fine, but on my PWM driven bulbs (_Filament WW/CW_) it does not, probably because the SM2135 is not so quick to respond. PWM bulbs do wake but when the FADE is finished it briefly turns completely OFF and then ON again after which it remains stable. So I think the POWERONSTATE 0 and POWER ON are conflicting somehow, yet I see no mention of this and in the console there is no OFF reference to be found.

I also tried to disable MQTT so POWERRETAIN was not an issue, and still this weird FADE->OFF->ON was happening at warm/cold reboot.

Rule1 ON System#Boot DO Wakeup ENDON; Does fade in nicely but since it waits for WiFi to be connected it takes to long for the lamp to be 'ON' after power has been applied.

EDIT: It does that ON->OFF->ON effect also without the rule. So something is not quite right when Tasmota is soft/cold started 🤔

EDIT2: I flashed v8.1.0 and closely looked at the wake-up effect and noticed that the light is also briefly reduced after the wake-up has finished. I noticed this before but I always though this was related to the bulb itself and not Tasmota. So it seems that it was always there but now instead of a small dip in lightoutput it is completely turned of.

[Jason2866]

If you compile yourself (not so easy possibel with Arduino IDE) and use
Tasmota feature stage core (Arduino commit e64cb619f...) the blinking on off on
is maybe gone. Tasmota development has a code change for this.
ONLY possible since the Arduino commit written before.
Your used Arduino Core 2.6.3 is too old.

[TimelessNL]

If you compile yourself (not so easy possibel with Arduino IDE) and use
Tasmota feature stage core (Arduino commit e64cb619f...) the blinking on off on
is maybe gone. Tasmota development has a code change for this.
ONLY possible since the Arduino commit written before.

Do you mean this commit? But shouldn't that be happening very early at boot? Because the ON->OFF->ON behavior I'm experiencing is more like 3sec after boot.

Even though when I compile both v8.2.0 and v8.1.0 against v.2.6.3 (release) I get different behavior. Isn't that strange?

Your used Arduino Core 2.6.3 is too old.

But the v8.2.0 public release is build against v2.6.3 (372a3ec) and is thus also affected by this bug?

[Jason2866]

Yes, Tasmota release version is build on commit 372a3ec. The GPIO blink fix
is NOT in the used commit for the release version 8.2.0 or in any precompiled bin.
You have to compile yourself (easy with Platformio using Platformio_override.ini) or copy manually the needed files in Arduino IDE from commit

Release 8.1.0 and 8.2.0 uses different Arduino Core versions
Tasmota was never build and released with core 2.6.3
If Arduino Core 2.7. is released a update Tasmota 8.2.1 release will be done

[s-hadinger]

@TimelessNL It seems easy to add a SetOption to decide whether Fade is used at startup or not. Is it still useful?

[TimelessNL]

Yeah that means PowerOnState is still used and not overruled by the given rules. This makes it easier to understand in my opinion.

[TimelessNL]

Yes, Tasmota release version is build on commit 372a3ec. The GPIO blink fix

But this commit fixes an "early boot" GPIO initialization issue. This is not what I'm seeing my ON->OFF-ON bug happens +/-3sec after boot, I don't think my issue is fixed by this commit?

[s-hadinger]

I do see a change in colors briefly at power on for PWM, because the interrupt storm of wifi connection disturbs the PWM interrupts. But it's not a complete ON-OFF-ON.

In the meantime, you can force fade at startup by just changing one line in code:
in file xdrv_04_light.ino line 274, change to bool fade_initialized = true; (instead of false)

[s-hadinger]

PR submitted.

[TimelessNL]

Wow! fast response, thanks!

[TimelessNL]

I do see a change in colors briefly at power on for PWM, because the interrupt storm of wifi connection disturbs the PWM interrupts. But it's not a complete ON-OFF-ON.

In the meantime, you can force fade at startup by just changing one line in code:
in file xdrv_04_light.ino line 274, change to bool fade_initialized = true; (instead of false)

May I ask what hardware you're using? I've run tests on a H801 and LSC Filament bulb, and they both share this ON->OFF->ON issue. I did test a NodeMCU with one of its onboard LEDs (GPIO16) as PWM, and where my H801 and LSC devices show this behavior every boot, the NodeMCU only shows it once it a while... very strange.

[s-hadinger]

I'm testing with MagicHome led driver. I also have E14 bulbs RGBW driven by PWM. I've never seen a full ON-OFF-ON.

Can you enable WebLog 4 and share the logs?

[arendst]

I think with regards to the power ON-OFF-ON this is the same issue as #8046

If I look sharp at my LC01 with three channel PWM I do see this phenomenon in a mild way too. After about 4 seconds, when the wifi tries to connect, I see a slight increase in brightness which resumes soon to the the correct one.

I've tried without Network scan on power up, MQTT and power cycle detection (which writes to flash) all to no avail. I believe, as @s-hadinger also suggested it is the wifi storm which stalls the PWM cycles. Depending on how wifi performs this may result in complete OFF as some users experience.

[TimelessNL]

I do see a change in colors briefly at power on for PWM, because the interrupt storm of wifi connection disturbs the PWM interrupts.

Yeah this seems to be the same for me on <= v8.1.0, it was never a problem for me just a side effect of software PWM. But v8.2.0 seems to have made things worse, it almost seems some value is reinitialized and therefor switches OFF->ON 🤔

But it's not a complete ON-OFF-ON.

May I ask what hardware you're using? I've run tests on a H801 and LSC Filament bulb, and they both share this ON->OFF->ON issue. I did test a NodeMCU with one of its onboard LEDs (GPIO16) as PWM, and where my H801 and LSC devices show this behavior every boot, the NodeMCU only shows it once it a while... very strange.

Depending on how wifi performs this may result in complete OFF as some users experience.

@arendst To my knowledge you also have the SM2135 type LSC bulbs, do you by any chance also have the Filament style E14/E27? Since all the Filament style LSC bulbs I tested go ON->OFF->ON on v8.2.0. Because I also saw this small dip in brightness on v8.1.0 and below, but v8.2.0 made things worse (_same SDK 2.6.3_)

[TimelessNL]

But regarding to the OP, this issue has been fixed by @s-hadinger .
So better continue the ON->OFF->ON issue in #8046?

[arendst]

Let's continue in #8046