Simplify update_zone logic #39
Conversation
Avoid duplicate checks and loops and follow a simple structure: 1. Update power state and skip all further updates if power is off, since those might not work anyway. 2. Update generic properties that should always be supported. 3. Update everything else that is supported by the respective zone, unless disabled via PARAM_DISABLE_AUTO_QUERY or PARAM_ENABLED_FUNCTIONS.
| elif ( | ||
| comm == "set_channel_levels" | ||
| and "channels" in self._params.get(PARAM_ENABLED_FUNCTIONS) | ||
| and bool(self.power.get(Zones.Z1)) |
There was a problem hiding this comment.
Note to self: this is probably a bug in the original code - it should probably check self.power.get(zone), rather than always check Zone 1 power irrespective of the zone being updated. Logged as #40
|
Thanks for the PR. It is definitely a lot cleaner. It seems ok, I have cherry-picked the PR and will soak it for a few days on my setup. |
| if ( | ||
| await self.send_command("query_power", zone, ignore_error=True) is None | ||
| or await self.send_command("query_volume", zone, ignore_error=True) is None | ||
| await self.send_command("query_volume", zone, ignore_error=True) is None |
There was a problem hiding this comment.
(Argh, I lost my previous comment.)
Because query_volume and query_mute are not executed if the AVR zone is off, volume[zone] and mute[zone] are unset. This impacts the HA media_player entity supported_features which does not advertise volume and/or mute.
For some reason, query_volume and query_mute are not executed on my AVR when the zone is turned on, this should update the attributes checked when calculating supported_features. I need to debug this further.
There was a problem hiding this comment.
So on my AVR (VSX-930, Zone 1 + HDZone) the scenario above occurs after the integration is started with all zones off, then HDZone is turned on before Zone 1. The initial full update is triggered only when Zone 1 is turned on for the first time because some commands don't work when only HDZone is turned on.
If volume and mute for each zone other than Zone 1 are not queried when the zone is off, the query_volume and query_mute will need to be queued the first time that zone is turned on, possibly after a delay.
There was a problem hiding this comment.
Tracking of initial update of individual zones has been implemented in 7c12d70 and I am testing this PR rebased onto latest dev.
Avoid duplicate checks and loops and follow a simple structure: