search

jishi / node-sonos-http-api

An HTTP API bridge for Sonos easing automation. Hostable on any node.js capable device, like a raspberry pi or similar.
http://jishi.github.io/node-sonos-http-api/
MIT License
1.85k stars 460 forks source link

[feature request] Sonos Move - Battery Status #792

Open TimWuyts opened 3 years ago

TimWuyts commented 3 years ago

I would like to get the battery related information from a Sonos Move. At the moment I'm able to get this information using the following GET request (where the IP is the address of my Sonos Move speaker).

http://192.168.0.103:1400/support/review

The XML result contains the following data:

<LocalBatteryStatus>
            <Data name="Health">GREEN</Data>
            <Data name="Level">100</Data>
            <Data name="Temperature">NORMAL</Data>
            <Data name="PowerSource">SONOS_CHARGING_RING</Data>
</LocalBatteryStatus>

If you can point me into the right direction, I will be glad to help to make a PR.

jishi commented 3 years ago

Hi, the support/review endpoint is not a great approach for gathering information about the players. It is normally done the opposite direction, by subscribing to "events" from the players. Since I don't own a Move myself, I can't verify exactly how this information is evented, but I'm pretty sure it is.

If you want to investigate exactly how it is evented, one way would be to sniff the traffic with wireshark when running the desktop controller (if battery information shows in that controller? It has been crippled since some years back).

Another option is to run the Intel UPnP tools (https://www.meshcommander.com/upnptools) and the device spy application, which will find the Sonos players and figure out the evented data.

The event stuff belongs to the sonos-discovery module, and here you can see which endpoints it subscribes to:

https://github.com/jishi/node-sonos-discovery/blob/master/lib/models/Player.js#L203-L208

Then the players starts posting data back to the service, and I parse out whatever I find useful to know (playback status, track info, volume levels etc). It would be a matter of finding out what and where the XML of the battery info is located, and parse that.

TimWuyts commented 3 years ago

Thanks for the clarification. Listening to the events does sound better instead of polling a certain endpoint. The desktop controller is only giving a battery charge indication. The mobile app does the same & also indicates if the move is charging or not.

I've been sniffing the events (Notify events, with HTTP/XML protocol) coming from the Move, however it seems that there is nothing mentioned about the battery charge/power source in the available information. I've also compared the XML schema's from the Move with those of the One. But they seem to be identical.

It seems that I should stick with my current solution, by polling the /support/review endpoint.

jishi commented 3 years ago

Are you saying that you don't see charge level in either app? But it is part of /support/review?

You should check if that info is available under http://x.x.x.x:1400/status for the IP of the move, because the support/review is an aggregation of info fetched from all players which can be horrendiously slow. Going against the Move directly and only requesting the support info from that player would be much faster.

I have a friend who has a Move, maybe I can borrow that and see if something comes up.

TimWuyts commented 3 years ago

Both the app & desktop controller show the charge level & give an indication whether the Move is charging at the moment.

The following endpoint on the Move "/status/batterystatus" gives the same information (in an HTML table) as the "/support/review" endpoint (in XML).

So that would make a viable case in order to fetch this information on a specified interval.