Blue Iris Long Delay with CodeProject Object Detection

[Vettester]

Have you tried adding your MQTT trigger to "Immediate {pre-altert) actions..." to see if that helps?

 

[curtis-r]

Have you tried adding your MQTT trigger to "Immediate {pre-altert) actions..." to see if that helps?

But then wouldn't that often be a false MQTT in the cases that AI doesn't confirm? Or are you just suggesting this as a test?

 

[Vettester]

Or are you just suggesting this as a test?

Just as a test to see if speeds up your MQTT times. If it does then then you know AI is the issue and you can work on decreasing your processing times.

 

[roymickton]

@curtis-r

Did you get anywhere with this? I have a similar setup to you and I am finding my AI confirmation is about 2 seconds after motion, but then MQTT publish can be another 27 seconds. I have my MQTT going off to my Home Assistant which in turn turns on my outside flood-light, but with such long delays it isn't doing what I want.

Are you running your BI on a Windows VM or bare-metal?

 

[roymickton]

Think I've just worked out what is going on here.......haha

When I actually stare at my logs, the MQTT publish happens with 500ms of AI detection. And then another MQTT comes to tell me the motion/AI has cleared.

I'm going to try set this up so logging doesn't group items together. I want a log of every separate event.

 

[roymickton]

Can't work out how to make the log show every event in a timeline.

However, if you save the logs to a .txt is shows the full timeline.....

3 12/04/2024 13:25:32.822 IPC1 Motion_A
0 12/04/2024 13:25:34.045 IPC1 AI: [ipcam-general] person:93% [996,727 1873,1298] 122ms
0 12/04/2024 13:25:34.040 IPC1 AI: person:93%
0 12/04/2024 13:25:34.275 IPC1 MQTT: Publish OK to BlueIris/IPC1/Status
3 12/04/2024 13:25:40.958 IPC2 Motion_A
0 12/04/2024 13:25:42.164 IPC2 AI: [ipcam-general] person:87% [148,421 1067,1027] 73ms
0 12/04/2024 13:25:42.178 IPC2 AI: person:87%
0 12/04/2024 13:25:42.508 IPC2 MQTT: Publish OK to BlueIris/IPC2/Status
3 12/04/2024 13:25:51.783 IPC1 Re-trigger: Motion_A
0 12/04/2024 13:25:52.898 IPC1 AI: [ipcam-general] person:94% [904,380 1573,904] 76ms
0 12/04/2024 13:25:52.803 IPC1 AI: person:94%
0 12/04/2024 13:25:53.035 IPC1 MQTT: Publish OK to BlueIris/IPC1/Status (this is the detector resetting after the break-point)
0 12/04/2024 13:26:13.008 IPC2 MQTT: Publish OK to BlueIris/IPC2/Status (this is the detector resetting after the break-point)
0 12/04/2024 13:26:17.546 IPC1 MQTT: Publish OK to BlueIris/IPC1/Status (this is the detector resetting after the break-point, as I caused a re-trigger)

 

[actran]

@roymickton Are you sending MQTT for "On Alert", and then another one for "On Reset"?

Just in case you did not know, the "On Reset" MQTT msg is not required if you configured your Home Assistant binary sensors like this:

 # MQTT
mqtt:
  binary_sensor:
   - name: "Person at Front Door"
      object_id: "person_at_front_door"
      state_topic: "Processed/person/Doorbell"
      value_template: "{{ value_json.state }}"
      json_attributes_topic: "Processed/person/Doorbell"
      off_delay: 15

Meaning, use "off_delay" config.

 

[roymickton]

@roymickton Are you sending MQTT for "On Alert", and then another one for "On Reset"?

Just in case you did not know, the "On Reset" MQTT msg is not required if you configured your Home Assistant binary sensors like this:

 # MQTT
mqtt:
  binary_sensor:
   - name: "Person at Front Door"
      object_id: "person_at_front_door"
      state_topic: "Processed/person/Doorbell"
      value_template: "{{ value_json.state }}"
      json_attributes_topic: "Processed/person/Doorbell"
      off_delay: 15

Meaning, use "off_delay" config.

I did not know that. I'll have to look into that.

 

[curtis-r]

If you don't have BI MQTT Reset and are monitoring MQTT outside of Home Assistant (such as MQTT Explorer), I suspect the initial alert would stay 'ON'. Of course this may not matter to anyone but probably safest to just have BI reset the MQTT to 'OFF'. But @actran I wasn't aware of the Home Assistant off_delay option, so that's good to know, but I also acquire the sensors through the BI Integration rather than manual yaml entries.

Just to provide an update to the issue that started this thread, I've gone down quite the rabbit hole, but unfortunately I can't say what solved at least my MQTT delay issue, but I CAN say that BI's GUI log is not accurate. For any debugging, one needs to use the .txt master log. Look at these two events. The GUI shows a delay of 12 seconds from the motion to MQTT. The proper log, less than 3 seconds, which is when Home Assistant received the MQTT.

 

[curtis-r]

SOLVED: Though there were a few moving parts to my issue, the main one that applies to this thread is that my two Reolink RLC-811A camera's sub-stream timeclock would drift over time, to the point where Blue Iris would receive that stream 10+ seconds after the event, thus leading to a significant delay when it gets to the MQTT.

Blue Iris support was amazing! They explained how Reolinks are notorious for this, but Reolink support would likely provide a 'beta' firmware that resolves this, which it did. But also Blue Iris support went to great lengths to help with some motion trigger issues and made improvements to the software as a result.

 

[looney2ns]

Reolinks should be avoided....period.

 

[curtis-r]

I hesitate to ask in fear of this thread and my head exploding from answers to such a generic and subjective question, but is there a sort-of consensus of quality, but not crazy-expensive, cams that plays very well with Blue Iris?

 

[looney2ns]

I hesitate to ask in fear of this thread and my head exploding from answers to such a generic and subjective question, but is there a sort-of consensus of quality, but not crazy-expensive, cams that plays very well with Blue Iris?

What are your goals with the cameras?
The Importance of Focal Length over MP in camera selection | IP Cam Talk

 

[wittaj]

+1 above! The cameras in that post I created represent the best overall value in terms of performance day and night and work well with BI.

You only buy consumer grade stuff you get at the store if all you care about is what time it happened.

If you want to be able to get clear pictures, start looking at Dahua OEM cameras. Our trusted vendor @EMPIRETECANDY has a sale coming up this week

The video quality examples shown here of Andy's $200ish cameras versus an Arlo $200ish cam or a Ring $200ish cam are no comparison. We are not exactly proposing Top Shelf Axis that costs 5-6 times other cameras - we are recommending cameras comparable in price to consumer favorites Ring and Arlo. Sure you can buy cheaper cameras, but when they shove 8MP on a sensor designed for 2MP, you will get poor results at night. For most of us, the perps are out at night and that is when we want good video.


Check out this thread on all the consumer grade junk (most of it wifi) that people have bought and look how poor the performance is. And don't think Reolink either LOL...

The Typical picture of a Perp on Nextdoor-type Apps with Consumer Grade Cameras like Ring, Nest, Arlo, Canary, Wyze, etc.



And in particular look at post #40 which is direct comparison between a better camera and the Ring that caught the same doorchecker on video in this neighborhood:

The Typical picture of a Perp on Nextdoor-type Apps with Consumer Grade Cameras like Ring, Nest, Arlo, Canary, Wyze, etc.

 

[curtis-r]

Very helpful links. Though I have 9 cams on my property, the one I'm most dependent on is at the street at our driveway. The critical footage would be 8'-25' and always involve motion, usually vehicles but also often people walking down our driveway.