search

jeffreydwalter / arlo-go

WIP - (BETA) - Go package for interacting with Netgear's Arlo camera system.
MIT License
43 stars 8 forks source link

Helping out #2

Closed jryd closed 2 years ago

jryd commented 5 years ago

Hi Jeffrey,

Just picked up my own Arlo Pro system this weekend, and as a developer who is familiar with Go, I'd love to help you out with this library.

How far have you gotten with this? What can I do to help?

jeffreydwalter commented 5 years ago

Hey James,

Sorry for the delayed reply. Been distracted with the holidays. Thanks again for your contributions!

If you'd like to contribute, here are some of the things that still need to be done:

  1. There are quite a few APIs that still need to be implemented. This is probably the biggest help you could give. If you look here: https://github.com/jeffreydwalter/arlo-go/blob/master/const.go you will find the whole list of APIs I found in the Arlo javascript. The library doesn't really need all of them to be useful, but the more of them we can implement the more useful the library will be. The python version of this library has some of the missing APIs already implemented, and they just need to be ported over. If you want to work on that, that would be a big help.

  2. Another issue this library currently has is that the Arlo ecosystem has grown quite a bit since I started this project and there are many devices that I just don't own so I haven't added support for them yet. (lights, bridges, siren, etc.) This is a more complicated project because it may require some rethinking of the overall implementation of the library.

  3. Another thing to look out for is race conditions and bugs. Ideally, this library should be able to run multithreaded with API calls being made to different devices concurrently. Unfortunately, the whole API is based on the EventStream protocol, and so Arlo has restricted all accounts to a single active HTTP session at a time. Also, the EventStream is basically a one-way pub-sub channel, which makes getting responses challenging. Basically, the client subscribes to the EventStream and then the client makes HTTP requests to a specific endpoint, and the responses are returned to the EventStream. Sometimes, a single HTTP request can generate multiple events on the EventStream. Generally, the events include a transId which is sent as part of the HTTP request. This transId can be used to correlate the request with the response, but this is not alway true (sometimes it's not included in the responses). In short, the Arlo API is crap, and they basically gave 0 thought to building out a public API.

I'm happy to have any help you're willing to give, so thank you in advance for the offer! Please let me know what I can do to help you help me. :)

jryd commented 5 years ago

Awesome, sounds like there's a fair bit to do.

I'll get my hands dirty working on implementing a few more of those APIs. I don't suppose you have a todo list? Otherwise I can just make one to manage what still needs doing?

I'm not super familiar with the EventStream so will start doing some reading on that in the meantime. Have you got an implementation of that already working that I can look at?

jeffreydwalter commented 5 years ago

Hi @jryd! Sorry for the delayed reply. Life has gotten in the way lately. :)

My main todo list is just to implement the api calls. You can find the list of them in const.go. The EventStream implementation is already basically done in the Go code in this library.

It's pretty simple. It's basically a long lived http (tcp) connection. The client makes an http request to the EventStream API, and then waits, listening for incoming messages streamed to it. The format is a little esoteric, and is not super important to understand to be useful with this endeavor. The main thing to know is that the EventStream is read-only and once a message is read, it is no longer available in the stream. The Arlo API works by POST'ing JSON messages to the /notify endpoint. When a message is received on this endpoint, the backend does whatever that message said to do and then a response is returned to the EventStream (most of the time). This allows the UI (mobile and web) to be asynchronous.

There is a minor race condition that occurs if you run a single arlo instance in multiple go routines, but I'm not very concerned about that at the moment. There will most likely need to be some rethinking the concurrency stuff in my original implementation, but is not critical for this library to be useful as-is.

Hope that helps... I should be more responsive going forward and look forward to any contributions you might make!

jeffreydwalter commented 5 years ago

@jryd do you still have any interest in working on this library? :)

jryd commented 5 years ago

@jeffreydwalter I do.

I've submitted some pull requests already to help close out some issues.

I'll admit that I'm not super experienced with Go. I've used it for a few API integrations, and have an understanding of how it all works - but I can't say I'm super confident in it.

What's on your to-do list? Still the API calls?