WiiM Pro API standby mode

[Bouwstra]

Hello everyone,

I got the WiiM PRO and I was wondering if there's an API function that could tell you if the device is in Standby mode or not?
I looked at the getPlayerStatus function, which can give the status like "play", "stop" or "pause", however I found that even if the device is in standby mode it seems the API returns still the status as "pause", so I cannot use the status value to determine if the device is in standby mode or not. Does anyone know if there's a way to with the API to figure out if the device is in standby mode or not?

Thanks in advance!

 

[Kekshaus]

Hi,
any news here about this topic?
Regards
Kekshaus

 

[Brantome]

Probably best asking WiiM directly about this using the feedback section in the WiiM Home app

 

[onlyoneme]

I don't even know what this "standby mode" is exactly.

 

[Kekshaus]

Hello ,
ok maybe im wrong but in the app its possible to configure a standby mode of the device. I think default is 2 min. And on the device the power-led get dimmed when the device is in standby mode. It would be a nice if its possible to get this info in "command=getStatusEx" or "command=getPlayerStatus" as 0|1 value.
Regards
Kekshaus

 

[onlyoneme]

How would you use this information?

 

[Kekshaus]

For me i use a big amplifier which already consume much power in idle. So i modifier the device that is possible to poweron/poweroff the device over smartfunctions. So i want to poweroff the amplifier automatic when the wimmdevice is going to standbymode to reduce powerconsumption. And poweron when the wimmdevie is going back to active. But its only an idea. If its not possible i will add an own standby function to my java-api.
Regards
Kekshaus

 

[onlyoneme]

So I guess you would like to monitor being "idle" which not always is the same as being in the "standby mode" - for example if you switch to line-in input and pause, it will be idle but not in standby.
Monitoring "status" property of "getPlayerStatus" is helpful, but not enough in some cases like using Tidal Connect when "status" can be "none" regardless of the real state. UPnP interface is more predictable here.

 

[cc_rider]

For me i use a big amplifier which already consume much power in idle. So i modifier the device that is possible to poweron/poweroff the device over smartfunctions. So i want to poweroff the amplifier automatic when the wimmdevice is going to standbymode to reduce powerconsumption. And poweron when the wimmdevie is going back to active. But its only an idea. If its not possible i will add an own standby function to my java-api.
Regards
Kekshaus

Why not just use the WiiM Pro's 12V trigger for this?

 

[Kekshaus]

So I guess you would like to monitor being "idle" which not always is the same as being in the "standby mode" - for example if you switch to line-in input and pause, it will be idle but not in standby.
Monitoring "status" property of "getPlayerStatus" is helpful, but not enough in some cases like using Tidal Connect when "status" can be "none" regardless of the real state. UPnP interface is more predictable here.

ah ok i was not aware that there is a diffrence between idl and standby. ok thnaks for the info. I think then i will use my own standby implementation for this. Thanks for this information

Why not just use the WiiM Pro's 12V trigger for this?

When i understand this correctly i need additional hardware to get the trigger. I preffer in this case a software solution. But nevermind i already implement a own standbymode that is already working. It was just a question to make it cleaner for my api

 

[Bouwstra]

For me i use a big amplifier which already consume much power in idle. So i modifier the device that is possible to poweron/poweroff the device over smartfunctions. So i want to poweroff the amplifier automatic when the wimmdevice is going to standbymode to reduce powerconsumption. And poweron when the wimmdevie is going back to active. But its only an idea. If its not possible i will add an own standby function to my java-api.
Regards
Kekshaus

Hi, my use case was very similar to what you described here, but I did not get any further information after my initial post here. Eventually I just assumed there's no API that we could call that could give you the information whether the device was in standby or idle mode. In the end I ended up building my own implementation, which is just based on frequently calling the getPlayerStatus API. If it was "play", it would then power on the AMP, and if it would return "pause" or "stop" for a period of time, it would then power off the AMP. However, it required polling the WiiM Pro API more frequent than I would ideally want, but as of now I did not find a more elegant solution.

I did occasionally encounter a scenario where the response from the getPlayerStatus call seemed not accurate. I couldn't figure out for which situations exactly, but I think it was when using Chromecast (either with or without "speaker group") or perhaps it was with AirPlay. Also, if the input is non WiFi (e.g. aux in or optical in), then I believe the result from getPlayerStatus was not very useful (as far as I remember).

Unfortunately my audio equipment does not support the 12V Trigger, otherwise that would have solved the situation. It would be nice if WiiM could still add an API function that could return whether the device is idle/standby or if it's on (so basically more or less the same info as what the 12V trigger would provide through a cable).

 

[Kekshaus]

Hi, my use case was very similar to what you described here, but I did not get any further information after my initial post here. Eventually I just assumed there's no API that we could call that could give you the information whether the device was in standby or idle mode. In the end I ended up building my own implementation, which is just based on frequently calling the getPlayerStatus API. If it was "play", it would then power on the AMP, and if it would return "pause" or "stop" for a period of time, it would then power off the AMP. However, it required polling the WiiM Pro API more frequent than I would ideally want, but as of now I did not find a more elegant solution.

I did occasionally encounter a scenario where the response from the getPlayerStatus call seemed not accurate. I couldn't figure out for which situations exactly, but I think it was when using Chromecast (either with or without "speaker group") or perhaps it was with AirPlay. Also, if the input is non WiFi (e.g. aux in or optical in), then I believe the result from getPlayerStatus was not very useful (as far as I remember).

Unfortunately my audio equipment does not support the 12V Trigger, otherwise that would have solved the situation. It would be nice if WiiM could still add an API function that could return whether the device is idle/standby or if it's on (so basically more or less the same info as what the 12V trigger would provide through a cable).

In my standby inplementation is use also the pay/stop as indicator to mark that the devie is in standby or not. But for now i can life with this solution. But yesterday i had a silmar situation with the getPlayerStatus that returns an invalid json.
Example:
{"type":"0","ch":"0","mode":"5","loop":"0","eq":"0","vendor":"CAST","status":curpos":"0","offset_pts":"0","totlen":"251000","Title":"4D6F636B696E6762697264","Artist":"","Album":"456E636F7265","Vendor":"unknown","alarmflag":"0","plicount":"0","plicurr":"0","vol":"52","mute":"0"}
There is a value missing for status.

 

[onlyoneme]

"mode":"5" means Chromecast. As I said "getPlayerStatus" does not always return correct data. UPnP interface is a better choice.

 

[Bouwstra]

"mode":"5" means Chromecast. As I said "getPlayerStatus" does not always return correct data. UPnP interface is a better choice.

Is there any info or do you have any information on getting data from the UPnP interface? All I know is just the HTTP API spec (https://www.wiimhome.com/pdf/HTTP API for WiiM Mini.pdf) which is currently still the same for WiiM Mini and WiiM Pro.
Or... perhaps there's a bit more study I need to do about this UPnP topic first ;-)

 

[onlyoneme]

All depends on the libraries being used. UPnP API is the same in general.

Below is the example how to retrieve playback status using polling method:

https://wiim.community.forum/threads/incorrect-tidal-connect-playback-status-over-api.658/

 

[cc_rider]

Is there any info or do you have any information on getting data from the UPnP interface? All I know is just the HTTP API spec (https://www.wiimhome.com/pdf/HTTP API for WiiM Mini.pdf) which is currently still the same for WiiM Mini and WiiM Pro.
Or... perhaps there's a bit more study I need to do about this UPnP topic first ;-)

Get yourself a good UPnP tool, which will search your LAN using SSDP for all your devices, display their methods, and allow interacting with and subscribing to their services. They are available free in the iOS and Android App Store, probably Windoze too.

There are plenty of UPnP libs on GitHub for Python and Node.js, probably other languages. There are Sonos libs in both languages, good examples, though not exactly the same as WiiM’s interface.

For an example of doing it raw, without a lib, see one of my Chrome extensions.

GitHub - retired-guy/WiiM-Watcher-Chrome-Extension: Chrome Extension for WiiM

Chrome Extension for WiiM. Contribute to retired-guy/WiiM-Watcher-Chrome-Extension development by creating an account on GitHub.

github.com

UPnP Tool (Android):

 

[Bouwstra]

Thanks everyone for the replies and thanks a lot to cc_rider for the detailed instructions regarding UPnP.
I managed to get the UPnP Tool to work and it's pretty interesting. Before I always thought UPnP was for just automated setup of certain hardware only, but I've learnt something new now

I've explored all the functions that the WiiM UPnP interface provides. For my use case I could consider switching to the UPnP interface instead of the HTTP API, however, the only advantage it may provide me at this moment is that the "play/stop/pause" status could be more accurate from the UPnP interface (although it "seems" like the actual playback status through the HTTP API has become more accurate recently, maybe since recent WiiM Pro firmware update).

What I ideally was hoping for when I started this thread is that there would be an API function that could just respond whether the device is in Standby/Idle mode or not. So basically pretty much the same as what the 12V trigger could provide, or like the LED light on the actual device: when it's standby/idle the LED light is dimmed, and when it's active then the LED light is bright. It seems that currently neither the UPnP interface nor the HTTP API could provide this status.

My use case is that I want to power off my AMP/Speakers when the WiiM pro is not in use. Let's say if you set the auto-standby time to 2 minutes, then when music is stopped or paused for 2 minutes, the WiiM Pro will automatically go into standby mode (the LED is dimmed, and the device is supposed to consume less power in standby mode). However, when you call the API to get the playback status, it would still return "paused", even the device already went into standby mode. I assume that if you had the 12V trigger, it would have actually switched off your amplifier) Now, with my script that keeps polling the playback status to "try" to determine whether the WiiM is on or off, I need to have "logic" inside my script to determine that if it's "paused" for a certain period of time, it should just assume that the WiiM is off. If you would set a longer auto-standby time (e.g. 20 minutes), it would be much trickier, because in some cases maybe you actually "pause" the music for a while, and then resume again.

Long story short: if the WiiM device could just expose the Standby/Active status through an API, then there's no need for an external app or script to have this logic to "try" to determine whether the WiiM is On or Off since you would just be able to get this information directly from the API of the device.

 

[cc_rider]

I've explored all the functions that the WiiM UPnP interface provides. For my use case I could consider switching to the UPnP interface instead of the HTTP API, however, the only advantage it may provide me at this moment is that the "play/stop/pause" status could be more accurate from the UPnP interface

You can subscribe to the WiiM's UPnP services, vs polling. You can also determine which services the WiiM is subscribed to, even get some login info for the services, get the WiiM to search any of the services for your app. I use it to build full size UIs for Tidal, Qobuz and Deezer in a browser or text UI, for example. There's MUCH more you can do with the UPnP interface vs the https.