Open APIs for developers

[jerryk]

There are many developers that would like to extend the capabilites of the cameras specifically and the system in general.  If there was an open API that would let users access their local cameras and control them that would be great.  Also, if there was a documented RESTful API to get to the data on the servers that would allow incorporating the data into a whole host of applications.  I suspect both the camera and server APIs do exist since the original developers had to use something.  If other could get at these interfaces this system could be the go to system for developers.

[conso2]

My italian sarcasm "de borgata" sometimes is taken too seriously! 😉

[thaweatherman]

@jeffreydwalter i cloned your python package on github and am working on improving it. i develop python full time so i'm making it actually look and behave in a pythonic manner. thanks for doing the initial work.

[jeffreydwalter]

@thaweatherman, awesome! I appreciate your help. Please submit your changes as a PR and I'll merge them in. Thanks!

[thaweatherman]

@jeffreydwalter I will once it is ready! I'm trying to get the endpoint for retrieving your custom modes to work but the call that gets made just returns {"success": "true"} and nothing else. It's quite odd.

[jeffreydwalter]

@thaweatherman the CustomMode() method of for setting custom modes not retrieving them.

[thaweatherman]

There's a call that gets made that sets the operation to "get" rather than "set" for modes. The web UI has to know about your modes somehow and I assumed that was it, but the call doesn't return anything besides success. It gets made when you go to the Mode page.

[jeffreydwalter]

@thaweatherman, the call you're looking for is https://arlo.netgear.com/hmsweb/client/subscribe?token=xxxxx This call returns an EventStream and several pieces of data are "streamed", including the modes. I didn't implement that call because it wasn't really important to me. The browser basically maintains this stream for the whole life of the session and events are pushed to the browser in "realtime" that way.

[thaweatherman]

Ah, yes I saw that call but hadn't fiddled with it yet. I think I'll get the existing stuff finished and merged in then I'll move on to adding that call, potentially.

[jeffreydwalter]

@thaweatherman, I think I've figured it out. Basically, the website subscribes to the eventStream via the GET /subscribe call, which is a streaming request. Then calls of type 'get' to POST/users/devices/notify/XXXXXXXXXX cause a event to be streamed to the eventStream. Then finally, when you logout, the website makes a GET request to /unsubscribe, which closes the eventStream.

So, in order to make this work in the Python library, we're probably going to want to do one of two things:

a) Just call subscribe, and after receiving the {connect:success} message, make the request to the specific 'get' we want and then unsubscribe from the eventStream after receiving the response.

b) Open a separate thread for the eventStream which would stay open until unsubscribe is called. Once we have the eventStream running in the background we can make as many 'get' requests as we need and get the responses from the eventStream thread via IPC. I've almost finished writing scenario 'a' and will push those changes shortly.

[thaweatherman]

@jeffreydwalter Awesome work! I probably won't have time to look at it for a few days, but early next week I should be able to try it and integrate it into the changes I've made so far.