Warm-up and cool-down delays in media players

[AThomsen]

Adds support for an additional delay when turning media players on/off.

I have some devices that cannot receive IR commands until some seconds after turning on. Same goes for turning off: it's not possible to send "turn-on" commands immediately after turning off.

Because of that it's impossible to make a script in HA that (1) turn on, (2) set source, (3) start playing, without adding explicit delays to the script.

Example definition:

{
    "manufacturer":"Cambridge Audio",
    "supportedModels":[
        "551R"
    ],
    "warmUpDelay": 7,
    "coolDownDelay": 4,
    "supportedController":"ESPHome",
...

In this example, after being turned on from an off state, subsequent commands will be delayed by 7 seconds. Turning off will block subsequent commands for 4 seconds.

Implementation details

A simple way to implement this would be to simply do an additional delay after turn on/off commands. However, this create some unnecessary blocks. Instead, after the on/off call, it simply calculates at what time new commands can be processed. Then, any waiting is done in the preceding calls.

[litinoveweedle]

Hello,
while I understand your use case, this seems to be too specific to me, to be included in the main. First, you can use existing delay parameter to achieve same effect, or as you describe you can put delay in the script. I am trying to keep main branch streamlined and this seems to be kind of edge case to me.

[AThomsen]

Hi :-)
It is to support devices that takes a while to initialize after turning on before it can receive additional IR commands. Looking around in my own house I believe this applies to at least my receiver, projector and TV.

As I understand the delay feature, it would in my case each IR command be delayed. So if delay=7sec and I do "turn on, switch source, turn up volume x3" it adds up to 5x7second if waiting.

[litinoveweedle]

Hello, I understand the usage. The topic is, that SmartIR is just simulating your remote. So in comparison there is also nothing preventing you from pushing on and off on your remote immediately. Simply you aren't supposed to do it. And if you do it then nothing will happen. And your remote control device is also not having some delay mechanism built-in to prevent sending an IR command immediately if you press the given button. So it is the same with the SmartIR. If your device doesn't like you to send on/off command in succession than please do not do it. If you are using a script then put delay in it. This is just the pure analogy of your IR remote device, only hooked to the Home Assistant. I really think that this proposed feature is something too specific to be maintained in this integration.

[litinoveweedle]

I took the time to think about your proposal. I might implement it, but is shall be:

• implementation for all 3 SmartIR device classes.
• generic implementation for any delay, including the default delay between commands.
• the delay_on and delay_off if not implemented shall be set to the default delay value.

Your original proposed implementation waits only in the case of the next command. This is nice, as HA is updated immediately and not only after delay. On the other hand, user than could think, that device is ready to immediately accept next commands and could be confused why it doesn't do anything and as there is mutex it will not even queue commands and will pass on them. I can guarantee you, that there will be plenty of the issues raised because of this behavior. It is stupid, but more robust to simply not even update HA until delay is pass.

[AThomsen]

I managed to implement what I needed in ESPHome instead for now.

Feel free to close/reject this PR as you wish 😊