Is there a way via MQTT to specify a time to turn on?

[jschwalbe]

Here is my scenario.. a ton of can lights with Tasmota. Poor Wi-Fi penetration thru the metal boxes. I send a MQTT topic command to turn on, and… popcorn! Instead of a smooth “all on”, some respond right away while others take their time (typically within 1 sec, but noticeable).

I would like my Node Red/MQTT command to include a time, like “turn on light at 12:45:00:42” such that it is maybe 500 ms after button press. Then some switches would sit on the command for 250 ms, and some might only wait 10 ms.

is this possible?

[sfromis]

No, there is no feature for delaying a command till some specified later time. Timer control in Tasmota is more based on configuring a timer schedule, possibly combined with rules, or using ruletimers to do something after a precalculated period. If you are not using timers for anything else, you could send a command to create a timer, at a whole-minute time.

Possibly, using device groups, or a group topic can help timing control, but if your wifi is too bad to work properly, that's what I'd focus on.

In case of using ESP32 devices, there is some additional flexibility with Berry for timing control.

[jschwalbe]

Thank you; I am currently using a group topic as you offered.
These are esp32s, so I’d be interested in what you have to say about using berry.

[jschwalbe]

Also this can be a question for google, but since you know more I’ll leave it here as well: does Bluetooth travel better thru metal than wifi signals? Would it make sense to have a Bluetooth relay of sorts? (even possible?)

[sfromis]

As both Bluetooth and Wifi (with Tasmota) are on the 2.4 GHz band, I'd generally expect similar range, and metal is horrible for radio waves. They will be blocked/reflected, but a lot of the time, the complex paths for radio propagation may also have a path around the wall, but maybe with weaker signal.

What I mean with Berry is that you can create a command, and then implement that command to do a calculation for when a timer is to pop, for taking whatever action you want.

Note that different Tasmota devices may not always be perfectly in sync with accurate time. While Tasmota will try to compensate for drift, having horrible wifi might result in trouble accessing NTP servers too.

[pkkrusty]

What if we added

  if (XdrvMailbox.payload == -1) {
    TasmotaGlobal.backlog_timer = millis()+(1000-RtcMillis());
  }

to CmndDelay function in support_command.ino (line 654)

That way if some sends a command like backlog power2 1; delay -1; power1 1 it won't execute power1 1 until the next second tick. Currently delay -1 is ignored.

Assuming all the tasmota devices OP is using can sync every 45 minutes, they should be within a few ms of each other if they're using the same NTP source.

*edit

Did some testing, and this works, more or less. power on/off happens within 25ms of a second tick. Might be nice as a setoption for folks that use group topics like you do.

@barbudor thoughts on this?

[jschwalbe]

That sounds like it would get the job done! (Assuming the code functions :))

[arendst]

I'll add command Delay -1 which will wait until next second before executing next command.

void CmndDelay(void) {
  // Delay -1  - Wait until next second
  // Delay 1   - Wait default time (200ms)
  // Delay 2   - Wait 2 x 100ms
  // Delay 10  - Wait 10 x 100ms
  if (XdrvMailbox.payload == -1) {
    TasmotaGlobal.backlog_timer = millis() + (1000 - RtcMillis());  // Next second (#18984)
  }
  else if ((XdrvMailbox.payload >= (MIN_BACKLOG_DELAY / 100)) && (XdrvMailbox.payload <= 3600)) {
    TasmotaGlobal.backlog_timer = millis() + (100 * XdrvMailbox.payload);
  }
  uint32_t bl_delay = 0;
  long bl_delta = TimePassedSince(TasmotaGlobal.backlog_timer);
  if (bl_delta < 0) { bl_delay = (bl_delta *-1) / 100; }
  ResponseCmndNumber(bl_delay);
}