USER_BACKLOG - only the first command is executed

[thermseekr]

Hello all,

Edit: I'm compiling 14.2.0 env:tasmota32 in Platformio.

I'm trying to run a few comands in USER_BACKLOG after setting a custom template and selecting module 0, but only the first command is being executed. Here is the relevant part of user_config_override.h:

#define USER_TEMPLATE   "{\"NAME\":\"ESP-24V-16CH-V2\",\"GPIO\":[0,3200,0,3232,0,0,0,0,5536,10240,10241,0,0,0,5600,0,0,0,0,5568,0,0,0,0,0,0,0,0,608,640,0,0,0,0,0,0],\"FLAG\":0,\"BASE\":1}"

#undef MODULE
#define MODULE USER_MODULE

#define USER_BACKLOG "ethipaddress 10.112.66.22; ethsubnetmask 255.255.255.0; ethgateway 10.112.66.254; wifi 0"

If I change the order of the commands, say make "wifi 0" the first one, again only this one is executed. And if I try the same commands in backlog on a terminal, it executes them all correctly:

00:11:42.279 CMD: backlog ethipaddress 10.112.66.22; ethsubnetmask 255.255.255.0; ethgateway 10.112.66.254; wifi 0
00:11:42.324 RSL: RESULT = {"EthIPAddress":"10.112.66.22"}
00:11:42.574 RSL: RESULT = {"EthSubnetmask":"255.255.255.0"}
00:11:42.824 RSL: RESULT = {"EthGateway":"10.112.66.254"}
00:11:43.072 RSL: RESULT = {"Wifi":"OFF","Mode":""}

What am I doing wrong, can someone see it?

Thanks.
Tales Maschio

[thermseekr]

Hi, any ideas?

[Th0maz]

Just guessing...
Try without the spaces between commands

[thermseekr]

Tried that, thanks anyway 👍🏻

[tsmoneta]

The documentation says it's only executed on the first boot after a reset (no variables defined in flash). If you've already changed a configuration setting, that's not the case. Perhaps a rule with 'on system#boot' would be more appropriate to your use case.

[thermseekr]

Ah! I missed that it's only executed on first run. Maybe I got confused by the fact that the first instruction in the backlog is always executed. Or at least it looks like. Will need to check again.

Thanks for the help.

Tales

[clscrzyc]

hey,bro,I have also encountered the same problem. Have you solved it? Do you have any good solutions? Is this a bug in Tasmota?

[sfromis]

The solution was already in the marked answer. There was no issue at all. Maybe what you ask about is just not "the same".

Beware that commands in that one-time initial boot will fail if they try to config a feature not yet enabled by pin config or other commands. Restart is often needed before such take effect, and thereby out of scope for USER_BACKLOG

[Stonedfield]

I have reproduced a similar problem and found a possible cause in CommandsReady() in tasmota/support_tasmota.ino. I cannot confirm that it explains the original report, but the following change consistently fixes my case.

Setup

• WT32-ETH01 (ESP32), custom build of Tasmota 15.6.0
• USE_UFILESYS enabled
• #define MODULE USER_MODULE
• USER_RULE1, USER_RULE2, and USER_RULE3 defined at compile time
• A longer USER_BACKLOG, ending with:

...;Rule1 4;Rule1 1;Rule2 4;Rule2 1;Rule3 5;Rule3 1

Problem

After Reset 4, all three rule texts are present, but the activation settings at the end of USER_BACKLOG are not consistently applied or persisted. Running those commands manually afterwards works.

In tasmota/tasmota_support/support_tasmota.ino, version 15.6.0 contains:

bool CommandsReady(void) {
  bool ready = BACKLOG_EMPTY;
#ifdef USE_UFILESYS
  ready |= UfsExecuteCommandFileReady();
#endif
  return ready;
}

UfsExecuteCommandFileReady() returns true when no command file is running. Consequently, the OR operation makes CommandsReady() return true even if the backlog is still non-empty.

The reset/restart handling uses this function to decide whether it can proceed. This appears to allow saving/restarting before USER_BACKLOG has finished.

Change tested

I changed only:

ready |= UfsExecuteCommandFileReady();

to:

ready &= UfsExecuteCommandFileReady();

This requires both the backlog and command-file execution to be finished.

Test results

With the same configuration and USER_BACKLOG:

1. Original |=: incomplete rule activation after repeated Reset 4.
2. Changed to &=: three consecutive resets produced the correct settings.
3. Reverted to |=:
   • First reset: Rule3 was OFF, Once ON.
   • Second reset: Rule3 was OFF, Once OFF.
4. Changed back to &=: correct settings again.

Expected Rule3 settings are ON / Once ON. The different failure states suggest a timing-dependent issue rather than a fixed backlog length limit. These logs alone do not distinguish between commands not being executed and their changes not being saved before restart.

Could a maintainer check whether the OR operation in CommandsReady() should be AND? It fixes this reproducible reset issue on my device, although I have not tested all other callers or command-file execution scenarios.

[sfromis]

Not clear what the relationhip is to doing the Reset 4, but in general expect a Backlog command sequence to be cut short if you have executed a command causing a restart (which the Reset 4 command will, but many others too). Basically, after having triggered a restart, this will be time-controlled, and not wait for completion of all the remaining other commands. You may be able to improve things by using NoDelay or lowering the inter-command delay SetOption34 from the default of 200 ms.

[Stonedfield]

Thanks for looking into this. Perhaps I should explain my workflow more clearly.

I build device-specific firmware with the complete configuration embedded in user_config_override.h: template, module, rules and initialization commands. I do not configure each device manually after flashing. My requirement is that a factory reset restores a fully configured, operational device without additional console commands. This is especially important for devices at a remote location.

I issue Reset 4 as a standalone console command. It is not part of my backlog. During the reset, Tasmota restores the compiled defaults and queues USER_BACKLOG.

In SettingsDefaultSet3(), this already uses Backlog0:

String user_backlog = F("Backlog0 ");
user_backlog += USER_BACKLOG;
ExecuteCommand((char*)user_backlog.c_str(), SRC_RESTART);

Therefore, reducing the normal backlog delay does not appear to address the underlying issue.

The restart handling is explicitly guarded by:

if (TasmotaGlobal.restart_flag && CommandsReady()) {

After restoring the defaults, it sets:

TasmotaGlobal.restart_flag = 3;  // Finish backlog then Restart 1

This suggests that the pending initialization commands are intended to finish before saving and restarting.

However, CommandsReady() contains:

bool ready = BACKLOG_EMPTY;
#ifdef USE_UFILESYS
  ready |= UfsExecuteCommandFileReady();
#endif

When no command file is running, UfsExecuteCommandFileReady() returns true. The OR therefore allows the restart handling to proceed even with a non-empty backlog.

I changed only |= to &=, leaving my configuration unchanged:

• With &=: three consecutive resets restored the expected settings.
• Reverting to |=: two consecutive resets failed, leaving different incomplete Rule3 settings.
• Restoring &=: initialization worked correctly again.

The rule texts are present in all cases. It is the activation commands at the end of USER_BACKLOG whose effects are missing after the failed resets. Executing those commands manually afterwards works, but defeats the purpose of having a complete configuration embedded in the firmware.

Could you clarify why OR is used here, rather than AND? I understand that some hardware configuration changes require a restart before dependent commands can work, but that seems separate from whether the reset procedure waits for its own initialization backlog to finish.

[sfromis]

Since you are using USER_BACKLOG, my suggestions did very deliberately not include Backlog0 (it is already in a Backlog sequence, but instead tweaking SetOption34or using multipleNoDelay. If your Backlog` sequence at all includes commands triggering a restart, you cannot rely on this for config without special care.

Also, many of the commands triggering a restart can be replaced by specific #define symbols as a better way of doing it, But you did not detail what command sequence you are hoping to use.