node-sonos-http-api
node-sonos-http-api copied to clipboard
jishi
Enhancement Request: Additional volume controls
To better control the kids use of their PLAY:1 I'd like
(1) to be able to set a max. volume. Similar to the existing lockvolume, but only clamping a maximum (2) as a bonus it'd great if I could set different values for different times of day - but maybe this is outside the scope of this api and if a max volume api existed it would be simple enough to call it with differetn values at different times of day. (3) I'd like to be able to ramp down the volume over a period time - this is kind of an extension to sleep, but with the volume ramping down over the sleep period to end at zero so that there isnn't a sudden cut off. (4) Maybe this should be a separate request ... I'd like a wake API to complement the sleep API. This could be used as a basic alarm clock. I'd also like to be able to set the volume (and, obviously :-) ramp up the volume over a period of time.
Recording these ideas here now so they don't get lost. I'll come back with proposed APIs and would then be happy to have a stab at an implementation, unless someone else gets there first.
+1
On 12/13/16 5:19 PM, Robert May wrote:
To better control the kids use of their PLAY:1 I'd like
(1) to be able to set a max. volume. Similar to the existing lockvolume, but only clamping a maximum (2) as a bonus it'd great if I could set different values for different times of day - but maybe this is outside the scope of this api and if a max volume api existed it would be simple enough to call it with differetn values at different times of day. (3) I'd like to be able to ramp down the volume over a period time - this is kind of an extension to sleep, but with the volume ramping down over the sleep period to end at zero so that there isnn't a sudden cut off. (4) Maybe this should be a separate request ... I'd like a wake API to complement the sleep API. This could be used as a basic alarm clock. I'd also like to be able to set the volume (and, obviously :-) ramp up the volume over a period of time.
Recording these ideas here now so they don't get lost. I'll come back with proposed APIs and would then be happy to have a stab at an implementation, unless someone else gets there first.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jishi/node-sonos-http-api/issues/409, or mute the thread https://github.com/notifications/unsubscribe-auth/AANxZVDUnVSfujFL92LsEWsK6IqVbDj8ks5rH0Q8gaJpZM4LMbQO.
(1) I've actually thought about the max volume feature. One big question was if that should be limited by config, or dynamically. You seem to be in favor of the dynamic approach, where you can lock it dynamically because you don't always want the lock.
(4) I'm using a cronjob for applying a preset today, but it is a bit tedious to handle when my schedule differs (on holidays, vacations etc). However, any such feature that needs state over a long period of time, would also need persistance of the state to survive a reboot or a crash. That makes it a bit more complex, this also makes upgrades and changes a lot more difficult.
Good ideas, but as you said, some of them feels like they belong as custom adaptations. All of these would be possible to do with the current actions, first one could be done via the webhook for instance. But it surely is a bit of work. 1 and 3 I can certainly see as part of the core functionality. I need to think about the other two a bit.
My use case is similar, I've got a rental situation where one of my zones is outside. I'd like to limit the volume setting based on a schedule (noise limits in the community differ on weekend and weekdays). An implementation with very short lag would be much better than one that does not.
OK, let me focus on (1) for now. I'm new to this codebase and the Sonos terminology in the last 24 hours, so apologies in advance if I'm asking stupid questions, pointing out known things or simply not making sense.
Firstly I'd like to thank @jishi for a clean and readable/understandable code base - makes life easier for everyone; also thank you for the great functionality. I have some other observations about the API, but will save them for another day.
If I understand the current lockvolumes action, then it simply locks the current volume of every player in the system, regardless of grouping. Personally I can't see the use case for that - I can only see use cases for locking individual players or all players in a group. Assuming that we keep the current functionality then I think we could consider the following api endpoints:
(a) /lockvolumes - current functionality, lock all players in system at current volume
(b) /unlockvoumes - current functionality, unlock all players, leaving them at current volume
(c) /{player}/lockvolume - new functionality, lock individual player at current volume
(d) /{player}/unlockvolume - new functionality, unlock individual player, leaving at current volume
(e) /{player}/GroupLockvolume - new functionality, lock each player in {player}'s group at current volume
(f) /{player}/GroupUnlockvolume - new functionality, unlock each player in {player}'s group, leaving at current volume
(g) /maxvolumes[/vv] - new functionality, clamp all players to a max volume of their current volume [or optionally to value vv]
(h) /maxvolumes/100 - remove max volume clamp for all players
(i) /{player}/maxvolume[/vv] - new functionality, clamp individual player to a max volume of current volume [or optionally to a value vv]
(j) ... etc.
Generalising we're applying a clamp between a min and max volume level for each player/group of players/all players; and extrapolating we might make a case for a similar set of ...ClampVolume/min-max apis, and for symmetry a set of ...minvolume/vv apis. But I don't, personally, see the need for all these. We have (a) and (b) today, and so should retain them. My need is only for (i).
As far as implementation goes I would propose to refactor the actions/lockvolumes.js to implement a clamping function that keeps volumes between a min and max for each player, then each of the endpoints above can be implemented as a wrapper that sets the min and max values for a player or players ...
the ...lock... APIs apply clampvolume(player, current_volume, current_volume);
the ...max... APIs apply clampvolume(player, 0, max_volume);
the ...unlock... APIs apply (effectively) clampvolume(player, 0, 100); - although I think we want to remove the volume event handler when there are no more restrictions to apply.
I need to give a lot more thought to what clamping volumes across a group of players really means - is this a clamp on the individual players or a clamp on the group volume or some combination of the two??
Not sure when I'll get to it, but I'll try to implement a straw man proposal for review. My JavaScript fu is not strong though.
Rob.
I concur that lockvolumes isn't really a very useful feature today. I implemented it more as an experiment, and the main idea was actually for a party setting to disallow people from adjusting the volume. But with some testing, I also realized that a max volume is much more useful, there is really no point in actually disallowing lowering the volume.
If anyone is of a different opinion, do share your experience.
Because of this, I don't see a reason for a minimum volume either, to be honest.
I'm curious though how many actually expecting a max volume to be sort of permanent? Like, having it like that for days or similar?
Makes no sense now that it's a native feature since 9.2?
On Thu, Oct 18, 2018, 16:03 honato11 [email protected] wrote:
Any chance to get the maxvolume feature implemented any time soon?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jishi/node-sonos-http-api/issues/409#issuecomment-431021351, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBNI6l_uTiZ1BHzlxdA_Sb2GZED2gtdks5umIpMgaJpZM4LMbQO .
The Sonos 9.2 setting can be easily changed by kids or guests and it would still be cool to dynamically set a max volume depending on the time and this can only be done when there is a nice (node-sonos-http-api) API call available to do this :)))
In other words: It would be perfect to have /lockvolumes implemented as /maxvolume to have always the last say concerning the max volume. In Sonos 9.2 -> Settings we could define the max volume and if it's changed to a value greater than the value set via node-sonos-http-api/maxvolume the volume is lowered automatically. Like this even if the Sonos 9.2 setting for a given player is changed it still cannot be ever set to a louder volume than defined by node-sonos-http-api. That would be perfect for my use case.
