I was able to disarm before, but something has changed during last half year. I cannot find a way to disarm or arm my cameras or sync module.
Question to ones that can arm and disarm.
How do you control those? I`ve tried switch on/off and SystemArm() and either of those does nothing. Can you post picture of working rule?
I just use the Network devices and turn them on or off. Does that not work for you?
Are there any errors in the logs when you try this?
I just pressed "SystemArm" on one of my camera children and the system that camera is part of switched to Armed (I double checked in the app). "SystemDisarm" worked as well.
On/Off on the camera controls whether Motion is enabled or disabled (both of which worked just now).
You got it. ”Blink API - Unauthorized”. Reauth to false and got code via sms. Code in place and reauth true and it works again
Glad to hear it was a simple fix.
This is something I don't think I've seen before:
Blink Cameras - Conflict detected, attempted [Method:Disarm System, ID:39640]
I don't see any other logs but I'm guessing I don't have any debug logging enabled which I can for next time (if it happens).
Anyway, I was able to disarm it manually (this was from automatic disarm based on HSM arm/disarm status). Just figured I'd mention it in case it meant anything
I want to say that the only time I've seen that is when I had an arm command pending/in progress and accidently hit the disarm.
As @thebearmay stated, I have only seen this happen a few times and it seemed to happen if the API has not finished processing some other command. Did something accidentally tell it to do things too quickly?
I brought the Blink devices into Node Red using the community Node Red integration a long time ago but don't use Blink in any of the flows. However, I just noticed this error message in my Debug window in Node Red. I haven't noticed any ill effects nor know if it is important. Device 1797 is my Blink device.
"The device (1797) sends an event (Armed System(s)) with non-official dataType (LIST). The default behaviour is to leave the attribute value ([234642]) as string. It may result in a difference when getting attribute value with input vs event (e.g., json vs string). You should report back this issue to the device driver maintainer. Supported dataType: https://docs.hubitat.com/index.php?title=Attribute_Object"
Well, my initial opinion is to just say "too bad" to Node Red and they should support a standard Groovy structure... It is a data array and converting it to a string would make it more annoying to check inside the driver.
I am surprised they do not use it OR (if they have some code issue with it) convert it to a string themselves rather than pop an error and expect the driver person to deal with it.
If there are no problems at this time... I am not going to change anything for it.
No worries. I wasn't sure but wanted to make you aware if it mattered. I also don't know if the error is generated by Node Red itself or the Node Red Hubitat palette.
Not that I do not change things to help mitigate issues with other stuff... I use lists and maps like that in many of my drivers and changing it here would likely end up requiring me to change it in others just to keep code consistent for me.
Thanks for the heads-up though. If it ends up actually causing a problem, let me know and I will see what I can do.
I noticed the same messages cropping up recently but don't recall seeing them before - which doesn't mean they were not happening. I put a 3 second delay between commands and it seems to be working ok. I did test the length of the delay so presumably it could go lower.
Are you talking about the same messages @jpage4500 was seeing?
Yep. I was turning the motion sensor on and off on several cameras at once. This causes the Conflict Detected error. So I split the individual requests up and put a delay between them.
Thanks. I will have to put some pauses in the driver for such things when I get back. I already had some similar delays in other areas but I will start looking at doing it on a broader scale.
I have always had 7-10 second delays in my pistons for every action.
I have found anything less and there are failures.
@snell
I was trying to be proactive the odd time my Blink fails to authenticate and not return.
Authorizationfailures=0
Doesn't happen very often though.
Curious as to the frequency of INACTIVE; seems to work fine but every hour I poll the status and issue an Authorize if I see INACTIVE.
Maybe the INACTIVE isn't really an idication of failed Auth?
app:17752024-08-30 11:49:52.691info ║ INACTIVE
app:17752024-08-30 10:49:52.761info ║ INACTIVE
What app is reporting it as INACTIVE? Since I do not have an app for any of my drivers, nor do I provide any logging structured like that... I am not sure where that comes from.
Download the Hubitat app
