Closed jishi closed 8 years ago
Makes sense, but I am inclined to leave it to others to do this should the need or desire arise. I do not want to touch my own Pi, which is performing this job flawlessly in our house, and that would preclude me from doing real-world testing before committing the change.
Out of curiosity @jishi , would any of the renamed events or changes to the state
object affect the following? The code no longer bear much resemblance to stub from which it was forked; it does not subscribe to events at the player level. It simply uses discovery.on(...
to subscribe 'transport-state'
, 'group-volume'
, 'group-mute'
, 'volume'
, and 'mute'
and does the same thing for any of those events, iterating all players and acting on this condition:
var giveItJuice =
(player.coordinator.state.currentState == 'PLAYING') &&
player.state.volume &&
!player.state.mute &&
player.coordinator.groupState.volume &&
!player.coordinator.groupState.mute;
The event stub you based this on is fairly outdated, and the new sonos-discovery library has a lot of improvements over the old one.
There are a few incompatibilities, some of the events has been renamed and the state object has some small differences. It also does logging internally, and you can get the same logger by
const logger = require('sonos-discovery/lib/helpers/logger');
Which makes winston redundant.
The main improvements are improved discovery of Sonos system in problematic environments, and improved event subscriptions from the players.