Is there a way to call an action on a fan using the local API and a GET request rather than a PUT?
Here is my use case:
I’ve installed a smart relay on our bedroom wall switch. (A Shelly1: https://shelly.cloud/shelly1-open-source/) One of the nifty features available is “long press” and “short press” “actions” (web requests) for flipping the switch back and forth. I thought it would be very nifty to use this to control the light on my fan with the local API. But, unfortunately, the only “action” is to hit a url with a GET request. I can’t specify a body, header, or HTTP method. I can still use it to turn on the light via IFTTT, but getting the cloud involved makes it annoyingly slow. I’d love to do it all locally and without needing other home-automation software involved.
I love the Bond and we use it with Alexa all the time, but I miss the instant feed back of a simple toggle switch.
Unfortunately there’s currently no way to execute an action with a GET request, this is the first I’m hearing of a use case for it.
I’ll have to discuss with the team what potential downsides making GET device/x/actions/y execute action y could have. If there’s any client out there that’s (unnecessarily) GETting those endpoints as part of a sync, this’d be a breaking change.
That’s the answer I expected, but it’s good to know for sure. It would be a nice feature for me to have, but I understand your feature request list is always quite long.
I also put in a question on the Shelly forums to check how I might make the request differently from that end.
One way I worked around weird limitations of my devices (with my Kasa smart bulbs, not Bond / ceiling fans) was to run a basic REST service on a Raspberry Pi.
I call into the Pi with various URLs / paths for different bulbs and commands, and then it calls out using the (unofficial local) commands to manipulate the Kasa bulbs.
Indeed GET BOND.local/v2/devices/x/actions/y would not be possible, as it would break an important paradigm of our API. However there’s no reason in principle that we couldn’t map GET BOND.local/v2_put/xxx into PUT BOND.local/v2/xxx. If we further permitted the argument to be passed in the URL query string, this could open up the API to a wider range of less sophisticated HTTP clients.
Same for me, for a number of years. I broke down earlier this year because there just aren’t enough flexible options for local API control across vendors / product types.
After I gave in and set up a Pi to shoehorn / brute force some additional solutions together, it’s made a pretty positive difference to me.
Even though I still grumble about it being necessary.
