IPC-T5442T-ZE IPC-T5442TM-AS IPC-T5842T-ZE SMD 3.0 Smart IR Latest New Firmware From EmpireTech

[David L]

If you choose week, instead of date, then you won't have to change the date every year.

Thx

 

[IAmATeaf]

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?

 

[David L]

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?

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.

pfSense:

From my Router:


From my Windows 11 PC:



[/QUOTE]

 

[IAmATeaf]

Isn’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.

 

[jrbeddow]

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.

 

[David L]

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.

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.

Sorry guys if I am here...

 

[David L]

Isn’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.

Yes, it is just not working at this time, so preferred drops down to the other Pools...to my understanding

 

[IAmATeaf]

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.

Isn’t that what I said above?

 

[jrbeddow]

Isn’t that what I said above?

Yes, perhaps stated slightly differently. No harm, no foul, right?

 

[pixelscript]

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?

Cheers.

 

[IAmATeaf]

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?

Cheers.

Have you done a find/inspect on the camera in BI?

 

[pixelscript]

Have you done a find/inspect on the camera in BI?

Yep, no change.

EDIT: I changed Network > Access Platform > ONVIF > Authentication to OFF
as suggested by DidyouDahua and it now works. My cams are disconnected from the wan so I'm not too concerned. Would be nice to know what changed though.

 

[Vygantas]

Yep, no change.

EDIT: I changed Network > Access Platform > ONVIF > Authentication to OFF
as suggested by DidyouDahua and it now works. My cams are disconnected from the wan so I'm not too concerned. Would be nice to know what changed though.

I've noticed another behavior after update to this firmware for one of my 5442T-ZE:
Scenario 1.

• if I set admin password to be 8 symbols (lower case, Upper case, numbers, special characters) Find/Inspect works fine and there is no "Events: subscription 00000190" message in BI logs;
• if I set admin password to my preffered one (16 symbols, lower case, Upper case, numbers, special characters) this "Events: subscription 00000190" appears in event logs and Find/Inspect does not find streams (Main or Sub's) from the camera. So I had to create special user as operator and use it in find/inspect to make sure streams are found.

Scenario 2 (after scenario 1):

• when I enable DST for the time and use Find/Inspect (with no other changes on Date&Time page, just tick the check box to enable DST) Find/Inspect works fine.
• if I change DST type to what it must be, Find/Inspect no longer finds streams from camera (while using the same Operator user from scenario 1). and "Events: subscription 00000190" appears again. This time I can disable DST (unticking the check box) Find/Inspect finds streams but the message (00000190) is still generated in event log. And there is only one way to get rid of it: Factory reset.
• after factory reset I can use any user with any password (no need to go with scenario 1) and no messages (00000190) appear in the log. Until I do something in Date&Time page (i.e. clock on Sync with PC).

On my another 5442T-ZE camera everything was solved with scenario 1.
I'm running out of ideas how to solve that with this unit.

 

[Vygantas]

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).


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):

or

I checked with ONVIF Device Manager and here I see this error:


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.

 

[wittaj]

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.

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

 

[Vygantas]

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

Checked. It works without additional find/inspect. Will go that way.
I will check if it gets event triggers from camera later.

 

[Vygantas]

Checked. It works without additional find/inspect. Will go that way.
...

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.

 

[Alfredo Monarrez]

I am using Dw Spewctrum VMS/ NX Witness I have found that the firmware provided by Andy is generic and when DW loads to camera in it comes in as general, causing the cameras anyltics not to work with the vms. Is there any simple fix to getting DW to read Dahua?

 

[David L]

Repositioned (Moved) our 2.8 mm 5442 CAM today:

 

[maximg]

Hello,

With latest firmware, my T5442T-ZE started to continuously generate and save snapshots. Even if I enable only "Event" checkbox for Storage destination and disable all of the detection types, it saves a snapshot every 10 seconds. The schedule tab has only "Event" and "Alarm" types enable. I did perform "Factory Default" reset, but it did not help. Any other setting that may cause it?

/