Feature description
You can make an API call in scenes, but only to trigger actions on remote services.
It would be super powerful to be able to make an API call and use the response as a variable.
Concrete example:
at 6 a.m., trigger a call to the weather API
send me a message with the day’s forecast
Or if I leave home, warn me if it’s going to rain during the day.
I imagine the possibility of retrieving a returned JSON value, either as in JavaScript {{ reponseapi.data.meteo.pluie }} or in graphical form as already done with existing devices.
I think we’ll do it in a graphical form. We’ll need to make a « test » call when creating the map. Then read the json response and make a list of all available keys, and populate them in the list of available variables
Good question, I haven’t handled that case, currently it will do a bit of anything ^^
I think we should stop the scene’s execution.
It will do anything, your message will have holes.
After that, I don’t know what the solution would be: validate that the schema is the same, and if it’s not the same, stop the scene? The issue is that some API responses may have variable responses and that shouldn’t necessarily be a reason to stop the scene’s execution… Good question!
Actually no, I think it’s useful to continue even with other status codes.
Example:
You want to check that your site/api is up with Gladys. You create a scene that runs every minute and makes a GET request to your site. You do a « continue only if status != 200 » and you send a message « the site is down, status = {{status}} »
You want to control a device and send a message if everything went well
etc..
I think that in many cases, the scene should continue even with « error » codes, precisely so that the user can use this information in the scene.
For « internet is down », this seems to be a special case, and there we can indeed stop the scene.
Otherwise, we could in the box put a parameter "stop the scene if the return code is different from: « choose list of codes », but that seems a bit heavy, I don’t know
Hello @lmilcent!
I don’t really understand your example of using an API to fetch the weather when we already have a service that does that.
Why not use this service for the scenes instead of making an API call? (though we need to have the action?)
Otherwise, what you propose @pierre-gilles is clean, but we could indeed let the user choose to stop the scene based on x or y reason but we already have that with continue only if (right?).
After that, in case the response is different, why not add an option to stop it based on the user’s choice?
In my opinion, to meet this weather need, we just need to develop the missing bricks linked to the meteorological service, today OpenWeather but also tomorrow TotoMeteo
Just like the missing bricks in the agenda service (at this point in time, it doesn’t do much except do the same thing as native apps [not as well at the moment because we can’t interact with events])
I am aware that this represents work, I am a dev myself and I don’t have the time (as much time as on V3) to help you ^^.
I’m just sharing ideas, or my thoughts on certain needs
Apart from that, I’m keeping an eye on the progress of Gladys (for info, since zibee2mqtt I finally switched to V4 with my V3 still running to compensate for the gap, but that’s another subject )
It’s super clean and exactly what I had in mind when writing this topic!
.