[FR] delay before MQTT message publish

[cociweb]

Hello, I've already use your great addon for months. I additionally put multiple devices into group wtth daenny/climate_group hacs addon. There is nothing special in that library: it's a very usable to combine multiple tasmota-irhvac devices into one, to set the temperature/mode/etc with only one card/automation. BUT! since the climate devices are the same type, they have the similar inertia delay, so they behave with the same internal timing during turn on/mode changes. It means that to turn them on, they will draw the same amount of the initial high current peaks, - which is very dangerous:bangbang:

Let me propose a new parameter into the yaml config: Delay [ms] with the default value of 0, which creates a device dependent static delay before the mqtt publish. So in case of multiple devices there will be a possibility to have different delays when a grouping is in use, so they won't influent the infrastructure on a high level: :fire::zap::warning:

[hristo-atanasov]

I do really think this is an issue for "the combining software". Like in home assistant automation you can turn on/off multiple AC with delay between each device, that is in the list of devices to be turned on/off. If I put such parameter "delay" I don't loose anything, but this means even if you decide to turn on/off your device (one of many in the group) you will still need to wait that time, even if you turn on just a single device. There is still a way to be implemented though.

[cociweb]

Yes, you are right: from automation pov the solution is evident. But from gui (from cards) it is required to group them to avoid to repeat the action X-times. So, I think, a few additional (eg. in case of 4 device: 0-1-2-3 or half/one-third of them) sec is reasonable, and not mission critical in my case, and by other users it is not a usecase since the default value is 0. :) - so I think, I can leave with this permanent constrain. Let me draw your attention, that if you use different manufacturer/different model, then I'm pretty sure their internal startup/command process timing is different, and there is a low chance to their timing will be identical, so this issue will almost never pop up. I've tried to find some solution from tasmota pov, but I had no luck (or it requires unreasonable effort and it 'forgets' by an update. The modification can also be done from the grouping repo pov, and we won't get permanent delay, but the interim delay won't be unique (won't be able to optimise) by each machines.

[nao-pon]

Closes with #105