Open wivaku opened 6 years ago
Unfortunately I do not know how to force a new image to be saved. I probably added those command line arguments in the hope that I could discover the functionality but I never did. Sorry to lead you astray.
Just wanted to bring this project your attention with respect to image capturing. https://github.com/thoukydides/homebridge-skybell
Update: Sorry, didn't realize that project is based on your research.
I'm not seeing any request that will force a new avatar image to be captured?
I can confirm that my homebridge-skybell project does not have any impact on when a new avatar it captured. It just uses the avatar that the SkyBell updates approximately once each hour, or the thumbnail for the most recently captured video if that is more recent. I am not sure why @whosit provided that link in this context.
The only way I know to force a more recent image is to use POST https://cloud.myskybell.com/api/v3/devices/<Device_ID>/calls/
to force a new video to be recorded, and then use GET https://cloud.myskybell.com/api/v3/devices/<Device_ID>/activities/
to obtain the media
URL for its thumbnail after the recording has stopped (approximately 45 seconds later). Unfortunately, the SkyBell servers only retain the most recent 20 recordings, so doing this is likely to result in "interesting" recordings being lost which isn't a particularly good trade-off.
However, I believe that Samsung SmartThings does have a way to trigger a snapshot photo (and receive low-latency button press and motion sensor events) as mentioned in SkyBell's blog post. These features appear to be provided by the SkyBell Connect API. Perhaps someone with a SmartThings hub could help reverse-engineer the protocol?
That was my original plan - find someone with a SmartThings hub and reverse engineer it. I've just not looked that hard to find someone.
I would also love to see if with SmartThings we could also reverse engineer some way to immediately detect a motion event (instead of waiting ~45 seconds for the new activity like you mentioned). This is, I think, the key thing missing from making the SkyBell useful for home automations.
My workaround for the event latency is to sniff the traffic going through my router between the SkyBell and its cloud servers. The traffic is DTLS encrypted (or at least it is now; the early implementation wasn't). However, it is still possible to identify button/motion events based on the pattern of packet lengths, although unfortunately not to distinguish between the two types of event.
I suspect we aren't missing much from the API needed to get these notifications properly. It probably just needs the right parameters to POST https://cloud.myskybell.com/api/v3/register/
to register a different type of endpoint that can subscribe to the relevant notifications. If this is the case then GET https://cloud.myskybell.com/api/v3/users/<User_ID>/app_installs/
and GET https://cloud.myskybell.com/api/v3/users/<User_ID>/app_installs/<App_ID>/subscriptions/<Subscription_ID>/settings
on an account with SmartThings connected will probably reveal the necessary details.
I tried @thoukydides tcpdump packet sniffer code and it works well to quickly detect events. I even got it installed directly on an Asuswrt/Merlin router. I did want to be able to detect motion from doorbell push events, so I next tried dedicating an old Android phone running the Skybell app with Tasker+HASS plugin. Push events to the Skybell app and then to HASS happen almost immediately, including the ability to identify motion vs doorbell. This is working much better than I expected and has been perfectly reliable for over a month now.
So now I have been trying to use Telegram to send camera.snapshots of who is at the door from either event, and so far, that seems to be impossible without sending a useless outdated image. Of course, this is a known issue, well documented in this post.
I was hoping that taking a snapshot of the last_activity would work, but trying to figure out the delay from when this image is actually posted to when the snapshot of it would be useful is just too unpredictable.
What I am trying to understand a bit better is this statement...
SkyBell updates approximately once each hour, or the thumbnail for the most recently captured video if that is more recent.
Is grabbing this "thumbnail" a possible improvement that could be made to update the image upon an event? Or is that thumbnail just referring to the last_activity image which is already being pulled with some significant cloud delay?
What I am trying to understand a bit better is this statement...
SkyBell updates approximately once each hour, or the thumbnail for the most recently captured video if that is more recent.
Is grabbing this "thumbnail" a possible improvement that could be made to update the image upon an event? Or is that thumbnail just referring to the last_activity image which is already being pulled with some significant cloud delay?
Yes, this is referring to the thumnail for the last activity video clip.
The thumbnails for recorded video clips are only available after the recording finishes and has been completely uploaded to AWS. Depending on the duration of the video this could be a few minutes after the activity that triggered it. The SkyBell website quotes various video durations, from 90 seconds to 5 minutes, although they can be shorter. We do not yet have a way to determine when this is available other than polling the server using one of:
GET https://cloud.myskybell.com/api/v3/subscriptions/<Subscription_ID>/activities/
GET https://cloud.myskybell.com/api/v3/devices/<Device_ID>/activities/
Thanks @thoukydides for the clarification. I was poking around in the skybell pickle file which has the URL to the "small.jpeg". I assume this is the last activity thumbnail. I didn't see any obvious way to leverage this file to determine if an image updated. It appears to be recreated about every 30 seconds. It's not clear why this data is written to a file instead of memory (to minimize SD Card wear), but oh well.
So unless someone reverse engineers the SmartThing connection or Skybell finally relents and grants a HASS or Homebridge developer access to the API, then obtaining as-it-happens snapshots (or live video) is a dead end with Skybell.
Maybe I'll just have to mount that repurposed Android phone outside and take snaps with it! Just kidding, but I am keeping my eye on the Eufy and Amcrest Doorbells to see how well their integration progresses.
Not sure if the CLI version is ready for use?
A skybell.pickle is stored, but no image file is saved.
For
--capture
the skybell.pickle contains all the image URL's (for on-demand, button and motion). These are existing images, and not as the help suggests: "Trigger a new image capture for the given device_id".For
--json
an error message is shown.For
--image
it seems it does the same as--capture