[APP][PRO] Blink for Home

I have now checked with USB, unmoiunted USB, missing USB. I could not get your situation.

But while checking it, I added the USB state to the system device and adjusted video reading logic to ignore errors based on missing USB.

Perhaps that solves your problem, too.
Please try test version 0.0.12
If it’s still not ok, please send a diagnostic report and send me the ID as PM.
Thanks for your help and patience.

1 Like

Hi RonnyW,
The app seems to work now as expected. I can control my system, each camera and get updated status values.

Nice work!

1 Like

I Can also confirm that the values started to work as of version .12

1 Like

@MarcoRuiter @petomei
So possible errors while reading SyncModule data are solved.
How dows the system look now? Is a USB state displayed in your devices?
grafik

If not, it would be nice if you could send a diagnostic report. Perhaps I haven’t found all possible situations which could occour. Thanks.

I’m not really sure what would make the USB state active ? I dont have local storage and my USB status tells me “niet beschikbar / not available”

Yes, that’s the correct state. Active is when you plugged in a stick and unmounted is when you unmount via Blink app. Not available is when no USB is plugged in.
If you have this state, the the app was able to get the SyncModule state (or ignored http errors) and set the device state correctly.

The dutch translation is done with Google translator only.
So if you have corrections/suggestions, please write, perhaps as PM. Thanks for the help :slight_smile:

@MarcoRuiter and all users with cloud subscription (cloud video storage):

A suggestion for a fine tuning of your setup regarding the motion alert recognition based on cloud storage

You are using cloud storage for the videos. And reading the video list for motion recognition is account based. So only one API call is done for the whole list independent of the amount of cameras or systems/SyncModules.

So I think, a 5 second intervall for checking the cloud video list should work.
In addition you can set the wait time for API errors to 0 (zero). That way, every API error will show you the ! icon on the account tile. This way you can check if 5 seconds is ok. If API errors are shown (http 403 / blocked), the go to 6 seconds and so on until you have a good compromise between short motion alert intervals and a stable API connection without rate limits.

1 Like

@All users with local storage:

A suggestion for a fine tuning of your setup regarding the motion alert recognition based on local storage (SyncModule)

With local storage, the videolists of all SyncModules are needed to check for new videos (which represents a motion).
So your video reading interval deoends on the number of used SyncModules.
For cloud storage, only one API call is nedded for the whole account. With local storage, 2 API calls are needed fo each SyncModule. If you have installed 2 SyncModules, you need 4 calls. That results in a read interval 4 times longer than a possible cloud access.

A good way for optimization is to start with 15 seconds interval.
In addition you can set the wait time for API errors to 0 (zero). That way, every API error will show you the ! icon on the tile. This way you can check if 15 seconds is ok.
If you periodically get http 403 errors, your rate is too high. Adjust to 20 seconds and check some hours. Increase the interval if still http 403 errors are shown.

The SyncModule access has another disadvantage:
It will show an unspecific http 409 error. In that case, another request is processed by the SyncModule. That can be caused by yourself (reading video list or playing videos in Blik app) or by another reason (cloud sync, cameras connecting to or writing video data…). These errors are difficult to avoid. The only way would be to inrease the interval to avoid overlapping requests. It’s a kind of try&error to find a good interval.

New test version 0.0.13:
Added repair function for account device. If you changed your Blink password, you can change the account device password via the device settings/repair function. This way you can re-auth your Homey device.

I tested it several times. Please report if you get errors on re-auth using the repair function. Thanks.

Is it possible to

  1. create recurring snapshots and
  2. store them to the local storage (like a cloud enabled account would do)?

I can’t find a card for it at the moment

Creating snapshot is possible with the flow action card for the camera. That retrieves a new image (asynchronous because the camera needs time to take a snapshot). Then you can react with a flow trigger on the new snapshot. Use the flow token to send the image as push message.
But with local storage, the snapshots are NOT stored in then syncmodule. That’s a restriction of Blink.

See the camera settings in the Blink app:

PS: I wonder if there is an app to upload the image toke to a NAS via SMB or FTP? At least a web upload using a http POST could work. Would be a nice addition but nothing for the Blink app itself.

Testversion 0.0.14 has some new features for snapshots. I will explain it with some examples in the next posts…I think you will like it :smiley:

Howto… use global tags for snapshots:

You don’t need to use the snapshot action card for taking snapshots for push messages. This is simple done using the global tokens of your camera in flow actions.

Example: You are sending snaoshots via push.
Just add the glokal token to your push card. You can find it under the camera name.

Every time this token is used, a snapshot is retrieved from the camera.
You see, using it once is goog. Using it several times (to send to several persons) is a bad idea.
Why? Each token will call the camera. The camera needs ~5sec to make a snapshot. So you need a delay in the flow. Else the following pushmessages can’t create snaopshots (camera is busy) and you get a push message without picture.

So please use snapshot this way if you call it only once.

Howto…use action card for snapshots (Advanced Flow example):

If you want to avoid multiple calls for snapshots in a flow, you can use the action card of your camera.
Previously, this action card used the camera tokens. But with the neew update, the action card retrieves the camera snapshot once, buffers and reuses it for each usage in your flow.

You can use the result directly in AdvancedFlows (the local token from the action card).
I have a delay in this example to check the timing. You can use it without delays.


Use the token below “This flow”.
Placing the mouse over the token in the push action card you will see the token icon blue highlighted. So you can see, where the token comes from.

So your camera is blocked olny once for ~5sec. This avoides missed motion events.

Howto… use trigger event for snapshots:

The example above works in Advanced Flows. But in standard flows you can’t use the result of your action card.
But every time making a snapshot, the correcponding trigger (a snapshot was created) is executed.
So you can make a snapshot with your action card and react with the trigger. You can use this also to split your flow of if you have several places where you want to create a snapshot, but wants to have one place for the action.

This example is designed in Advanced Flow canvas to show it in one picture. It works in both flow variants.
Using the flow action has the same advantages like the example above: The snapshot is retrieved once.

Howto… Store a snapshot on a SMB share:

This is a really new feature. This opens the possibilit yto locally store a snapshot - independent of your Blink subscription. Because with subscription, you can periodically store snapshots in the cloud storage, but without subscription you can’t.

The app has a simple action card (for the app, not for the camera devices) for storing image tokens.

Yust use the app action card in the flow and fill all your SMB values:

  • server-IP and share name
  • camera name (optional). You can use the trigger token if you use the “a snapshot was created” trigger or enter it manually
  • SBM user and password

These informations are stored as flow parameter. Please use it only for local access (NAS) and use a specific user with inly this access rights (no admin user).

The file will be named with a timestamp and the camera name (if set).
grafik

In this example, the global snapshot token is used.
If you wants to use the snaphot for more actions, you can use the action card from the example above:


This way you can use the tokens of the trigger card.

Please note: using this SMB functionality will increase the app memory usage by 10 MB - until the app is restarted. This is caused by the used NodeJS modules. So don’t worry about this.

1 Like

Have fun with your snapshort. Please report bugs or if there is a high/raising memory uasge over some days. PLease contact me in that case. I will have some detailled questions to reproduce the situation.

Just one word for this update : Awesome

Thx again

1 Like

Testversion 0.0.16 adds a snapshot to the motion alert trigger (Cloud subscription only!).

The motion alert trigger is added to the camera devices. Until now, this trigger was only available for the account device (triffer for all assigned cameras). The cameras had only the alarm capability and its trigger. Now you have a dedicated trigger for the app, too.
The trigger has the following tags:

  • camera name
  • timestamp
  • new: snapshot image

You can now send the snapshot image with a push message to your mobile phone and see wha’t going on without need of the blink app to check the video.
The snapshot is the same you can see in the video list in the Blink app.

Please note: Blink only stores snapshots for motion alert videos in the cloud storage. So a subscription is needed (still free).

Use it in your flows:
Use the local flow tokens under “this flow”:

grafik