The Bose Soundtouch API is a REST API that allows for programmatic local control of a stereo. A lot of the endpoints return a response with useful information. However, as far as I can tell, the current implementation of hass’s Restful command integration does not appear to provide any kind of access to the response from endpoints. Am I missing something?
So, for example, in configuration.yaml, I define:
restful_command:
bose_info:
url: http://STEREO_IP:8090/info
method: GET
bose_sources:
url: http://STEREO_IP:8090/sources
method: GET
bose_play_url:
url: http://192.168.1.176:8090/speaker
method: POST
payload: >-
<play_info>
<app_key>BOSE_APP_KEY</app_key>
<url>'{{ url }}'</url>
<volume>50</volume>
</play_info>
If I invoke one of the GET endpoints above from Developer Tools and if I set the logger level to debug for the integration, the only output I’ll get is :
2019-12-05 16:19:17 INFO (MainThread) [homeassistant.components.rest_command] Success call http://STEREO_IP:8090/info.
I would expect to see the response from the endpoint in home-assistant.log or at the bottom of the Services page.
I am stuck with similar problem but do not understand how this might solve it.
I need to access a hystory data of a sensor. For that I found I may usr REST command. But I do not understand where the result goes and how to access it? How would a sensor help me?
Exaple. I have a temperature sensor T. I need to understand when the temperature was decreasing, and when increasing in a time interval t. For that I have to call a REST command GET GET
/api/history/period/ to obtain the datapoints to work with. But how to access it after the REST command was called?
Just stumbled upon this myself — just to see if there was a simple workaround, but I’m doubting that there is.
It seems that if you wish to trigger a command, and consume the response, there is no quick solution.
A sensor does return the response, but is constantly polled at intervals rather than when required.
Ideally, an event should be triggered containing the response. As a hacky workaround, my plans for my current situation is to raise a custom event as part of script, act upon it in Node-RED and call a HTTP request there, and fire a response event that acted upon in the original script following a wait_for_trigger step.
You can set a very high scan_interval on a sensor and trigger an update “manually” as required. For my printer, I do this under the rest: section (with a daily default update, but you could go much higher):