No, there an unsolicited message from the zone which initiated the party mode,
The format is #Z(zone number)Party(1: meaning on) [#ZzPARTY1]
But there is no message on how many other zones were affected. For me, party means all zones on with the same source and preset volume level.
As long as there's some indication, that should be enough I guess. So, once we see one of those, we'd have to do a re-poll of all zone status I guess. Can more than one zone be in party mode separately?
I do not think so, so only one party at any point in time.
There is another feature called "dynamic group" of which there are multiple possible, but I make no use of these, it seems to me that it takes more button presses to add/remove from a dynamic group and you have to do it from each zone separately, where in party mode all automatically turn on and set to the same source from one point.
04-07-2016, 07:29 PM (This post was last modified: 04-08-2016, 07:18 AM by lleo.)
Dean, I not a programmer, but after looking at the code I thought I will give it a try to add the desired functions.
I added the SyncDateTime to the InvokeCmd list to synchronize date/time and added the handling of #ALLOFF initiated from the device itself. The ALLOFF was available as custom InvokeCmd, but was not handled when issued from a keypad device.
Lastly added the handling of PARTYx mode and triggering a full status update to keep sync.
This works for me as excepted with some caveats. In Party mode, the Party host (zone which started the party) impacts all zones without a status update, in other words changing the volume on the party host does change the volume for all zones, and not just syncing but incrementally, for example if Z1(party host) volume is changed to from 30 to 50, but Z2 was at 20, would be come 40. This results in volumes/sources to get out of sync in party mode between CQC and MZAudio.
The Audio class definition has some considerations for multi zone audio and synchronized mode (i.e. party mode) but not much is specified.
In any case some more fields would be needed to capture Party Mode and Party Host and maintain sync between device and CQC.
You can find my additions in the attached driver macro. I am sorry for any gross misuse of code or practices as I just copied things around.
If you create a driver pack, other folks can import it easily and try it.
I doubt we'd expand the audio device class to deal with party mode, since it's much more general than multi-zone audio systems. So any actual exposure of it would have to be via non-V2 fields.
