these are my rules:
The last line triggers another rules witch disarm the system:
Maybe disarming 2 networks at the same time is too much?
I will install the new version and see what happen.
@ymerj Not sure if it will help for disarming but for turning motion detection on or off for 2 cameras, I had put a 3 second delay between the actions for each camera. Without that delay it was missing the action for the second camera.
1 Like
same things happened to me too with the updated driver fwiw
It looks like neither of yours are authorized... but why didn't the reauth run? Line 421 IS in the reauth in the latest driver version... so maybe the refresh attempted to reauth and got an error there also?
That "No response data" is the thing I had the last bullet for on the changes... Obviously it did not fix it. I wonder how it can be checked? It tests for a null already but what is happening is a Java Exception.
What happens if you each select the "Request PIN" command to manually reauthenticate? Do things start working then?
Looks like I will have to get more work done tonight and hopefully have something tomorrow night.
1 Like
I was getting unauthorised messages in the logs... and wasn’t able to reauthorise because the client field (and user/pass) had disappeared. I had to uninstall and reinstall. Once reauthorised, all back again... but I appear to have lost the battery status fields...? I can’t see the attributes that can be used on a dashboard.
I used the request PIN option and the logs show that I didn't need verification: "verification_required":false,"
dev:3642020-10-13 10:45:18.123 am traceBlink - PIN response = {"account":{"id":<SNIP>,"verification_required":false,"new_account":false},"client":{"id":545742,"verification_required":false},"authtoken":{"authtoken":"<SNIP>","message":"auth"},"region":{"tier":"u008","description":"United States","code":"us"},"lockout_time_remaining":0,"force_password_reset":false,"allow_pin_resend_seconds":60}
dev:3642020-10-13 10:45:17.596 am infoBlink - Requesting PIN for validation.
Then, I tried a Refresh but got this:
dev:3642020-10-13 10:45:33.280 am errorBlink - PIN must be verified within 40 minutes. Enter the PIN emailed to you, Save Preferences, then select the Verify PIN button.
dev:3642020-10-13 10:45:33.274 am traceBlink - Has ClientID
dev:3642020-10-13 10:45:33.271 am traceBlink - Has Email and Password
@nutcracker:
If those fields disappeared from the preferences... it means the state.Verified = true, except that all the other authentication errors at the moment meant it was unauthorized overall but not showing it. Sorry. That is the main thing I am trying to fix.
@jpage4500:
Trying to build in something now to ignore the PIN (and messages like that) if the Blink said verification required = false. See if that works in the long term. The Refresh was related to that.
All:
Reauth is broken in build 0.1.14 it appears. If your system fails to work with some error, hit the RequestPIN command to have it reauthenticate (which does not use the reauthorize command). I am working on this, but the "no response" problem is giving me fits. I thought I had a fix, found it broke WAY more in the process, then found a possible new fix. BUT... I now have to wait for my token to expire again. Because of how bad this one is/was I am not going to have a build out tonight, hopefully tomorrow night after I get another test.
2 Likes
All:
After updating to the latest driver, please run the Authorize command from your parent device after saving the new driver. This is to try to make sure your device(s) will remain authorized from now on (per below Changes).
Updated Version(s):
- BlinkAPI.groovy = 0.1.15
Change(s):
- Main change is the removal of the reauthorize function and related mess. This was just causing so many problems and kept getting more complicated. Rather than have it try to reauthorize if there is an issue I am trying the "ounce of prevention" method. In this case what will happen is that the Authorize function (previously named Request PIN) will be called once every 12 hours. This should reauthorize and obtain a new auth-token to keep everything running without error. At least it did for me over the last 2 days...
- Updated the install instructions to remove Request PIN and replace with Authorize.
- Expanded error checking in Refresh for when it runs GetHomescreen. Hopefully this will eliminate error messages when there is no error.
Known Issue(s):
- Still might be have the Armed/Enabled list error. I have not seen it lately on mine. Has anyone else seen it (only applies if you have more than one camera/network)? If it appears it has gone away I will remove it as a known issue, but I do not want to be the only test point here.
3 Likes
Ok, I’ve uninstalled and reinstalled.
Have reauthorised.
New child devices created as before.
I’m not seeing any battery statuses as before (just the one for “ok”)
I don’t appear to be getting state of arm/disarm when getting Homescreen.
Arming causes an error but does arm Blink. Disarm works fine.
2020-10-15 09:04:03.270 errorjava.lang.NullPointerException: Cannot get property 'value' on null object on line 1154 (GeneralResponse)
You really should not need to reinstall with the updates.
"battery" will show up when the GetCameraInfo is run as part of the daily check. The battery voltage is not reported in Homescreen, but is in GetCameraInfo. Homescreen only reports the "OK" value (which I guess makes sense for a "quick status" that the Homescreen is meant for.
Thanks for the note about arming from Homescreen! I found I was only getting the NetworkID from it, NOT actually processing them through. Although the only really useful data is ID and armed, but in the next version (update tonight most likely) it will now add the Network child from Homescreen and update the armed state for those because that data is there.
Found the error with the Arming, so thanks for the log! It was a simple "wrong variable" name based on a previous attempt for the Armed/Disarmed event. Already have it fixed for the next version.
As always, feedback is greatly appreciated!
1 Like
Using the latest drivers I was able to call arm/disarm on the camera!
I noticed an error in the logs but it didn't seem to affect anything that I can tell.. just wanted to note it
dev:3642020-10-15 09:38:39.599 am errorjava.lang.NullPointerException: Cannot get property 'value' on null object on line 1154 (GeneralResponse)
dev:3642020-10-15 09:38:39.545 am traceBlink - General Response: data: [Method:Arm System, ID:39640], resp.data: {"id":363562934,"network_id":39640,"command":"arm","state":"new","commands":[{"id":363562935,"network_id":39640,"command":"config_lfr","state":"running"},{"id":363562936,"network_id":39640,"command":"config_lfr","state":"running"},{"id":363562937,"network_id":39640,"command":"config_lfr","state":"running"}]}
dev:3642020-10-15 09:38:38.924 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-15 09:38:38.873 am traceBlink (front door) - Arming network 39640.
I just updated the drivers to BlinkAPI 0.1.15 and BlinkChild 0.1.8. Things appear to be working ok. Arming and disarming still works.
I just noticed one thing. My email, password, and client pin are now displaying in the blink api device preferences despite the state variable "Verified : true".
Authorization works. Arming works (2 networks at the same time through a rule) but I get the same error as mention by others:
The network devices states they are disarmed even though they were armed.
All:
That 1154 error will be fixed as soon as I publish the new version (I fixed it before I even started my day job this morning). It was because I was calling "it.value" from an older method whereas it should have been "data.ID".
@M6TTL:
AH! Good catch. I forgot to include that in the notes. I "unhid" those once things are Verified because it is a tradeoff between people getting to the settings (there was no way if Verified equaled true) and simplicity of the preferences. It is impacted by the "Show All Preferences" selection though, so if someone knows they are set and wants to move on, they can still hide them.
2 Likes
okay, I'm a NOOB to HA but have been using ST for many years including CORE. I created a simple rule using a virtual switch called camera arm/disarm. I followed the example calling for the sync module to be armed when the switch is on. the part I can't seem to derive is the integer value. I assumed it was the module ID? I could use a kick start!
In the device page for the sync module you want to arm/disarm, look under State Variables for the ID variable (just ID, not Account ID). That's the integer to be used as a parameter.
I should note that I'm arming by sync module just like the Blink app does. But there appears to be other ways to do it using newer versions of this driver if you prefer another approach.
The main alternative is to Arm the specific child device (Network-#####).
okay, I assumed that was the value and used it but that isn't working. I must be doing something wrong elsewhere. This at least removes this as an uncertainty. There use to be a custom handler for ST that got killed that allowed activating motion at the camera level and this is my goal here but I thought I would crawl first. Thanks for the rapid reply
Updated Version(s):
- BlinkAPI.groovy = 0.1.16
Change(s):
- Corrected value for Armed reporting, solves line 1154 error.
- Network(s) now processed as part of Homescreen (on Refresh). It should pull in their ID and whether they are armed or not.
- Corrected Authorize scheduling (I had it set to run at noon, not every 12 hours). This may change again in the future to be every 12 hours based on when the schedule last gets triggered rather than the "noon & midnight" schedule it is now.
Known Issue(s):
- Still whether Armed/Disarmed & Enabled/Disabled lists on parent device are working fully...
- Still working on thumbnails.
2 Likes
