Blink Binding - arm/disarm does not work

[MichaelEi (Michael Eichhardt)]

Continuing the discussion from [Blink Binding, 2026 5.1.0.0,6.0.0.0):

Firstly, many thanks for taking up the binding and implementing the new authentication method and all other functions. The binding (5.1 and the new one) connected to blink without any issues (2FA required & working). Cameras identified via Scan and main readings (thumbnail, battery, temp) working.

What I cannot get to work is arming and disarming motion detection. Changes to switches on cameras are not reflected in blink app. Change on main arm/disarm is reflected in app (after a while). But untortunately it seems to confuse the system. After disabling and enabling the system does not respond to motions. I could not figure out a deterministic way to get it working again, but after flicking the status in the app it eventually worked again.

Question:

1. Is arming / disarming working reliably for anyone else?
2. Any idea, what details I could provide tom help tracking down the root cause?

Background: I’d love to arm/disarm from openHAB. I use one camera as a “cat bell” to see if our cat approaches the terrace dorr and wants to get in. When stepping out at night, I want to use a switch to disable motion detection for a few minutes to prevent false alarms.

Many thanks for your support

Regards,
Michael

[dashrb (Robert Brown (-rb))]

Hi @MichaelEi, you’re welcome! Let’s see if we can get you up and running.

I have tested the camera’s motiondetection On/Off, and the sync module Armed On/Off switches and they seem to work for me.
Let’s make sure we’re on the same page in terms of words. Don’t be offended–I want to make sure we’re on the same page, and any future readers will understand too.

Each camera has a channel called motiondetection which, when linked to a new Item, will have a Switch type of item, and thus have a simple On/Off mechanism. On means motion detection is enabled, and Off means it is disabled.

Each camera is connected to a sync module. A sync module can support 10 cameras. Each sync module can be Armed with a similar On/Off switch. The sync module Thing has a single channel called Armed, and you’ll want to link it to a new Item as well. Many people only have one sync module, and if so, you may consider this to be the “main arm/disarm” switch. I personally have 5 sync modules (eye-roll at myself), although one is called Temp and I just use it for testing.

Blink’s behavior: Both the sync module must be Armed/On, AND also the camera must be motiondetection/On in order for the motion detection to “work”. I assume the logic is that some people want to have some cameras enabled (e.g. outdoor?) while others are disabled (e.g. indoor?), but also have a big master switch that allows a comprehensive disarming. While allowing you to rearm the “whole system” and it can remember which individual cameras were supposed to be Armed or Disarmed. These were Blink’s design decisions, so I’m speculating.

My observations, using the openhab web maintenance UI while I have the retail Blink app open on my phone so I can watch what happens there (not touching anything in the Blink app):

Starting conditions:

1. My camera is sitting on my office desk, about 2 feet from me, and it’s pointed to my right, so it doesn’t see motion unless I intentionally lean in front of the lens.
2. This happens to be a “gen 3 / Catalina” camera, which shouldn’t matter for this test, but it does have different settings within the blink app than the older/newer cameras.
3. My camera is currently not armed, so there is no “running man” icon on top of the camera thumbnail in the blink app. There is just a ... button in the lower right corner.
4. My sync module is Armed (the bottom of the Blink app Home Screen shows ARMED as highlighted)

Then I click on the openhab web UI as follows:

1. When I switch On the motiondetection for a camera, after about 3-5 seconds of delay, the blink app shows the “Running man” icon appear on top of the lower right corner of the thumbnail on the Home Screen.
2. When I put myself in front of the camera lens, the blue light illuminates on the front of the camera, to reflect that it’s recording me.
3. Soon after, the Blink app notification appears on my phone that motion was detected at my office camera. The recording appears in the blink app’s Clips page.
4. When I switch Off the motiondetection for the camera, after about 3-5 seconds of delay, the blink app takes away the “running man” icon from the home screen thumbnail for this camera.
5. For what it’s worth, the openhab.log shows these messages during the Off sequence:

22:20:59.788 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'CBOffice_Motion_Detection' received command OFF (source: org.openhab.ui=>org.openhab.core.io.rest$demoadmin)
22:20:59.788 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'CBOffice_Motion_Detection' predicted to become OFF
22:20:59.791 [DEBUG] [blink.internal.handler.CameraHandler] - Handling command motiondetection OFF for camera blink:camera:xxxxf4:xxx78
22:21:00.940 [DEBUG] [internal.service.BaseBlinkApiService] - Checking for status of async command 2488699944 (try 0)
22:21:01.011 [DEBUG] [internal.service.BaseBlinkApiService] - Command 2488699944 completed with message Command succeeded
22:21:01.011 [DEBUG] [link.internal.handler.AccountHandler] - Loading devices from Blink API
22:21:01.924 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CBOffice_Motion_Detection' changed from ON to OFF (source: org.openhab.core.thing$blink:camera:xxxxf4:xxx78:motiondetection)
22:21:02.012 [DEBUG] [link.internal.handler.AccountHandler] - Loading events from Blink API since 2026-02-11T03:18:38Z

Separately, when I arm or disarm the sync module itself, the log file shows lines like below. This is a disarm, followed 30 seconds later with an arm command:

22:23:55.547 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'CBSync_Module_Temp_Armed' received command OFF (source: org.openhab.ui=>org.openhab.core.io.rest$demoadmin)
22:23:55.547 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'CBSync_Module_Temp_Armed' predicted to become OFF
22:23:56.700 [DEBUG] [internal.service.BaseBlinkApiService] - Checking for status of async command 2488703446 (try 0)
22:23:57.763 [DEBUG] [internal.service.BaseBlinkApiService] - Checking for status of async command 2488703446 (try 1)
22:23:57.889 [DEBUG] [internal.service.BaseBlinkApiService] - Command 2488703446 completed with message Command succeeded
22:23:57.890 [DEBUG] [link.internal.handler.AccountHandler] - Loading devices from Blink API
22:23:58.475 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CBSync_Module_Temp_Armed' changed from ON to OFF (source: org.openhab.core.thing$blink:network:xxxxf4:xxx6:armed)
22:23:59.168 [DEBUG] [link.internal.handler.AccountHandler] - Loading events from Blink API since 2026-02-11T03:18:38Z
22:24:19.263 [DEBUG] [link.internal.handler.AccountHandler] - Loading devices from Blink API
22:24:20.341 [DEBUG] [link.internal.handler.AccountHandler] - Loading events from Blink API since 2026-02-11T03:18:38Z
22:24:34.244 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'CBSync_Module_Temp_Armed' received command ON (source: org.openhab.ui=>org.openhab.core.io.rest$demoadmin)
22:24:34.244 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'CBSync_Module_Temp_Armed' predicted to become ON
22:24:35.471 [DEBUG] [internal.service.BaseBlinkApiService] - Checking for status of async command 2488704122 (try 0)
22:24:36.528 [DEBUG] [internal.service.BaseBlinkApiService] - Checking for status of async command 2488704122 (try 1)
22:24:36.593 [DEBUG] [internal.service.BaseBlinkApiService] - Command 2488704122 completed with message Command succeeded
22:24:36.593 [DEBUG] [link.internal.handler.AccountHandler] - Loading devices from Blink API
22:24:37.165 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CBSync_Module_Temp_Armed' changed from OFF to ON (source: org.openhab.core.thing$blink:network:xxxxf4:xxx6:armed)
22:24:37.646 [DEBUG] [link.internal.handler.AccountHandler] - Loading events from Blink API since 2026-02-11T03:18:38Z

Other things I’ve observed:

1. Sometimes my cameras go into repeatedly triggering false alarms for non-existent motion. In order to stop it, I have to go into the Camera-DeviceSettings->Motion->Sensitivity down to 4, and then Save it. Then I can go back in and revert the sensitivity to level 5. This happens on more than one of my cameras but I haven’t yet correlated this crappy behavior to a specific generation of cameras, or daytime/nighttime, etc. Mostly I just haven’t researched it, just been annoyed and moved on with life. This has nothing to do with openhab and isn’t relevant to your situation.
2. It also seems like when my cameras are set to sensitivity 4 or lower, they never trigger no matter what. Not sure if I’m too close, or too far, or maybe I need to carry an IR flashlight to shine at the lens, or whatever. Just strange. I speculate that these sorts of cameras use fairly low cost / low performance IR detection logic.
3. I also use USB power for almost all of my cameras (as opposed to battery power). This doesn’t seem to change the motion detection performance (until the batteries get low, obviously).
4. One time I enabled my camera using openhab, and before the blink app showed the “running man”, the motion notification appeared on the phone. (I was using 5 second recordings in order to shorten my testing time). So I’m confident that the motion detection setting is honored nearly right away, even if the blink app doesn’t reflect it yet.

Sorry for so much detail, but hopefully we can figure out what’s going on with yours.

[MichaelEi (Michael Eichhardt)]

Hi @dashrb, many thanks for your detailed answer. Very much appreciated. I think we are on the same page. You perfectly summarized my understanding. I am trying to eliminate any setup issues and have uninstalled the binding, upgraded to latest stable release 5.1.2 and after stabilizing the first startup, manually installed the latest binding:

356 │ Active │ 80 │ 5.2.0.202602072213 │ openHAB Add-ons :: Bundles :: blink Binding

The things (1 SyncModule, 2 cameras Gen4 sedona) immediately came online.

Checking camera thing properties. First observation: Power Source for both cameras is shown as USB Power even though they are on batteries. All other properties seem to be reasonable.

Setting binding to Debug - failed with exception java.lang.RuntimeException: Unable to set level for logger. Hmm, the same happened with other bindings. I recall that this is a known issue with the logger I read somewhere. I will sort that out later.

I am trying to replicate your setup: Opening blink app on mobile, setting test camera to disarmed and system to armed. After a short while status is reflected in the corresponding items.

Note: I must admit that network connection from Camera to Sync Module is poor from my desk. However initial tests worked perfectly fine.

1. Switching motiondetection of camera item to On. It takes at least 20secs for the running man to show green.
2. Singing and dancing in front of the camera does not trigger anything.
3. Setting Sync module to disarmed in the app takes +1min to reflect the change in the item. Though it worked at least…
4. Setting status to armed in app again takes another +1min to change the status of the item. However, that reset the camera status and motions are detected again.
5. I am now changing the status of the Sync module on the item to armed. The app shows the status change within less than 5secs. After a minute, the camera recognized motion and I got a notification on my mobile.
6. Now setting the sync module status to disarmed. It took care of 20secs for the status change to reflect in the app. Camera no longer responds to motion.
7. Repeating the same of #5. ca 5secs for the app to recognize the status change, after 45secs the camera reacted.
8. Repeating #6 with same result and similar similar timing.
9. Setting sync module to disarmed on app takes >60secs for the item to recognize.
10. tried other combinations …

Conclusion: arm/disarm seems to be working for me in general - that is a change to before. Might be that the fresh install of the binding helped improving the situation. It seems that there is a huge latency for the system to respond / adjust to status changes. It could be due to my setup (low network quality to Sync and probably between sync and camera) but it is not consistent with arm and disarm and also not consistent between changes on App or in openHAB (where I’d assume latency should not be a technical issue).

Even though the latency does not allow using the door switch to disarm when opening the door, but I can happily work around. Worst case I do get some other redundant clips on my SIM card. Who cares? I am not expecting from this cheap hardware any realtime responses or 100% reliability. I’d never consider those to be used as mission critical devices or a reliable home protection system. If that continues to work ok, I consider purchasing another one or two cameras for little money if on sale to take nice movie clips from animals in the garden. With the help of your binding I am closer to control those in an automated fashion. And the cat is happy, that she does not need to wait too long in front of the garden door…

Many thanks for your effort.

Regards, Michael

[dashrb (Robert Brown (-rb))]

Thanks @MichaelEi for the details!

On the latency issues:

• When we make a change in openhab, there is some latency “A” for the POST to reach Blink, probably not much but if your connection were spotty it could be slower (but still <1 second, if I had to guess). There is some latency “B” for the Blink app to reflect the change, completely under Blink’s control. I suspect Blink is using some sort of mobile app “push” technology to get the update from their servers to the Blink app. Could be iOS vs. android are different but I have no idea.
• When you make a change in the blink app, there is some latency “C” for their POST to reach Blink, and probably C is similar to A – very small. Then there is some latency “D” for the openhab Things/Items/Rules/etc to reflect the change. Since openhab can’t participate in the mobile app “push” technology, the Blink Binding needs to poll the blink servers periodically to ask if anything has changed. We suspect that if one were to try to poll every second, for example, that the Blink system administrators would eventually notice and get upset about the bandwidth (maybe even threaten us with bogus claims of Denial-of-Service “attacks” or something). We have no idea how often would be “too often”, or what the retaliation would be, if any. Maybe they would never notice, nor care.

That said, this latency “D” can be controlled in the openhab Blink Account Thing configuration, in the same area you would have put in your username and password. You can set this Refresh Interval to as quick as 30 seconds, because “we” arbitrarily decided 30 seconds was safe, but that polling more often would be risky. I could certainly be convinced to lower the bounds checking on this field to allow for very short periods. Anyway, this value will reduce the latency “D” above, which doesn’t change how Blink behaves, but it does change how fast openhab will display whatever Blink does. Anyway, this corresponds to the “+1 min” in your bullets 3 and 4.

The amount of time in bullet 5 depends on a number of factors. I don’t have a “hawk” but since it’s new-ish, it might behave like the gen3 or gen4 cameras. These are the settings in the iOS app which are relevant (not all of these settings are visible for older cameras). In the android app, I assume they are similar but possibly not identically worded.

1. Settings->MotionSettings->EarlyNotification (On or Off). If off, the app (and also, openhab) will not show a motion event until after the recording is completed and set to Blink.
2. Settings->VideoSettings->Motion Clip Length: If set to the max of 60 seconds, then it will record for 60 seconds and then it will “complete” the recording, upload it, and notify the app (and openhab will also be able to poll to discover the new recording event). So setting a shorter time here will speed up notification (but also reduce your recording duration, obviously).
3. Settings->VideoSettings->EndClipEarlyIfMotionStops (On / Off). This setting also does not exist for older cameras, but if On, the camera can terminate the recording as soon as you stop dancing (for example), and thus speed up notification (but also reduce your recording duration, obviously).

I’m going to look at the Battery vs. USB power thing.

Also, your output shows that you’re in the CLI or the ssh karaf console which means you can change debug levels like so: log:set TRACE org.openhab.binding.blink or use DEBUG, INFO, WARN, or ERROR instead of TRACE, for decreasing amounts of verbosity, respectively. Also log:get to show all of the levels you have set globally.

[dashrb (Robert Brown (-rb))]

You are correct: the “Power Source” property is not working as intended. I see the problem. I was interpreting a value incorrectly (based on coincidence in my cameras). However I found a different field, which is accurate, and tested my own cameras by swapping batteries for USB power and back and forth to verify that it reports properly (and updates automatically at the next refresh). Anyway, this will be working in the next release.

Side note: the doorbells currently show this property but should not. In the future, they will no longer show this property–they are always battery powered, and they don’t report the extra details that the full cameras do, so the ac_power field isn’t available (pedantically, ac_power is a misleading field name since USB power is still DC power, and you don’t technically know whether the USB cable is connected to an AC or DC power source, but I digress).

[dashrb (Robert Brown (-rb))]

I haven’t forgotten about the lack of functionality for those of you who don’t have a subscription to their cloud services, and are using a local storage device on a sync module. I’m still without a good way to test this configuration.