Where I get confused, my pfSense router keeps perfect time, it gets its time from other NTP Time Servers/Pools. and the router's DST is set to CDT so I don't have to set DST on my devices, they just get their time from the routers NTP Server. Maybe I am wrong how this works, I have a friend helping me setup a U-Blox GPS receiver to get my future time from. That is what the 127.127.20.0 address is for but I was unable to get Satellite connection where the receiver resides, I need to try to run an antennae wire up in the Attic. So presently my time comes from the other Pools.I suppose it does depend on the device and how it might make use of any region settings that have been set but a time server offers the time based on UTC, it’s then up to set the correct time zone and then DST.
Without DST being set wouldn’t the time be correct for part of the year?
Agreed but what is crazy, none of my devices have DST set, except my CAMs, yet they all are in sync with my Router's time which does have DST set and has the correct time for my Time Zone. My guess pfSense goes out to the NTP Servers to get it's time, it corrects the time with DST set and my devices gets it's time from the NTP Server I setup in pfSense.It's really simple: NTP servers hand out the "real" time without the artificial "overlay" of dealing with DST, as that will vary depending on where you are (some states don't observe it, etc...). The "overlay" of imposing the DST setting has to be done on the device, it doesn't come directly from any NTP servers.
Yes, it is just not working at this time, so preferred drops down to the other Pools...to my understandingIsn’t that NTP Server option in your screenshot one to enable that device to become a time server so that other devices can sync their time with it?
It’s probably the set time automatically that’s reaching out and setting the correct time based upon your time zone and in turn taking care of DST.
So for example on my Windows 10 devices it has something similar to the set time automatically and I never have to worry about clocks going forward or back.
Isn’t that what I said above?It's really simple: NTP servers hand out the "real" time without the artificial "overlay" of dealing with DST, as that will vary depending on where you are (some states don't observe it, etc...). The "overlay" of imposing the DST setting has to be done on the device, it doesn't come directly from any NTP servers.
Have you done a find/inspect on the camera in BI?Hi, since updating my firmware of my ipc-t5442t-ze to:
V2.840.15OG00D.0.R, Build Date: 2022-08-18
It no longer triggers IVS in blue iris via ONVIF. Where previously it worked fine. Instead now I get an Events: subscription 00000190 notice in my blue iris logs.
I've tried a factory reset but still no dice. Will it be possible to revert firmware without bricking the camera?
Yep, no change.Have you done a find/inspect on the camera in BI?
I've noticed another behavior after update to this firmware for one of my 5442T-ZE:
So will the camera work in BI if you do the find/inspect with DST as day but then go back into the camera afterwards and change the DST to week but DO NOT do find/inspect again? I don't see why you would have to do find/inspect again changing DST.After doing more research here are my findings:
1. "Events: subscription 00000190" must be generated in BI logs. This shows that BI is listening to ONVIF trigger events.
Excerpt from the post in BI forum:
The logs will let you know if BI is listening via Events log events.
CODE: SELECT ALL
1 12/10/2021 10:08:04.253 AM Cam13 Events: subscription 00000190
1 12/10/2021 10:08:05.472 AM Cam11 Events: subscription 00000191
1 12/10/2021 10:08:06.891 AM Cam12 Events: subscription 00000190
1 12/10/2021 10:08:07.272 AM Cam13 Events: subscription 00000190
1 12/10/2021 10:08:08.477 AM Cam11 Events: subscription 00000191
2. There is an issue with the DST option in camera configuration. This is how it works on all of my cameras (5442T-ZE and 5442TM-AS).
View attachment 143143
If I make selection of Date in DST configuration everything works fine. As soon as I switch to Week BI can't connect to camera via ONVIF. Here is what I get in BI Find/Inspect (depends which port I write in Discovery/ONVIF port: 80, 8999):
View attachment 143144 or View attachment 143145
I checked with ONVIF Device Manager and here I see this error:
View attachment 143146
As soon as I switch back from Week to Day everything works fine.
That means I will have to change the date once in a year in order to have correct time in camera.
Checked. It works without additional find/inspect. Will go that way.So will the camera work in BI if you do the find/inspect with DST as day but then go back into the camera afterwards and change the DST to week but DO NOT do find/inspect again? I don't see why you would have to do find/inspect again changing DST.
Does the camera work otherwise in BI even with those event subscriptions? I get those if I restart a camera but they stop after a few minutes and the camera works in BI as intended. I let my OCD behavior go and just ignore them since everything still works LOL
Same thing applies to my Review: Dahua SD5A425XA-HNR 4MP 25x Starlight IR PTZ . The issue is that I can't call PTZ preset if find/inspect doesn't work. So for PTZ this is not an option.Checked. It works without additional find/inspect. Will go that way.