Hi @lolodomo. As I and others have said before, thank you greatly for your support of this plugin.
I am experiencing a strange behaviour related to grouped players in version 1.0 (and in fact in prior versions as well). I am not certain if it is intentional. When a player gets added to a group (via a Sonos interface or the UI5 interface), the added player (Device B) automatically switches to “Play” in the UI5 interface although the player is not necessarily actually playing. If the group starts playing, that Device B remains in a Play state in the interface; if playback is stopped, then Device A (the original player to which Device B is grouped) shows the actual Stopped state in the UI, whereas Device B continues to show a Play state. In other words, once added to a Group, the Device B always and only shows a Play state.
I am working to create a representation of the Play state using PLEG based scenes that light certain buttons on a keypad. Although the functionality is working perfectly when the players are separate, the above causes the same misrepresentation from the UI to reflect in the keypad buttons when players are grouped.
Yes, the plugin just reflects the state provided by Sonos.
I think Sonos is assuming a Sonos device is playing as soon as it is linked to a master device.
You have to check the state of the coordinator of your group.
In any Sonos interface, the actual play state is reflected. However, in ghe Sonos interface, the group is shown as a s ingle entity, as opposed to individual players.
The Sonos application shows the state of the group itself, that is its coordinator, not the state of each slave members.
In the Vera, you have one device per unit, even when the unit is slave member of a group.
That being explained, of course it would be possible to change how the plugin works to reflect the state of the group for each member but that is not an easy change.
If Sonos is passing an incorrect play state of the grouped player to the plugin, then the change needed to correct this may not be worth the effort. For the moment, I have established a work-around for my requirement and I will continue to watch for developments with the plugin itself. Thanks for the help.
There is no bad value provided by Sonos, you have not understood my explanation.
To say that differently, you have access to the slave zone in the Vera while the Sonos application only give you access to the group itself and in fact its coordinator.
There’s a good chance that I do not understand the inner workings so well, but it does seem clear that an incorrect value for the play status is being transmitted. As soon as the grouping is made, the player status changes to Play, even though there is nothing being played. You are correct that the group coordinator’s status remains correct and representative of the group, but there is an opportunity for automation that is lost due to the grouped players’ misrepresentation.
As I am satisfied to ensure that groupings are always done in the same order and to rely on the designated coordinator’s status, I can achieve 90% of what I wanted. However, I cannot control the players independently, including assigning groups, through automation. Realistically, this likely represents a small loss.
[quote=“lolodomo, post:4, topic:182032”]That being explained, of course it would be possible to change how the plugin works to reflect the state of the group for each member but that is not an easy change.[/quote]Are you planning to this change in a near future? Or do you recommend us to look for a workaround?
Thank you, so I will look for a workaround meanwhile, maybe evaluating differently if the sonosid is different than the group coordinator ignore the state? talking about scenes and PLEG evaluation. Just an idea to share.
Just for sharing, I think I found a workaround for what I was lookinf for and maybe others to, it is used in a PLEG condition:
((sonos_kitchen_state ne "PLAYING") OR (sonos_kitchen_gc ne "RINCON_B8E93756669C01400")) AND ((sonos_studio_state ne "PLAYING") OR (sonos_studio_gc ne "RINCON_B8E937555F2801400")) AND ((sonos_bath_state ne "PLAYING") OR (sonos_bath_gc ne "RINCON_000E58AFDA4401400")) AND ((sonos_master_state ne "PLAYING") OR (sonos_master_gc ne "RINCON_B8E93755549001400")) AND ((sonos_living_state ne "PLAYING") OR (sonos_living_gc ne "RINCON_B8E9375666AA01400"))
Where:
sonos_xxxx_state is the variable TransportState for each of my devices
sonos_xxxx_gc is the variable GroupCoordinator for each of my devices
This way, a device is considered as not playing when its TransportState variable is not equal to “PLAYING”, but if it is grouped and it says it is PLAYING, then it checks if the GroupCoordinator is not himself, because if it is not himself, it will then ignore the state and one of the devices has to be the controller so it is going to be taken in account. Hope I am clear enought and it helps someone.
It can be done also in a Scene just getting the variables first and using if elseif
Vreo, thanks for sharing your effort with the PLEG. In my case, unfortunately, it does not solve the issue I was looking to address. I had hoped to be able to identify the play state of two zones, to operate the zones independently through automation, and to enable grouping through automation. As the actual play state of each player cannot be accurately discerned once grouped, this is not possible. In the end, for my application, I am finding that it does not make any practical difference. I simply rely on the play state of the controller and leave the two players always grouped (which is likely what would have occurred anyhow).
Ds514, not with my exact example, but using this variables, it is posible to achieve what you want. For example, if you want to see if a speaker is grouped or independent, you have to compare the GroupCoordinator variable with the SonosID one. If they are equal, it is or an indpendent player, or a zone coordinator, if they are different, it is grouped so the state that you need to know is the one of the GroupCoordinator id. This way you can detect each zone or independent player and know its exact state.
Yes, but - as the Vera can never know the true status of the grouped player, and although we can identify the player as grouped or not - accurate status of the grouped player seems beyond even PLEG. We can know that the states of the two players in my example are different, but that does not necessarily mean that such state is accurate or not.
Anyhow, this seems like the classic automator’s struggle (in my case at least); the logic is more important than the practical function. I have lived happily with my inadequate logic all summer (these are outdoor zones) and have never felt lacking.
I defer, you can compare de GroupCoordinator with the SonosID.
e.g. if I have players 1,2,3,4.
sonos id same as groupcoordinator, then the state of this one is real
2 and 4 are grouped. if sonos id is different than groupcoordinator, then compare group coordinator with other, 1 for example, it is not the same, so compare with 3, it is not the same, compare with 4, it is the same, so take 4 status as real.
Yes, this would work for more than 2 players in the group. However, for only two players, it seems to me that the status of the grouped player could never be known.
The status of a group is simply defined by the status of its coordinator. And it does not depend on the number of zones inside the group.
The group coordinator is simply the zone that has Group coordinator == zone UUID
The discussion regarding the number of players is regarding a PLEG based logic that Vreo is suggesting as a method for determining the correct status of the grouped player.
Best Home Automation shopping experience. Shop at Ezlo!