@nutcracker - thanks for the detailed steps - i'll try that out tomorrow. 1 thing I wasn't sure I see in here though is -- if you arm/disarm Blink from the app (for example) - are you able to update the virtual switch state to match the blink system? Otherwise, would the virtual switch get out of sync with the actual state of the system?
Hi, yes it’s possible that the switch would get out of sync with the actual status of the Blink if you used the app as well. The Blink status on the dashboard will update on the next poll. You would end up in a loop if you watched for the Blink status to change to then update the status of the switch... don’t think you can do much about that.
Personally for me, if I can automate the setting of the Blink system as much as possible then I shouldn’t need to use the app itself to arm/disarm.
Just need @snell to get the images/video pulling down and visible now...! 
(either by cracking the driver render issue... or may be turning this into an app/driver setup???)
No pressure. I REALLY do not want to have to learn apps for some reason, but I really want the thumbnail to be available. It is really annoying to me that I have the data but cannot figure out how to display it readily. There needs to be a functional "image" attribute.
Maybe I need to submit that as a feature request.
2 Likes
I was wondering about that a while back.. are you getting the actual image data? and then are you looking to return an image URL that can be used by a dashboard?
Not sure about storage on HE - but can the data be saved to the hub using some name that won't lead to multiple image files per camera (ie: filling up storage)? Or, maybe it'd be possible to upload it to an image sharing service like imgbb.com? (the latter might not be ideal for security reasons though..)
It is indeed receiving the image data (it takes a bit also). The hub does not allow storing image files locally from a driver (at this time). You CAN store files from Rules, but that does not help in this case (because of the auth-token needing to be in the header not the URL).
Not sure about sending it elsewhere, like you said it seems like a security risk. If/when it is possible to save the image file locally (it IS just a jpg) it would be very easy to name them specifically so they would just get overwritten (like they currently do when you take a new thumbnail). They are not very large.
1 Like
I am trying to follow your example from above on how to use this in RM. I am fairly new to HE but have been learning a lot in the last couple of weeks.
My question is this. What action are you choosing in the drop down to be able to put "ArmSystem" in as an action?
Here you go, custom action.
Select the Actuator to be the Blink network device and from there you can choose ArmSystem.
1 Like
Perfect! Thanks so much for the help and quick responses. Great community here!
2 Likes
This seems new - it happens when I try to call arm or disarm on any of the camera devices. This was working before - not sure what changed.. I did remove and re-add the device last week. I also confirmed that the armed state didn't change via the Blink app
dev:3642020-10-11 02:24:37.229 pm errorjava.lang.Exception: No response data exists for async request on line 1192 (GeneralResponse)
dev:3642020-10-11 02:24:36.791 pm traceBlink - Disarm System Params = [uri:https://rest-u008.immedia-semi.com/api/v1/accounts/36734/networks/39640/state/disarm, headers:[token-auth:<SNIP>]]
Trying to arm my system today, I got these (after dozens of "Unauthorized" and "Reauthorizing auth-token" log entries):
Arming did not work. Then later:
But this time it worked despite the errors.
@jpage4500:
Looks like I have to put another error condition in, but it is weird it did not work, disarm is pretty simple. Do you actually have a network with ID # 39640? Can you enable trace on the camera device also so I can see if it is reporting any error?
@ymerj:
The 429 error is the HTTP response for "too many requests" sent in too quickly (I will have to add that in as a status result). It should not have had dozens of Unauthorized and Reauthorizing though... It is supposed to fail out after 5 tries in a row (although there COULD be some overlap due to asynch... hmm... wonder if that could keep the count from incrementing properly... something else to think on). In any case, could you let me know how many requests it actually was and across what timeframe (first one to when the last one was or it finally did give up)?
As for the "network ID is unknown"... but it works, that is a known error on my part. I left out a break from switch/case... so it works because it runs the first part but then it still gets to the rest and displays the error incorrectly. That is fixed in the next version once I post it.
1 Like
There were 40 requests between 14:12:43.638 and 14:12:44.503
40 requests in less than a second?! I do not even know how that is really possible but obviously it was...
Was this a Rule triggering the arming or did you select it manually and just the massive amount is reauth? I guess part of what I am asking is whether a number of those 40 are repeated attempts to do the main thing, compounded with reauth repeats.
Really need this looking at as there’s the risk of a number of us being banned from their servers... 
. Anything obvious in the code that sticks out? It doesn’t appear to be happening all the time - mine was fine today but I’ve seen this pattern (reported it before). What do you need to help fix?
I do not think it will cause a ban... but I am really not sure what is causing it at this point. If it is from manual triggers only, then it HAS to be the reauthentication portion. I think it has to be related to the asynch (YET AGAIN that comes back to bite me). If the asynch response is being processed while others are being processed, it might not hit the 5 limit because they keep resetting the variable between those different processes... but 40 times?! If it had been a rule, I could understand maybe the Rule had a flaw and was just spamming the change. But a single, manual one... that then triggers tons of reauth. Ugh.
My one idea is to try to change the reauth portion to be a regular http NOT an asynch. That way it will wait for the response and not try to do anything else. Those sometimes switch over quite nicely and sometimes result in absolutely incomprehensible errors for me. Hopefully this will be a "it worked" moment. I will have an updated version published today (starting to work it now).
Not sure how I never hit these problems either, but that is a separate issue.
2 Likes
Yep, the network ID is 39640. I changed a camera to trace logging and tried to arm it:
dev:3642020-10-12 10:16:22.912 am errorjava.lang.NullPointerException: Cannot execute null+[39640] on line 1202 (GeneralResponse)
dev:3642020-10-12 10:16:22.858 am traceBlink - General Response: data: [Method:Arm System, ID:39640], resp: {"id":361708450,"network_id":39640,"command":"arm","state":"new","commands":[{"id":361708451,"network_id":39640,"command":"config_lfr","state":"running"},{"id":361708452,"network_id":39640,"command":"config_lfr","state":"running"},{"id":361708453,"network_id":39640,"command":"config_lfr","state":"running"}]}
dev:3642020-10-12 10:16:22.330 am traceBlink - Arm System Params = [uri:https://rest-u008.immedia-semi.com/api/v1/accounts/<SNIP>/networks/39640/state/arm, headers:[token-auth:<SNIP>]]
dev:3662020-10-12 10:16:22.319 am traceBlink (front door) - Arming network 39640.
It should be armed overall and show as armed in their app (because the response was successful). It looks like what is happening is that when it attempts to add the ID # to the "Armed System(s)" list... it is failing because the list is null and apparently the .plus command will not work to a null list... because of course that latest attempt would not work either.
I will add another attempt for that area in with today's version.
1 Like
Ok folks... new version incorporating a couple of the minor changes PLUS hopefully a fix for the big new issue:
Updated Version(s):
- BlinkAPI.groovy = 0.1.14
- BlinkChild.groovy = 0.1.8
Change(s) to BlinkAPI.groovy
- Changed reauthentication to have it's own attempt NOT using the RequestPIN method. It has also been changed to httpPost methof (from asynch) so it should WAIT for the response. It worked for me... but I only get one shot of these things work. At least 24 hours for the token to expire so I can try again (without breaking the token myself, which I am hesitant to try as I do not want to cause any risks for something that fundamental that typically works).
- Should no longer ask for a PIN if Verified = true (even if no PIN is ever entered).
- Fix for attempting to add a network when the state."Armed System(s)" was null.
- HOPEFULLY handling a null response from Blink in the GeneralResponse area. This appears to be a change on Blink's part. Previously they provided an "Unauthorized" response, now apparently they do not respond. So I am trying something to hopefully handle it and reauthorize (which solves it). Again, something I can really only test once my token has expired. Hopefully it works for other people.
Change(s) to BlinkChild.groovy
- Corrected switch/case statements for arm/disarm so it should no longer give error-seeming log messages even when they work.
Known Issue(s):
- Thumbnail still not implemented (because I cannot get it to display images).
- Still could be some "weirdness" with IDs in Armed System(s) and Camera(s) With Motion Enabled, but these seem to be behaving a bit more now.
Different Topic(s):
- I hit the browser caching the driver today after I loaded the new version (my browser still showed the old one when I went to double check the version control for my changes). I am going to edit the very first post so people know this is something to watch for when new versions come out. So just a reminder, if the import still shows the current version... refresh the driver's webpage to clear the cached version from your browser.
1 Like
