#25035·Tasmota

Shelly DALI Dimmer Gen3: DaliChannels 5 initializes as 1-channel after cold power-on, but works correctly after Restart 1

Author: qammyCreated Sep 16, 2026Updated Sep 17, 2026

Tasmota_DALI_Restart1_Success.txt Tasmota_DALI_Cold_Boot_Failure.txt

Description

I am experiencing what appears to be a cold-boot DALI/DT8 initialization issue with a Shelly DALI Dimmer Gen3 running Tasmota 15.6.0, connected to a Sunricher SR-2309PRO-5C DT8 RGB+CCT driver.

The system works correctly after a Tasmota software restart, but after a complete mains power cycle Tasmota initializes the light as a single-channel brightness light (lt_st:1), despite DaliChannels remaining correctly stored as 5.

Issuing Restart 1 without changing any DALI configuration causes Tasmota to detect/initialize the light correctly as 5-channel RGBCCT (lt_st:5).

This behaviour is repeatable.


Hardware

Controller

  • Shelly DALI Dimmer Gen3
  • ESP32-C3 v0.4

DALI driver

  • Sunricher SR-2309PRO-5C
  • DALI DT8 RGB+CCT / 5-channel
  • Driver configured for R9 / 5A

The Shelly and Sunricher are powered from the same installation, so both experience a cold start following mains power restoration.


Tasmota version

Tasmota 15.6.0 (release-tasmota32)
Core: 3.3.8
Build: 2026-08-25T09:07:10
ESP32-C3 v0.4

Template

json
{"NAME":"Shelly DALI Dimmer Gen3","ARCH":"ESP32C3","GPIO":[34,4736,0,3840,11360,11392,128,129,0,1,576,0,0,0,0,0,0,0,0,1,1,1],"FLAG":0,"BASE":1}

DALI configuration

After a cold power cycle, the following settings are still correctly retained:

DaliChannels
{"DaliChannels":5}

DaliTarget
{"DaliTarget":1}

DaliBS
{"DaliBS":"OFF"}

DaliLight
{"DaliLight":"ON"}

SetOption37
{"SetOption37":0}

DaliGear reports:

json
{"DaliGear":64,"Present":1,"Address":[1]}

Therefore, the problem does not appear to be loss of the stored DaliChannels 5 configuration.


Expected behaviour

With:

DaliChannels 5

I expect Tasmota to initialize the light as a 5-channel RGBCCT light after both:

  1. A software restart
  2. A complete mains power cycle

Actual behaviour

Complete mains power cycle

After removing and restoring mains power, Tasmota boots with only the T1/brightness control.

MQTT state contains only:

json
{
  "POWER":"ON",
  "Dimmer":100
}

Tasmota discovery subsequently reports:

"lt_st":1

No RGB, HSB, CT or five-channel controls are created.

Software restart

Without changing any configuration, issuing:

Restart 1

causes Tasmota to reboot.

After this reboot, the RGB/CCT controls are immediately available and MQTT state now contains:

json
{
  "POWER":"ON",
  "Dimmer":100,
  "Color":"FF15000000",
  "HSBColor":"5,100,100",
  "White":0,
  "CT":153,
  "Channel":[100,8,0,0,0]
}

Tasmota discovery now reports:

"lt_st":5

The light then operates correctly as RGB+CCT.

This has been reproduced multiple times:

Cold mains boot
    ↓
Brightness/T1 only
lt_st:1

Restart 1
    ↓
RGB+CCT controls
lt_st:5

WebLog 4 comparison

The debug logs show an interesting difference during the very early DALI initialization.

Cold mains boot — failure

Configuration is loaded correctly:

00:00:00.279 DLI: Cfg loaded from file
00:00:00.280 DLI: GPIO4(RXi) and GPIO5(TXi) as light

Tasmota then performs DALI/DT8 communication:

00:00:00.280 DLI: Tx 0x00000199 16 DT0
00:00:00.316 DLI: Rx 0xFFFFFFFF  0 response
00:00:00.316 DLI: Tx 0x0000C108 16 DT8
00:00:00.332 DLI: Tx 0x000001FF 16 DT8
00:00:00.381 DLI: Rx 0xFFFFFFFF  0 response

The restart reason confirms this is a true power-on reset:

"RestartReason":"Vbat power on reset"

The resulting light state is:

"POWER":"ON","Dimmer":100

and discovery reports:

"lt_st":1

Restart 1 — successful initialization

The same configuration is loaded:

00:00:00.279 DLI: Cfg loaded from file
00:00:00.280 DLI: GPIO4(RXi) and GPIO5(TXi) as light

The first DALI query again receives no response:

00:00:00.281 DLI: Tx 0x00000199 16 DT0
00:00:00.317 DLI: Rx 0xFFFFFFFF  0 response

However, the subsequent DT8 query now receives a response:

00:00:00.317 DLI: Tx 0x0000C108 16 DT8
00:00:00.333 DLI: Tx 0x000001FF 16 DT8
00:00:00.377 DLI: Rx 0x00000008  8 response

Further DT8/DALI queries receive valid responses:

DLI: Rx 0x000000A0  8 response
DLI: Rx 0x0000007F  8 response
DLI: Rx 0x000000FE  8 response
DLI: Rx 0x00000015  8 response
DLI: Rx 0x00000000  8 response
DLI: Rx 0x000000FF  8 response

The restart reason is:

"RestartReason":"Software reset CPU"

The resulting state contains the full colour information:

"POWER":"ON",
"Dimmer":100,
"Color":"FF15000000",
"HSBColor":"5,100,100",
"White":0,
"CT":153,
"Channel":[100,8,0,0,0]

and discovery reports:

"lt_st":5

Troubleshooting already performed

Configuration persistence

After cold boot:

DaliChannels = 5
DaliTarget   = 1
DaliBS       = OFF
DaliLight    = ON
SetOption37  = 0

All values persist correctly.

DaliBS

Issuing:

DaliBS 0

causes a scheduled software reboot approximately 9–10 seconds later.

After that reboot, RGB/CCT controls become available.

This appears to be because the resulting software restart causes successful initialization rather than because DaliBS itself changes the channel configuration.

DaliTarget

Likewise:

DaliTarget 1

causes a delayed reboot even though the existing value is already 1.

After the software reboot the colour controls are available.

Restart 1

A plain:

Restart 1

with no DALI configuration changes reliably restores RGB/CCT operation.

This confirms that changing/re-saving the DALI settings is not required.

SetOption46

Startup delay was tested up to:

SetOption46 255

There was no change.

After a complete cold boot the device still initialized with T1/brightness only.

SetOption46 was subsequently returned to 0.

Boot rules

A delayed rule reapplying DALI configuration was tested, but commands such as DaliBS/DaliTarget cause a software restart. When executed following System#Boot, this creates a restart loop.

The rule was therefore disabled and is not part of the current configuration.

Home Assistant

Home Assistant restart workarounds were also tested and subsequently removed.

The behaviour described here is reproduced directly in Tasmota without Home Assistant automation affecting the startup sequence.


Possible cause

The logs suggest a possible timing/race condition during a true mains cold start.

On a cold start, Tasmota begins DALI/DT8 interrogation at approximately 280 ms after startup and receives:

Rx 0xFFFFFFFF  0 response

for the early DT8 query.

After Restart 1, the DALI gear remains powered while the ESP32-C3 restarts. During the subsequent initialization, the DT8 query receives valid responses and Tasmota creates the correct 5-channel light.

One possibility is therefore that the Sunricher DT8 gear is not yet ready to respond when Tasmota performs its initial DT8 interrogation following simultaneous mains power-up.

If DT8 detection fails during that early window, Tasmota appears to instantiate the light as:

lt_st:1

and does not subsequently retry/rebuild it as:

lt_st:5

once the DALI gear becomes responsive.

This is only a hypothesis based on the observed logs, but the difference between the cold and software boot is very repeatable.


Question / possible fix

Would it be possible for the DALI initialization code to:

  • delay initial DT8 capability detection following a true power-on;
  • retry DT8 detection if the gear initially returns no response; or
  • when DaliChannels 5 is already stored, retry/reinitialize the 5-channel light after the DALI gear becomes responsive?

I can provide the complete WebLog 4 output from both the failing cold boot and successful Restart 1 boot if useful.