Slow image sensor uploads at critical time

So today I had an interior image sensor indicate an alarm. The app says upload pending for the last 20 minutes…and still waiting. Kind of pointless to have the central station on hold while waiting for this to happen to decide whether or not to dispatch the police.

There were no corresponding other sensors or communication failures noted so it’s probably safe to let them go but here we are. 25 minutes in now and still upload pending.

The system is dual path so there shouldn’t be any issue uploading anything unless I’m missing something.

So an hour later and I see that the images are no longer pending upload; they reverted back and are just sitting there in my upload folder waiting for me to tell the app to upload.

I’m pretty sure that’s not how it’s supposed to work…

No, and an Alarm Image should automatically upload regardless. This definitely indicates some communication trouble. Speaking with ADC now.

Mind you that during this period I’m still receiving normal arm/disarm notices as well as sensor activity notices for open doors etc. so it’s not that the panel can’t talk to ADC as far as I can tell. I have a screen shot that I just took that clearly shows the alarm images in a pending upload state (after I kicked off the process again) and you can see the timestamp of the event as well as the current time an hour later.

And now it’s reverted back to doing nothing in the upload window. Another screenshot with timestamps obvious.

An update, the images finally loaded in the past minute. What I see though, besides the fact that nothing is wrong in the house (a good thing) is that there are only two images uploaded.

Unless I’m mistaken, aren’t there five images taken during alarm events? Also, are they supposed to be taken from all image sensors or just the one that alarmed?

They are only taken upon motion during Alarm. If no motion occurs, no images.

Looks like the panel acknowledged receipt immediately of the alarm upload request, but the actual upload was delayed.

Images are transmitted only across cellular. I’ve been told this is for security reasons.

The big question is how this signal got held up on its return, what I am looking into.

You should be able to see the images on your panel. Do you see a time stamp when the panel received the images? Was the breakdown perhaps between the sensor and the panel?

I’m not at home, so can’t see what the panel has for timestamps. As far as a breakdown between the sensor and the panel, the sensor that alarmed is 12 feet from the panel, unobstructed by anything. Also, obviously the alarm signal went right through instantly but of course I realize that there is a different set of radios used for the image from sensor to panel comms. It’s never malfunctioned before when I’ve requested peek-ins or uploaded background capture images so to have it fail in this instance is very troubling.

Delayed or slow cell issues also may explain a lot of what you have been seeing (from other threads)

Getting higher level engineers to look at this. Need to verify it wasn’t a local issue though (sensor to panel)

I’ll look once I’m home tonight. What exactly do you want me to take note of?

As a point of data, the last time I checked the cell signal strength it was 19 per the panel. This wasn’t recently though, definitely a few weeks ago at the earliest.

Alarm time as recorded by panel history and time of image capture at panel.


So this is rather disconcerting. I looked at the panel, it registered the alarm on the image sensor at 12:31 PM as indicated in the app above as well. The camera on the panel took at picture at the same time, so that confirms the initial alarm occurrence. However, the alarm images from the image sensor never uploaded to the panel at all. They’re just not there despite them being set to appear on the website under image sensor settings.

The only place I can see the images is in my uploaded gallery after I tried three times to forcefully upload them.

However, on the panel, I do see the subsequent entry of my girlfriend twice after that alarm event. So the panel is talking to the image sensors apparently without issue. The only glitch appears to surround the alarm images from the tripped image sensor.

Not good.

Ok, so in this circumstance, the panel failed to process the Alarm images of the IS. The images are however stored onboard the IS and you were able to manually upload them after much effort.

It doesn’t look like it would be a signal strength issue between the panel and the IS. Signal looks pretty good from what I see.

I’m going to upload the error/data log file from your panel to Qolsys for review.

Out of curiosity, how long is the power cable run for your IQ panel?

The power cord is about 4 feet. It’s running behind the panel, in the wall, to the outlet directly below the panel.

I checked the cell strength last night and it reported 4 bars, 17/31 and then 18/31 as I was watching it.

Signal strength should be irrelevant in this case. Just to clarify, the panel itself does not show the alarm image, correct? Have previous Alarm images been available?

The panel does not show the alarm images from the image sensors, no, just the post disarm images that happened some time after the alarm event.

I’m not sure that we’ve had any other alarm events since the image sensors were installed; certainly none caused by the image sensors themselves.

They reliably capture activity after disarming and work 100% for peek-ins too.

Would you be willing to test this out? You can place your account on test mode with the monitoring center, then trip and alarm and walk past the image sensors. We can test timing on image availability and panel viewing.

As a benchmark, you should be able to view IS images within around 3 minutes according to ADC. In my experience, you should actually expect to see them in half that time or less.

I can do that if you think it’s helpful. I want to see what Qolsys says from whatever you’ve given them though. I don’t know why an alarm condition would be different than any other image sensor action but clearly it is. Testing is fine but we already have a “live fire” test that should give you whatever you need to analyze this. I’m sure you can see the other images from peek-ins and background motion that work just fine too.

Recreating the scenario and forcing the panel to process the same type and amount of incoming and outgoing data and seeing those results (whether it works perfectly this time or performs the same) tells us a lot more than an image peek in.