5.7.5 - April 20, 2023 - Onvif updates

But unchecking "Get ONVIF trigger events" now means the camera isn't doing the motion detecting and sending to BI - that is ok if that isn't how you have it set up, but what about those that use the camera on-board AI to do the triggering?

Also, you can't use the find/inspect feature! I use this all the time. It's not just the events, it is failure to authenticate the onvif user. Here's another kicker, I tried to use Onvif Device Manager and it also will not authenticate. So now I am stumped as why this worked before the update, yet appears to be camera issue now ?? For now, I just turned off onvif authentication in the camera, which is not a good fix.
The camera I am having this issue with and only it is the SD5A425GA-HNR.

190.jpg
 
That is odd. ODM should be completely independent of anything in BI.

ETA: Just checked mine in ODM and all seem OK. I'm not seeing any problems authenticating. All of mine come up on discovery and can be accessed with no problem.
 
Last edited:
But unchecking "Get ONVIF trigger events" now means the camera isn't doing the motion detecting and sending to BI - that is ok if that isn't how you have it set up, but what about those that use the camera on-board AI to do the triggering?
Understood. I should have been more clear.

I was just confirming that the error messages could be eliminated by disabling ONVIF events in BI as well as in the camera itself.
 
Also, I did check and am running the latest version of ODM 2.2.250 and double checked my onvif user password in the camera twice now. Once I turn off onvif authentication in the camera then ODM will also connect fine. I also even tried my BI demo install and reverted it back to 5.7.9.12 and did a full registry import of that version as well....BI still will not authenticate onvif. I don't really even know how to explain this one to Ken :lol:
 
Exactly, same error in it I get in BI. This camera is almost identical to all my other Dahua cams and they all work fine.

Search for that "Wsse authorized time check failed" error and it seems to be related to how time is used for ONVIF authentication. e.g.:

Not sure why that would happen all of a sudden. Wonder if maybe the month change? Or maybe something associated with DST changing this month? Don't know enough about how the authorization is done but only thing that I can think of.
 
  • Like
Reactions: looney2ns
Search for that "Wsse authorized time check failed" error and it seems to be related to how time is used for ONVIF authentication. e.g.:

Not sure why that would happen all of a sudden. Wonder if maybe the month change? Or maybe something associated with DST changing this month? Don't know enough about how the authorization is done but only thing that I can think of.
Good point !
 
How do you have time and DST set on your cams? All of mine (working OK) are using a local NTP server, EDT local time zone, DST changing based on week for the first Sunday in November @ 2:00 am.
 
  • Like
Reactions: looney2ns
How do you have time and DST set on your cams? All of mine (working OK) are using a local NTP server, EDT local time zone, DST changing based on week for the first Sunday in November @ 2:00 am.
I run a NTP server in a Linux VM. Cams all sync with it and have DST enabled and configured properly.
 
  • Like
Reactions: Mike A.
How do you have time and DST set on your cams? All of mine (working OK) are using a local NTP server, EDT local time zone, DST changing based on week for the first Sunday in November @ 2:00 am.

Yes, mine snyc to my BI machine via NetTime. Same settings I use in my others as well. Maybe this is the new WEB 5.0 issue ?? It is the only difference to my other cameras as they all run web 4.0

192.jpg
193.jpg
 
:idk:

I double checked my only cam with 5.0, which is working, and I do have authentication turned on. I have had the 8000ffff errors in the past with that cam and thought that I'd left it turned off. Must have fixed that and turned it back on but I don't recall when/why/how.
 
i thought my issue was an odd one but looks like I’m not the only one since I was on latest stable release and hadn’t made any changes to my BI machine for at least 3-4 weeks. Just a couple of days ago, I noticed I stopped getting pushover alerts and when I looked into this, I saw BI logs were spamming with 8000ffff errors from trying to get onvif events. The issue seems to affect 7 of my cams, 5 of those are 5442. Updated BI to latest version and/or rebooting the cams didn’t resolve the issue either. Had to disable onvif authentication for onvif alerts to work again.

Biggen, Hopefully, Ken will provide you some clues so we can avoid this in the future.
 
  • Like
Reactions: jrbeddow
Unless you’ve raised a ticket then this is an old issue which he might think has been resolved?
We all thought it was resolved. I'm betting it has to do with the DST change coming up. My cameras are set to change from DST automatically. I don't believe its a coincidence that both cameras that I use for ONVIF alerts and that have DST enabled stopped working on the exact same day/time.
 
We all thought it was resolved. I'm betting it has to do with the DST change coming up. My cameras are set to change from DST automatically. I don't believe its a coincidence that both cameras that I use for ONVIF alerts and that have DST enabled stopped working on the exact same day/time.
you are correct, I just tried to disable DST in the problem cam and still no luck. I then tried to change time back one hour, still no work. I then changed the time to 2 hrs. earlier and bingo, the onvif then authenticated.

196.jpg
 
  • Like
Reactions: Mike A.
UPDATE: I found that by selecting a date in the DST selection, then the problem is fixed. There is a bug in the camera's DST firmware and it is not reading the correct date using the week setting. Also found that using the date method, you cannot select 2:00 am on the start date, why I show 1:59am. Also you MUST restart the camera in Blue iris each time you change anything in the camera's Gui. Of course this is not a good solution as the date changes every year. I think the best solution is to just leave DST disabled and let the NTP sync the time, if you use NTP.

197.jpg
 
  • Like
Reactions: Mike A.
Good job figuring out what's happening.

I think the best solution is to just leave DST disabled and let the NTP sync the time, if you use NTP.

Unfortunately, won't work. NTP uses UTC for time. Any local time zone adjustment, DST, etc., are on the client to maintain. So the time will stay an hour off, it won't adjust to the time of the machine running the local server.
 
Good job figuring out what's happening.



Unfortunately, won't work. NTP uses UTC for time. Any local time zone adjustment, DST, etc., are on the client to maintain. So the time will stay an hour off, it won't adjust to the time of the machine running the local server.
LOL, I was going to edit my post after figuring that out but hadn't got that far. Thanks for pointing that out. So for some reason on November 1 when Ken released the .12 update, then if you updated, your cameras are restarted within BI and the error showed up. I notice in the WEB 5.0 GUI if you select date instead of week, it defaults to 10/31 on the end date. I think a firmware update is the only real good fix here.
 
  • Like
Reactions: Mike A.
Buggy Dahua firmware. Shocker! :rolleyes: Thanks for that great bit of detective work @Tinman. You may want to ship that info over to Ken.

I guess I'll just leave ONVIF authentication off. Don't really need it activated and I don't want to have to change the DST dates all the time. Having it set as the week is a hell of a lot simpler.
 
  • Like
Reactions: Leroy60