-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Frigate reports incorrect occupancy in Home Assistant after restart #662
Comments
This is because the state is not retained which is not incorrect because otherwise you'd have the opposite problem - an object would show occupancy even if frigate wasn't running |
Sorry, maybe I'm not understanding. But Frigate is detecting an occupancy, the Add On says Clear. That is not the correct state.
That problem already exists in the current implementation. When frigate isn't running it is reporting Clear by default even if it's not actually clear. It's the opposite side of the coin, but still essentially the same issue. If Frigate isn't running, then I would expect the state should be Unavailable. I won't pretend to know what the solution is, but it is definitely reporting a state that is not the real, current state after a restart. When Home Assistant restarts, could Frigate re-send the current states to update the occupancy entities? |
To be clear I am saying retaining is not a solution because it would cause the other problem.
that would require frigate to be aware of home assistant and home assistant to communicate back to frigate which I am not sure is desirable. One solution might be to have an api in frigate that would send the current state for all objects. Then home assistant could call this api on startup to get its initial state. |
Yeah, that makes sense, I see what you mean now. I just implemented a workaround with an automation that triggers when Home Assistant starts. I have it publish an MQTT message to the frigate/restart topic. That works to newly detect all the objects and update the occupancy entities, but it takes extra time waiting for Frigate to start up. Not sure if there's an MQTT topic to request re-publishing of current states? If so, maybe that could automatically be published as part of the normal HACS Frigate Add On startup process so it stays in sync? And if there was a way to get the entities to show a state of Unavailable when Frigate isn't running, I think that would be ideal. I noticed the camera entities and sound levels already show Unavailable when Frigate is stopped. Maybe that could be extended to the occupancy entities, etc.? |
@NickM-27 I've been thinking about this some more, and am curious how all my other integrations maintain states after a restart. For example I have lots of sensors through zigbee2mqtt. When I restart home assistant my door sensors don't all default to reporting that they're open. My zwave locks don't default to reporting as unlocked. My Hue bulbs don't all default to showing an off state. Do other integrations retain messages? Or do they re-poll for states after restart? Are there plans for Frigate to do the same? |
Looks like zigbee2mqtt retains all their messages. Like I said I don't think that is a suitable solution for the way frigate works with mqtt. Object detection data is a lot more transient than the attributes of a zigbee device |
I see what you mean. Although, I will say that I am using object detection for things that are not transient, so it depends on the use case. Either way, I think occupancy sensors reporting accurate states after a restart would be a best practice. Is there a fix for this on the roadmap? |
There are a number of things that make the object count and occupancy sensors sub optimal currently. It will likely be rewritten and made better at some point, we are currently rewriting the frigate UI among many new features so I wouldn't expect this to be improved in 0.14 |
Understood. And thanks for being responsive and for all the work you do on this project - it's great stuff. I would definitely put my vote in for this to be moved up the priority list following the 0.14 release. These sensors get used in automations for many users and would love to see them fixed. |
@NickM-27 Thanks for an awesome 0.14 release! I wanted to check back on this issue. Is improving the way Frigate reports occupancy sensors so the state is accurate following a restart something that will be prioritized for the next major release? |
@soonerfan237 hey mate I'm definitely seeing this issue as well, thanks for raising it.
Mind sharing the automation/workaround for this? Would be good for myself/future travellers. |
@lucasteligioridis I changed the way I restart the add-on since I made that MQTT comment. Here's my current method. The automation triggers every time that Home Assistant starts. The action is "Home Assistant Supervisor: Restart add-on" with the Frigate add-on selected.
If you do want to use the MQTT method, here's the action section of the automation.
|
Thanks a heap @soonerfan237 |
Not sure if I can add this onto here or if I should open my own ticket but ever since 0.14 HA is falsely detecting occupancy in one of my zones while frigate does not have any events at the time stamps. Only at night it seems. We have our front doorbell camera set to go through our do not disturb if someone is at our front door...so 3+ false positives from HA with no video clips or recorded events is odd. I reviewed the footage at the timestamps in frigate. Looks like most of the timestamps was a car driving by on the road(it has been raining here so had some weird reflections. What I find odd is frigate did not even see this as a motion or detection event so I am not sure why HA thought is was worthy of an alert. |
@Nooton92 A couple days ago I got a notification that a person was detected in my house while I was away. My dog sometimes gets falsely detected as a person. So after I got home I went to send the false positive to Frigate+. But I never saw a detection/motion event in Frigate during that time. At the time, I figured it was just a random occurence, but now seeing your comment, there may be something more to it. Not sure how to reproduce it though. It could be that event thresholds set in yaml aren't being used the same in every part of the UI? If it happens again, I'll try to do some more digging. |
The occupancy sensors have less verification in order to be able to respond faster. This is working as expected. The /events or /reviews topic should be used for notifications |
@NickM-27 Interesting, didn't know that! Will switch to the /events topic going forward. Was this a recent change to occupancy sensors or has it always been like this? Can you expand the "less verification" comment? Is it bypassing threshold checks or something? |
No, this is how it has worked for quite a while |
Thanks! Is there documentation out there for what causes the occupancy sensors to be turned on? Or can you help me with an explanation? And follow up question - is the occupancy sensor behavior configurable? |
Good morning. I have also noticed that with the latest version of Frigate 0.14 and the version 5.3.0 of the integration, sometimes the "Occupancy Sensor" is activated but there is no recorded snapshot nor clip. With version 0.13 I had not experienced anything similar. Maybe it's just coincidence (?) but I see that other users report the same problem above. Inside the yard where the cameras are operating there is a big dog and sometimes Frigate recognizes him as a "person". But I don't have a snapshot to see exactly what has happened. |
There are a number of things that are different:
|
Version of the custom_component
5.1.0
Configuration
Describe the bug
The Frigate add on is not reporting the correct occupancy state after Home Assistant is restarted while an object is being tracked. For example, if Frigate is detecting a car in my garage, and then I restart Home Assistant, the occupancy sensor will become clear even though Frigate is still actively detecting the car in the garage. Here's a video showing the situation.
I think this is related to this issue:
#376
Debug log
The text was updated successfully, but these errors were encountered: