[daikin] Update channels immediately after a successful API command

[jimtng]

This was requested in #16479 (comment)

In summary, when sending an API call to change something, the device will return a ret=OK if it accepted the values that we've set. Therefore, we should know the updated value already, without having to wait for the next poll. We therefore update the relevant channel immediately.

This helps for when changing something requires immediate feedback, such as increasing/decreasing the set temperature. Previously, the only way to get a smooth user experience is by relying on autoupdate.

[jimtng]

@Jogobo - FYI

[jimtng]

@psmedley if you're still using Daikin binding, WDYT?

[psmedley]

LGTM - I would hope this might fix issues where if you send two commands in short succession - the second command can end up reverting the 1st command - presumably as the autorefresh sometimes hasn't completed.

[jimtng]

I would hope this might fix issues where if you send two commands in short succession - the second command can end up reverting the 1st command - presumably as the autorefresh sometimes hasn't completed.

Could you elaborate / give an example please?

[Jogobo]

As, in most cases, you cannot set a single value via HTTP set command I guess it depends on the parameter combinations chosen in the binding.
Let's say i.e. you cannot set fan speed without setting the temperature too, but you can set the temperature without setting the fan speed. Actual desired temperature is 20°C.

First you set the new desired temperature with your temp item to 21°C which results in set_control_info?stemp=21 being sent by the binding. As long as the next poll did not happen the binding channel is still at 20°C.
Now you change the fan speed with your fan item. As the temperature has to be sent together with the new fan speed the binding sends set_control_info?stemp=20&f_rate=4, thus overwriting the previously sent 21°C.

[jimtng]

Let's say i.e. you cannot set fan speed without setting the temperature too, but you can set the temperature without setting the fan speed. Actual desired temperature is 20°C.

First you set the new desired temperature with your temp item to 21°C which results in set_control_info?stemp=21 being sent by the binding. As long as the next poll did not happen the binding channel is still at 20°C. Now you change the fan speed with your fan item. As the temperature has to be sent together with the new fan speed the binding sends set_control_info?stemp=20&f_rate=4, thus overwriting the previously sent 21°C.

No, I believe this is what happens instead:

• Setting temp to 21C -> get_control_info -> set_control_info?stemp=21 + other values from get_control_info
• Setting fan speed to 4 -> get_control_info -> (the stemp should be 21 already here) change the f_rate=4 -> send it back via set_control_info - even though the settemp channel may still be 20 if a poll hasn't occurred yet.

For each action for the channel, it first gets the current info so nothing is "stale" / old.

And that's all already done prior to this PR.

[psmedley]

My example is similar to @Jogobo

I have a rule setup so that if the set point or inside temp change, and the delta between them is >= 2C - then increase the fan speed.

I have other rules to set the setpoint to 16C overnight - but up to 23C during the day. When the setpoint goes from 16C to 23C is also triggers the fan speed rule - and on a decent number of occasions, the setpoint ends up reverting to the 'old' setpoint of 16C.

This was with the code in 4.2.0

[jimtng]

I have a rule setup so that if the set point or inside temp change, and the delta between them is >= 2C - then increase the fan speed.

I have other rules to set the setpoint to 16C overnight - but up to 23C during the day. When the setpoint goes from 16C to 23C is also triggers the fan speed rule - and on a decent number of occasions, the setpoint ends up reverting to the 'old' setpoint of 16C.

This was with the code in 4.2.0

I can't immediately imagine how this could have happened. Could you make this problem appear consistently, perhaps by lowering the polling refresh rate to say 10 minutes and triggering the sequence of events manually?

[lsiepel]

Thanks, just one comment.

[lsiepel]

Thanks,LGTM.

Will merge when the potential issue @Jogobo and @psmedley mention is resolved.

[jimtng]

ping @Jogobo @psmedley

[psmedley]

Apologies, I've been busy. I just did some experimentation with trying to reproduce - I can't - even with refresh set to 600 seconds.

[Jogobo]

Did not come across the problems @psmedley had. So from my side there is no reason to prevent the changes from being merged.