Hi Anova. Suck less. Tell us how you plan to do this.
What is API?
An API is a hook for hackers.
Application Programmming Interface allows inter communication between computers. Contrary to User Interface UI for mere mortals.
Why would you want this? It’s a cooker!!!
There is no requirement that Anova provide an API and dissing them for it will likely get you nowhere. Ask nicely, offer to help, demonstrate why it would be a benefit, and maybe it will be considered.
Here, read this. It was asked nicely, someone even found a way to get the keys to allow access for automation or changing temps throughout a cook. Then they blocked it.
OK, so they proved they don’t want to do it, but no matter what, getting angry probably won’t accomplish anything. Likely some lawyer told them it’s a problem and it’s going to be a long journey and it might never happen.
Offering API access requires a whole new development and testing division to vet the entire API. Otherwise, opening the oven, a device that uses electricity, heating elements, and water and lives entirely surrounded by lacquer-finished wood – what could possibly go wrong? – opens them up to all kinds of liability.
What if you use the API to do something that is beyond the specs of the oven, like broiling at 500 degrees for 30 minutes? An unfettered API would not stop you from using this over-heat to burn down your house. Then who are you going to sue?
To release the API, they would first have to build a portal/session manager, then test limits on every single controllable option, then test every combination of every single option. The costs of that would be astronomical, and I, for one, do not want to pay extra for a small number of people to be able to tweak their bacon cook from their Alexa.
So yeah, it’s sad they don’t have an API; but it’s also completely understandable, both from an economic and a liability standpoint.
I think API access would be pretty cool, I hope they can do it at some point.
That is horrible and wrong argument.
You need at least same firmware level limits and same testing with cloud as with local API.
If you do somethink wrong with local API without firmware level limits, worst case scenarion is your house burn to ash. With cloud based solution worst case scenario is thousand of houses burn to ashes. It can be bug on cloud, it can be hacker attack,…
When somebody hack anova servers, what stop it from like broiling at 500 degrees for 30 minutes? What stop hacker from using this over-heat to burn down your house? Only limits in firmware. So there is no difference between API and cloud access dangers. No extra testing for safety reasons. All already need to be done.
This is limits need to implement on firmware for cloud and they are same limits you need for local API, because cloud is not safer then local api. You can’t be sure that cloud is not compromised. It’s irelevant from what source it get command. Even if that is from god of internet, firmware need to tell if it’s safe before do what command say.
And secondary, even if there is safety reason (which is not) for not accept command with local API, what reason is for not sending data? Why not at least get read only access?