-
Notifications
You must be signed in to change notification settings - Fork 53
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
binary_sensors not being updated #45
Comments
Have you done any firmware updates on your NVR's recently? If you force an event shortly after starting up the component does it show up? Having the watchdog trigger on both streams at the same time may be a network error on the HASS side of things since it's extremely unlikely for both streams to drop at the same time. |
I'm afraid both NVRs have actually been updated recently to newer firmware.I will try to test if events are coming through after restart once I manage to get back home. I will also try to debug eventStream to see what exactly is coming through. |
I have also started seeing following in the logs after reboot:
This looks like #44 mentioned few days ago. |
Watchdog appears to be expiring exactly 5 mins because |
Alright, it looks like a recent firmware change may have altered the behavior on reporting the channel ID's in the event stream. If you're getting the TypeError every time the watchdog expiration and lack of events makes sense. Just to be thorough, please try curling the event stream for one of the NVR's to make sure it's still sending out events. |
It does look plausable indeed. I did leave terminal open for about 30 mins and I'm getting a steady flow of events, mostly
|
I've merged in a fix for the blank channel ID field and released a new version. A PR is pending to update the repository in HASS but you can manually specify 0.2.5 to check it now if you'd like. |
Thank you. Now I'm getting following error:
|
Ok, I'm going to need samples from the alert stream from a couple different types of events. If the IDs are missing from everything it's not as straight forward to fix. |
Thank you for taking time to look into this. I can see that line crossing has
|
Here is the list of my event triggers:
|
Perhaps disable the video devices which aren't connected or turn off video loss reporting to stop video loss flooding the alert stream, then post a few different events from the alert stream. |
I don't have any. devices which aren't connected, those are five Hikvision cameras. Sadly there is no way to disable video loss, as it just keeps coming. My understanding is that it is used to keep connection alive and without it, it would simply timeout. |
Strange, I don't see that on my NVR and don't have timeout issues. |
Funny thing is that disabling "Notify Surveillance Center" for Video Loss actually solved the problem. I fail to understand why because curling still shows them:
|
Ok so what is probably happening and what I saw myself with my NVR is that when things are in alarm they send through dozen of messages a second, and you can only really handle a couple of devices doing this before things start going funky, did you turn it off on the camera and the stuff under exceptions? |
Yes. I've disabled it for all cameras. It is still supposed to keep pushing it for keep alive: Line 564 in b0c60a0
The reason it does not cause an error is because pyHik is ignoring these types of events since we are not "subscribed" to them. The reason is does fail with Video Loss enabled is probably because execution of |
For whatever reason videoloss events are always published in the stream no matter what settings you have turned on. I don't know why they decided to do it that way, but it makes for a nice keep-alive indicator to know that the stream is active. The problem in this case is a monitored event being published without an ID. The way the individual events are tracked within pyHik is a combination of the name and the ID. If there is no ID available you get the TypeError since the field ends up being blank. I'm going to consider this as something that needs further exploration for now. If videoloss events are the only culprit I may just consider removing them from the monitoring list. |
I think that whenever a real (active) videoloss event would occur, it would have an ID of the channel. We could have a branch in code specifically checking if this is inactive videoloss and has no ID and consider it as heartbeat. |
Seems like this still might be a thing? I've recently upgrade my DS-7608NI-I2 to V4.22.000 build 201208 and now i'm getting
Homeassistant core-2021.5.5 |
@necromn Are you notifying the surveillance center for videoloss events? |
Yeah I read up the page and saw that so i thought i went and turned them all off but i'll double check Edit: My bad - I disabled video loss but I did not uncheck the notify surveillance center. Without that ticked it all comes back to life, so confirmed test case for enabling video loss to notify breaks the stream. |
Unfortunately I have recently stopped receiveiving updates for any binary_sensors in HomeASsistant. last_tripped_time is always of the last boot time. I've added logging as follows:
I don't see anything particularly wrong except maybe for last two lines (not sure if this is an expenses behaviour):
I do have
Notify Surveillance Center
permission enabled.The text was updated successfully, but these errors were encountered: