0.10.0 Beta 10

[blakeblackshear]

Major Changes for 0.10.0

Updated docs are available for preview here.

Changes since beta 9

• Publish mqtt updates to events topic on position changes, when an object becomes stationary, and at least once per minute
• Make stationary_threshold configurable so you can adjust how many frames are required to determine an object is stationary
• In progress events are now listed in the recordings viewer
• Playback rate is retained in recordings viewer
• In progress events can now be downloaded

BREAKING CHANGES

Camera Names

Camera names in the config file must be URL safe starting with this version. Only A-Z, a-z, 0-9, -, and _ are permitted. If your cameras need to be renamed, any associated events will be retained based on your global retain settings, not the new camera name settings. If you want to retain recordings from the previous camera name, you need to ensure you have retain days set globally. For example:

record: #  <---------- global setting
  retain:
    days: 7 # <------- will retain 7 days of recordings for old cameras

Retain modes

This release adds the ability to define retain modes for the initial retention period and for event data beyond the initial retain period. There are three modes:

• all: retain all recording segments. This is consistent with the previous behavior
• motion: retain only the recording segments that have some motion
• active_objects: retain only the recording segments that have a moving true positive object that is being tracked

The default record settings will retain only segments that have motion for events.

Note that the retain_days config entry has been DEPRECATED. This release includes backwards compatibility, but you should migrate to the new format.

Example: Store all segments with motion for 7 days and events with active objects for 14 days.

record:
  enabled: True
  retain:
    days: 7
    mode: motion
  events:
    retain:
      default: 14
      mode: active_objects

Stationary objects

Frigate will now continue to track objects after they are stationary. This enables use cases such as presence detection. After an object has been stationary for 10 frames, object detection for the object will be paused (the new stationary_interval setting allows periodic checks too) until there is new movement. An object is determined to be stationary if the bounding box in the current frame overlaps almost entirely with the previous 10 frames. I have been testing this in my home office, and it works quite well.

I expect this to disrupt the way a few people are using Frigate. For example, a car that enters the driveway, parks, and then leaves 5 hours later will be one continuous event. The zones will stay with the tracked object over this lifetime, so when the car leaves, it will still have zones associated from when it first arrived. Ensure you use the right retain mode to ensure you only capture the segments you want.

Depending on the specifics of your room, you may need to tune your resolution and motion settings to get the results you want. In my office, I reduced the resolution to 640x360 and increased the contour_area setting for motion detection up to 125 to reduce the sensitivity. I recommend watching the debug view and adjusting as needed.

fixes #841

In progress events and cache handling

Events are now stored in the database while in progress, so you can expect to see In progress for some events under end time in the Events view.

Recording segments written to the cache are now only moved to the recordings folder if they overlap with an event (in-progress events too). For those with retain_days set to 0, this eliminates disk I/O when there are no events. Frigate will no longer store a minimum of 5 minutes of recording segments for each camera, so now you can enable recording without worrying about SD/SSD wear.

Lastly, more proactive cache maintenance was implemented to prevent the cache disk from filling up. You should never see more than 7 segments in the cache for each camera. If the cache maintenance job is too slow, you will get a warning in the logs. You can also see the time it takes to copy to the recordings disk by setting frigate.record: debug in the logger config. Additional error handling was also implemented to prevent the cache maintenance thread from stopping on errors.

Now that recordings are managed proactively, recordings are expired according to the retention settings at the interval set in the expire_interval setting (defaults to once per hour).

fixes #1885

Motion detection improvements

0.9.0 introduced dynamic motion sensitivity which didn't work out well. For many users, this made motion detection too sensitive which increased CPU usage due to more motion causing more object detection. It also increased false positive detections due to the increased frequency for detections on areas without substantial motion.

In this release, motion detection has been reset back to better defaults for frame_height and contour_area. If you have customized either frame_height or contour_area in the past, it is recommended that you remove those for your camera and let them revert back to the new defaults. For most users, the sensitivity can be tuned by adjusting contour_area (smaller numbers are more sensitive and larger numbers are less sensitive). For very high resolutions with very small objects, the frame_height may need to be increased.

In addition, this release brings about dynamic contrast adjustment for motion detection. Based on my testing, this substantially improves night time detection with IR lights and other low contrast situations.

Other changes

• Improved logic for merging motion, bounding boxes, and regions
• Report coral temperature stats when available (USB Coral not supported)
• Limit the cache time for playlist urls to avoid recording playback failures
• Allow yaml extension in addition to yml
• Sync database recordings with the disk on startup
• Store motion and objects data in database
• Entered zones in mqtt messages are now sorted based on the order the object entered zones
• Frigate now scans for objects in the frame on startup
• Detected objects that never move no longer generate events or snapshots
• Make recording expiration interval configurable (previously hard coded to 60 minutes)
• New event datepicker in the events viewer
• Require camera names to be url safe
• Ensure clean snapshots are deleted when deleting events
• Fix bug when last recording in the database does not exist on disk
• Randomize the region slightly to try and reduce lost true positives
• Allow recording motion even when detect is disabled
• Add stacktrace to config errors
• Tweak error messages when ffmpeg fails
• Update has_clip to false when an event fails to play
• Handle rare divide by zero in fps calculation

Fixes

• fixes [Support]: Recording breaks if disabled by MQTT on Frigate start #2129
• fixes Make wait_time for recording cleanup configurable #2734

Full Changelog: v0.9.4...v0.10.0-beta10

Images:

• x86: blakeblackshear/frigate:0.10.0-beta10-amd64
• x86 w/ nvidia (for ffmpeg only): blakeblackshear/frigate:0.10.0-beta10-amd64nvidia
• Raspberry Pi 3/4 (32bit): blakeblackshear/frigate:0.10.0-beta10-armv7
• Raspberry Pi 4 (64bit): blakeblackshear/frigate:0.10.0-beta10-aarch64

[ozett]

i have 14 cams, which one of them has the wrong name for beta7 ?
how do i identify the config-line for this error?

frigate    | 1 validation error for CameraConfig
frigate    | name
frigate    |   string does not match regex "^[a-zA-Z0-9_]+$" (type=value_error.str.regex; pattern=^[a-zA-Z0-9_]+$)

edit:
that change brakes all my existing mqtt-flows, as they are based all on the cam-names...

edit: i changed all dashes... running fine as before. your work is really great, thanks

[blakeblackshear]

I added - to the allowed characters for beta 8. Sorry for the oversight.

[Daniel-dev22]

I don't see an update available for the beta should I uninstall and reinstall the beta addon?

[Daniel-dev22]

i pulled the new docker image, as frigate runs for me in docker

Sounds good I'll just delete and re-install and see if it's the new one when I start it. Excited to test the static object detection improvements.

Edit: Uninstalling and reinstalling didn't work it's still beta 6.

From the debug menu this is the version: 0.10.0-DB1255A

[blakeblackshear]

I haven't pushed the addon update yet.

[Daniel-dev22]

No problem any idea when it will get pushed?

[blakeblackshear]

Just pushed.

[Daniel-dev22]

Just pushed.

That's odd I still don't see it and I tried reloading the supervisor.

Edit: It's there now.

[blakeblackshear]

Yea... I will look at adding more characters so less camera names need to change. That may have been a bit too restrictive.

[blakeblackshear]

I pushed beta 8 after adding - to the regex.

[Daniel-dev22]

So far it appears to be detecting static objects much better than the last version.

Is it possible when static objects are detected the motion sensor clears rather than stays detected as I use that for my trigger to trigger blue Iris.

Although I know I could also probably use the mqtt event I just don't know how I would use the mqtt trigger for when the event starts and ends for a camera in an automation so that I could have the same functionality to tell blue iris when to start and stop recording.

[blakeblackshear]

I am fairly certain I just found a bug with the active_objects retain mode. I think it has been only retaining segments without any active objects up until this point. I inverted the logic and I am testing.

[NickM-27]

Just wanted to share that stationary objects has been working great this beta! My car in the driveway (that is only half visible) was detected when I got home 2 hours ago and it has not been lost once.

[Daniel-dev22]

I have a few more changes for beta 9 and then I can get a release candidate out in a few days so we can move on to 0.11.0.

I have noticed no issues as well and I'm super excited for custom models whenever that will be ready.

[blakeblackshear]

I really hope it lives up to everyone's expectations. 😅

[Daniel-dev22]

I really hope it lives up to everyone's expectations. 😅

Anything that's faster and more accurate than the current models is a +. Not that there anything wrong with the current models but an improvement is always a +

[pcb1962]

hmm, I'm finding the opposite, in the past hour I've had 4 notifications for my neighbor's car (through the bushes!) which hasn't moved.
I think I can fix this by setting a minimum size for car, but it's odd that it didn't do this in beta 6.

[blakeblackshear]

This is probably because it scores very low and keeps getting lost. This may be a good situation for an object filter mask if you never want to detect cars in your neighbors driveway.

[blakeblackshear]

I just pushed beta 9. Hopefully this is the final beta before the release candidate.

[tungmeister]

@blakeblackshear I've just updated to the 0.10 releases however now I'm getting detections that are marked as in a zone that they're clearly outside of:
here's a screenshot of the zone /mask config for the camera in question:

and an example snapshot - showing as in the zone "Everywhere"

and one of a person:

The "everywhere" zone definintion:

and the zone config, stating that cars shouldn't even trigger in the everywhere zone regardless:

    zones:
      entrance:
#4k        coordinates: 1992,642,2997,835,2941,602,2953,284,2355,209,2323,437
        coordinates: 1519,408,1094,301,1151,242,1158,132,1483,164,1481,302
        objects:
          - car
      everywhere:
#4k        coordinates: 2350,217,2365,461,2942,631,2949,0,3840,543,3840,2160,0,2160,0,0,1040,0,1055,331,1158,299,1142,173
        coordinates: 1920,0,1920,1080,0,1080,0,0,524,168,555,157,554,101,600,94,814,101,992,89,1177,115,1179,239,1480,297,1491,25
        objects:
          - person
          - cat

any suggestions?

[NickM-27]

Hmm, I agree that doesn't make a lot of sense. It seems like it happens fairly often so watching the debug stream with zones and bounding boxes on should show pretty quickly how the bounding box is being formed to somehow get into the orange zone.

Another option might be add an object mask for car in that other parking lot. That is a bit around the issue, however it could be a good solution if you don't want to spend resources tracking those cars, it looks like they have to go out of frame to get to your driveway anyway.

[blakeblackshear]

I've overcompensated for the location now being defined as the lower center of the bounding box

@tungmeister To clarify, presence in a zone has always been based on the bottom center of the bounding box. That is not new for this version.

[tungmeister]

I've overcompensated for the location now being defined as the lower center of the bounding box

@tungmeister To clarify, presence in a zone has always been based on the bottom center of the bounding box. That is not new for this version.

I can only imagine that improved detection is causing these detections then if that's the case as I wasn't getting the "false" positives before updating to 0.10.

[blakeblackshear]

That's my guess. There must be a single frame where the object is in that zone. I have seen situations where a group of objects get detected as one, so that could be happening.

[blakeblackshear]

Any car driving by on the street would definitely be in the entrance zone. The snapshot you see obviously isn't the frame where it was in the zone.

[hunterjm]

I see that since beta 7 stationary objects no longer send events or take snapshots. Is it possible to put this behind a config flag? I would like to update the blueprint to handle stationary objects, but without an update event letting me know how many frames it has been stationary for that is difficult to do. After adding stationary_interval I do see that updates are provided for the same event on significant bounding box changes, but looking at the debug screen along with the events, it looks like it is also incrementing position_changes from time to time when there are no motion boxes and the car hasn't moved, so I see why you turned off the periodic detect scan by default, as if there is no motion there should be no reason to scan and potentially mess up the IOU.

Having a periodic (possibly configurable) update interval for tracked objects would be useful for things like loitering notifications:

"Is there a car parked in front of my house on the street for more than 15 minutes?"
"Is the same person loitering for an extended period of time?"

When new motion is detected, I do notice that it does send update events, but the number of position changes doesn't really add up, so it is impossible to calculate how long an object is in one position and for how long, because it skips them in the events. The example below goes from 9 changes with 1 frame motionless to 17 changes with 94 frames motionless. What happened in positions 10-16?

{
    "before": {
        "id": "1644299063.508683-eoqeml",
        "camera": "garage",
        "frame_time": 1644299069.248259,
        "snapshot_time": 1644299064.261453,
        "label": "person",
        "top_score": 0.90234375,
        "false_positive": false,
        "start_time": 1644299063.508683,
        "end_time": null,
        "score": 0.7265625,
        "box": [
            404,
            124,
            515,
            462
        ],
        "area": 37518,
        "region": [
            65,
            0,
            1645,
            1580
        ],
        "motionless_count": 1,
        "position_changes": 9,
        "current_zones": [],
        "entered_zones": [],
        "has_clip": true,
        "has_snapshot": true
    },
    "after": {
        "id": "1644299063.508683-eoqeml",
        "camera": "garage",
        "frame_time": 1644299117.150873,
        "snapshot_time": 1644299117.150873,
        "label": "person",
        "top_score": 0.90234375,
        "false_positive": false,
        "start_time": 1644299063.508683,
        "end_time": null,
        "score": 0.953125,
        "box": [
            340,
            141,
            478,
            505
        ],
        "area": 50232,
        "region": [
            75,
            11,
            679,
            615
        ],
        "motionless_count": 94,
        "position_changes": 17,
        "current_zones": [],
        "entered_zones": [],
        "has_clip": true,
        "has_snapshot": true
    },
    "type": "update"
}

Perhaps position changes is getting incremented while the object is moving? Or is it simply the old "better thumbnail/score" logic? If that is the case it is fine, but we are still missing the information on how long they were in the same position previous to moving in some cases like below:

{
    "before": {
        "id": "1644299063.508683-eoqeml",
        "camera": "garage",
        "frame_time": 1644299157.206871,
        "snapshot_time": 1644299157.206871,
        "label": "person",
        "top_score": 0.93359375,
        "false_positive": false,
        "start_time": 1644299063.508683,
        "end_time": null,
        "score": 0.7578125,
        "box": [
            1445,
            334,
            1640,
            831
        ],
        "area": 96915,
        "region": [
            328,
            0,
            1920,
            1592
        ],
        "motionless_count": 1,
        "position_changes": 36,
        "current_zones": [],
        "entered_zones": [],
        "has_clip": true,
        "has_snapshot": true
    },
    "after": {
        "id": "1644299063.508683-eoqeml",
        "camera": "garage",
        "frame_time": 1644299159.681251,
        "snapshot_time": 1644299159.17768,
        "label": "person",
        "top_score": 0.93359375,
        "false_positive": false,
        "start_time": 1644299063.508683,
        "end_time": null,
        "score": 0.7421875,
        "box": [
            748,
            847,
            1136,
            1081
        ],
        "area": 90792,
        "region": [
            483,
            0,
            1887,
            1404
        ],
        "motionless_count": 0,
        "position_changes": 41,
        "current_zones": [],
        "entered_zones": [],
        "has_clip": true,
        "has_snapshot": true
    },
    "type": "update"
}

I'll see if I can find some time to dig in to this new feature and contribute, but in my mind I would like to see update events for tracked objects under the following conditions:

1. A new "better" thumbnail or snapshot is available for objects in motion.
2. A tracked object has become stationary (IMO this threshold should be configurable as well, 10 frames? 20? 30?).
3. Periodic status updates on entirely stationary tracked objects (every 30-60 seconds? configurable?)
4. Update when a stationary object begins to move again letting us know how many frames it was in it's previous location.

[hunterjm]

Perhaps 2-4 warrant a new event type? update is currently reserved for "zone changes" and "better thumbnail". For notification purposes I don't want to overwrite a push notification constantly if a new thumbnail isn't available. Perhaps tracking?

[NickM-27]

The change can be undone and is also configurable by changing the stationary_interval under detect to be a nonzero number https://deploy-preview-1927--frigate-docs.netlify.app/configuration/index

[blakeblackshear]

You would come in here with some great ideas right as I am looking to put out a release candidate. /s

Yes, position changes do occur while an object is moving unless they move too quickly to hit 10 consecutive frames with IoU > .6. Once there are 10 frames combined to determine a "position" it no longer incorporates new bounding boxes and it stops adjusting. Using 10 frames allows objects with inconsistent bounding boxes (car that is partially obstructed) to still become stationary, which was an issue in the previous betas. The position becomes fixed after 10 frames because otherwise slow enough moving objects would still be considered stationary even if they moved a long distance.

I think it makes the most sense to just add some additional conditions for when an mqtt message is published:

1. position_changes values change
2. motionless_count crosses the threshold to be considered stationary

I can make the motionless_count threshold configurable too. Periodic updates can be accomplished by making sure the best_image_timeout still applies to stationary objects as it probably should anyway. That will get you at least one update per minute.

You can compare the snapshot_time in the before/after to determine if there is an updated image and only notify then. Also note that in progress events are now stored in the database too, so you have the option of pulling event data from the API if/when that makes more sense. That may make the blueprint too complicated.

I think these changes would address all your use cases.

[hunterjm]

Thanks for the quick response @blakeblackshear. I agree that the proposed changes should cover my use cases.

[tbrausch]

Just a minor suggestion. I really like the ability to record only on motion. It saves a lot of space and time when going back to look through the recordings. Normally I would like to go into the Frigate UI, select the camera, select recordings and start day/time, and then fast forward through the recordings. However, after I select 4x or 8x speed, it is reset back to 1x when the individual motion recording is complete.

[bm55]

I saw it on the 0.10.0 Beta 9 document so assumed it was release. I was using Beta 6 and just updated to Beta 9

[NickM-27]

The discussion doesn't mention it. Also beta 9 came out two days ago and the commit was made yesterday: 0b02f20

[bm55]

no worries. it's not a big deal.

[hunterjm]

There is a draft for Beta 10 up that hasn’t been released yet. It’s possible the docs update went out prematurely.

[tbrausch]

Much better with the new beta version, however, the playback speed still drops back to 1x when you are viewing recordings and you go past an hour mark. In other words, if I record all motion and start playback at 9:00 AM (at 8x speed) when the video reaches 10:00 AM the player defaults back to 1x speed.

[blakeblackshear]

Beta 10 was just pushed.

[hunterjm]

Side note as well, I added the ability to run custom models some time in 0.9.x. I've found the EfficientDet-Lite models to detect less false positives even though it has a lower mAP, but the trade off is much higher inference time so depending on the number of cameras you are running it may be worth looking at. With 0.10 I moved to EfficientDet-Lite2 as I was getting false positives of stationary objects with around the same scores as true detections that would now hang around for a while.

[NickM-27]

@elgorro If it is detecting it then in-progress makes sense. The error trace you put above has to do with the camera stream, I see it with my wyze cam as well and it doesn't affect the object detection or anything. So basically, seems the main issue you are seeing is a false positive on person. If it is in the place you could add a small object mask for person on the bottom center of the bounding box so that it will not be detected in the future.

[elgorro]

Excellent guys - thanks for clarifying.

[hunterjm]

If it is in the place you could add a small object mask for person on the bottom center of the bounding box so that it will not be detected in the future.

This would work too, but I'm too lazy to continually edit zones and filters 😛

[NickM-27]

If it is in the place you could add a small object mask for person on the bottom center of the bounding box so that it will not be detected in the future.

This would work too, but I'm too lazy to continually edit zones and filters 😛

Yeah I mainly just use zones as with my cameras I pretty much only have some false positives at night when the camera is running with IR.

[hunterjm]

For those on this thread that use my notification blueprint, I have updated it for 0.10 and could use some help testing, especially for those of you use use the zone filters and/or are Android users. You can import it below and try it out yourself.

⛔ Requirements

• Frigate: 0.10 Beta 10+
• Home Assistant: 2022.2+
• Frigate Integration: v2.2.0+
• iOS 15.0+ or Android with the latest Home Assistant Mobile App installed

🚀 Features

• Optionally send the notification as a critical alert (potentially faster delivery on android, noise maker on iOS)
• Choose whether or not to update the notification when a better thumbnail becomes available.
• Set a loitering timer to notify you of stationary objects that remain for a set period of time.

🐞 Bugfixes

• The old blueprint ran in single mode and only tracked a single object. With stationary objects in frame this means you were probably missing notifications. This version will send a notification for every tracked object. When they are stationary and start moving again it will send another notification.

📄 Reporting Issues

Please reply to this post so we can keep everything in one place.

⬇️ Import

[NickM-27]

@hunterjm My bad, I think I had something wrong, seems to be working as expected now.

[NickM-27]

@hunterjm okay so I'm seeing weird behavior with labels / zones. I have a street zone where I have a min_area filter of 18000 (only for delivery trucks) but I am getting notifications for every car that drives by. I also have another automation for just people / cars in the driveway but am getting notifications for cars that drive by in the street there as well. Both are setup to filter by zone. When I check the event in home assistant it appears to not have a zone associated with it.

Edit: it seems to happen after a legit event occurs. So perhaps it's happening in the loitering loop which doesn't filter those events?

[hunterjm]

Correct, no notification was sent for the initial "new" event. The second loop is not just for loitering, but also to handle any updates where it enters zones that should be triggered. If you open the trace on desktop (for easier reading) and click on the first "choose" inside the loop (the fork icon), then look at the right. you should see all iterations of the loop at the top and what choice (if any) was made. Find an iteration that has "Choice: 0" under it, then in the bottom right section switch over to "Changed Variables" and look at the event data and flags that were set during that iteration. I can not help debug without that information.

Edit: better yet, you can download the trace data from the top right and upload it here. It shouldn't contain any sensitive information.

[NickM-27]

@hunterjm Gotcha, here is the trace data for a run where this occurred. If it doesn't have what you need let me know

trace automation.outside_driveway_front_yard_notifications_frigate_event 2022-02-12T14_13_08.288037+00_00.zip
,

[hunterjm]

Sorry for not getting back on this yet. Family vacation at Disney World until Sunday. Will try to look at it next week.

[Firerouge]

I seem to sometimes have binary sensors in home assistant that aren't getting marked clear when frigate ends an event, not exactly sure when this was introduced but running beta 10 on 2022.2.5 right now.

Possibly also being marked clear while they should still be detected, note how at 7:55:57 it went from clear to detected in home assistant but frigate had a person event going from 7:52:53 till 7:56:18

This detection persisted through one additional one minute event around 8:30, but otherwise on an empty hallway, until I manually toggled detect (you have to wait!) on the camera under the frigate ui around 9:17.

Upon further review, frigate seems to have spontaneously (without a prior in progress) created a new event after the detect was toggled.
Start time 7:55:05 slotted between the last event in the picture and the 8:30 event, going till 9:17. It's got a clip, which is one minute and 23 seconds, it includes 7:55:11 till 7:55:21, where it jumps forward to 7:55:31 going till 7:56:21 (accurately longer than the previous hallway clip which oddly cut short) then jumps once more and includes the entirety of the 8:30 event.

[hunterjm]

Yes I know, it's just a example. But it would be nicer to have them (cars. ..) 'recorgnized' as stationary objects all the time and if they move record it. A nice benefit would be to have the base for feauture item-tracking I guess.

What you describe is how it works already... unless I misunderstand you. You can also set record mode to active_objects for only moving objects.

[Firerouge]

Sorry @blakeblackshear, I believe I've recreated the containers since posting this, and likely lack any additional logging for this specific occurrence. I do however still have the home assistant statistics, which shows the camera maintaining it's process fps but dropping to zero detect fps for a large portion of that 7:50-9:15 timeframe.

If I observe another good example I'll make sure to include text logs.

My areas are usually occupied by more than one person at a time, and I'm often getting overlapping clips because of that. While this would be ideal if I wanted to run a pipeline on each person snapshot (double-take) I don't really care about the individual people or amount of them, but simply if an area is occupied or not. Are there any recommended settings for high traffic areas to decrease the amount of overlapping events, I'd prefer to have simply one at the start and end of a camera being occupied.

[blakeblackshear]

You probably had a stationary false positive at that time. Events are strictly based on each tracked object, so there isn't a way to consolidate. Recordings are only stored once. Future versions of the frontend will look more like a timeline viewer with an event data overlay, so I don't think it will matter then.

[hunterjm]

You can also view the events in the Recording UI which already automatically combines overlapping events in the timeline.

[elgorro]

What you describe is how it works already... unless I misunderstand you. You can also set record mode to active_objects for only moving objects.

I have. Also I've positive false and false positive - mainly in events. Just saying try with poster or painting in your setup and see what your code does. If it's intended in this stage (version) to act like this, then I know now that more tweaking/testing would help in my setup. Thanks for helping understand and glad for your nice progressing.

[pcb1962]

Sorry if I missed an announcement somewhere, is there no 32 bit Pi build for Beta 10?

[blakeblackshear]

I can probably get it to build for 0.10.0. If it requires no unique modifications I will consider it for 0.11.0, but it probably won't be supported in that version.

[blakeblackshear]

Beta 11 has a 32bit build.

[pcb1962]

@pcb1962 Is there a good reason you still run the 32bit Pi build?

I'm also running HA Core in a venv, together with a MariaDB and a few other apps on 32 bit Raspbian so I don't want to migrate that machine. As soon as I can get hold of another Pi 4 I will move Frigate onto 64 bit Pi OS. About to install Beta 11 now, thank you.

[Firerouge]

Just fyi, 64 bit pi OS has been released for a long time, but only recently was released out of beta @joe248. I've been running 64 bit on a pi 4 since March 4th 2021 with no significant issues (other than mmal support sometimes having bugs).

[joe248]

@Firerouge thanks for the info! I ordered a new SD card so I can give it a try.

[blakeblackshear]

Here is my stationary tracking test setup.

[blakeblackshear]

Beta 11 is now available.

[ozett]

to trigger light outside seems to depend on night detection for person.
maybe hard without any light, or doing wrong with IR-Light?

but what cams do well inside? person-detection at night, in dark-rooms , to switch on lights?
or with the help of IR-Light inside? no problem for detection?

My kitchen, living room, a long area in the dining room with 3 zones for 3 different light groups. Multiple cameras controlling 1 light group from different angles. It has been working really well and extremely impressive I can turn the lights off within 5 seconds of someone leaving

is there a special consideration necessary for zone-design to reach this goal? may this needs a own discussion ..

[NickM-27]

I haven't had any issues with night detection issues. My doorbell works well with night vision. It is one of those things you just got to try and adjust the setup to optimize it for your use case.

[ozett]

yeah, this all started me thinking about light-switching based on cams (inside and outside).
may i give my frontdoorcam a try. i get 360° view and also partial views. should make something out of it..

[Daniel-dev22]

to trigger light outside seems to depend on night detection for person. maybe hard without any light, or doing wrong with IR-Light?

but what cams do well inside? person-detection at night, in dark-rooms , to switch on lights? or with the help of IR-Light inside? no problem for detection?

My kitchen, living room, a long area in the dining room with 3 zones for 3 different light groups. Multiple cameras controlling 1 light group from different angles. It has been working really well and extremely impressive I can turn the lights off within 5 seconds of someone leaving

is there a special consideration necessary for zone-design to reach this goal? may this needs a own discussion ..

I am running a mixture of amcrest ip3m-941s both wired and wireless and ip4m-1051s. Sadly both were discontinued. I liked them for their 5ghz capability besides picture quality and I just got them a few months ago before they completely fell off the earth. I didn't know their night vision would be as good as it is until I got them. Frigate can see objects in the complete darkness with the aid of their ir lights. They are so bright I can see ir on the floor from another around the corner.

It just depends on your layout as far as zones go. Whether or not it's possible to distinguish zones based off the cameras location, the distance etc. This camera with 3 zones is high enough up that i can distinguish 3 zones it's straight ahead from the camera but high enough up about 9ft that it has no issue knowing which zone a person is in. Depending on location it's likely not going to be possible to do more than 1. For example I have a doorway where I needed to use 2 cameras to cover the area as the doorway opens to left side kitchen and right side the living room. Instead I have 1 for the kitchen and 1 in the living room angled in such a way that the only way it would see you is if you're in the living room. This is the one that actually "stopped" detecting (binary sensor cleared) for more than 15 seconds but the person still had a bounding box around them the entire time. So far I haven't noticed it happen again.

It detects people very well even if standing/sitting still for a long period in addition to moving of course. I prefer this over motion sensors as cameras are dual purpose. Security + presence detection. Additionally not sure how your sensors work but the ability to turn the lights off 5 seconds after a person leaves is pretty cool to me at least lol. There's no need for waiting periods before it clears as with traditional motion sensors that can't actually see people that aren't moving.

I'd suggest getting a camera and just testing it. For example I just adjusted the camera in my kitchen yesterday to point further down to cover a Blindspot and I just got a ip2m-841 to cover another area.

[ozett]

thanks for encouraging me, i will make a plan and try out some things.
i just bought a "g3 instant" with wide-angle. looks good for this purpose.
this cam has some other drawbacks, but i have other spare cams, so i go now for this new idea.. thanks

edit: the binary-sensor (in HASS?) is trigged from mqtt-events, right? i have no HASS, but can make use of MQTT..