IPC-T5442T-ZE IPC-T5442TM-AS IPC-T5842T-ZE SMD 3.0 Smart IR Latest New Firmware From EmpireTech
- Thread starter EMPIRETECANDY
- Start date
MikeLud1
IPCT Contributor
The backlight setting does not show the change happening but if you resave the setting it goes back to normal.
@MikeLud1 / All. This is a known bug. I flagged the bug to Dahua RE: the underlying, earlier codebase which was fixed in the 09/08 beta FW (primarily for 4K) but the 08/28 was built on the older codebase and that issue still exists. Therefore Dahua already aware. It primarily affects exposure settings but can impact others too. @EMPIRETECANDY this is the bug I captured on video and showed Dahua & yourself about a month ago. For the 4K, looks to be fixed in the 09/08 which of course was built on the known good, 06/11 FW base that I recommended they use. However, 08/28 was NOT built on the known good base (I know Dahua is aware of this). Therefore once I'm finished testing 09/08, assuming thats still good, then Dahua should pick this up / converge the codebases assuming they continue using 09/08 as the next iteration of VOLT FW etc. Will reach out to refresh the details and also ensure Dahua engineering is aware of what FW codebase to continue using.
Last edited:
@Wildcat_1
So that 06/11 branch is also the problem and the solution to the IVS problem? I was hoping for such explanation.
BTW, I'm having the same sort of IVS problems with my color4k cams (5849 line).
I am a bit confused. I have 3 IPC-T5442T-ZE just bought from Andy. The Version is V2.800.15OG004.0.R, Build Date: 2020-12-03
What is the latest stable firmware to use and where to get it from? The first post has two .docx to download. So there are two .bin files I can download. Which one should I use for my camera?
Should I hold off for the one oming in October?
What is the latest stable firmware to use and where to get it from? The first post has two .docx to download. So there are two .bin files I can download. Which one should I use for my camera?
Should I hold off for the one oming in October?
For the 5442 right now, the latest is 21-07-29. I would advise you try that one first. 8/28 still has some issues. While there are some quirks still being ironed out on 7/29 it is a solid FW for you to try on your cams.
NO !!!!
My advise is NOT to touch Dec 2020 FW in case you care about reliable IVS.
Though @Wildcat_1 is the best camera tester we have in here, guys that are using IVS as their watch guard (including me but not only me) were complaining about the reliability of the IVS with all 2021 FW we've tested.
The 28082021 is BAD !!!!!
With the Dec 2020 FW I've never caught dogs and cats, with 28082021 it happens (not too often but it sure does every couple of days - especially at nights).
With Dec 2020 FW, when the tripwires aligned correct, it hardly ever misses a human crossing. All the 2021 FW I've tested missed me (again, not too often but it's enough to realize that something went wrong and find out that you are not the only one complaining).
Bottom line: if reliable IVS is important to you, stay with your current firmware.
Before we get to that explanation I'd add:
1. it's got nothing to do with factory reset before and after the upgrade.
2. it's got nothing to do with global settings.
When you'd test the IVS, you'd probably get got results cause it's working OK MOST of the time.
But testing over a longer period of time (like a week time), and trying to verify that you never miss IVS events you'd find out that some events are simply not detected.
Though you can never expect bullet proof of 0% false positives and 0% false negatives. The Dec 2020 firmware is as close as it cat get and ALL 2021 FW are missing a lot for some reason.
I was asking @Wildcat_1 if the next firmware that starts from the branch of 06/11 is expected to fix the IVS but I got no answer.
It looks like wildcat ignores the IVS problems because he didn't find them.
1. it's got nothing to do with factory reset before and after the upgrade.
2. it's got nothing to do with global settings.
When you'd test the IVS, you'd probably get got results cause it's working OK MOST of the time.
But testing over a longer period of time (like a week time), and trying to verify that you never miss IVS events you'd find out that some events are simply not detected.
Though you can never expect bullet proof of 0% false positives and 0% false negatives. The Dec 2020 firmware is as close as it cat get and ALL 2021 FW are missing a lot for some reason.
I was asking @Wildcat_1 if the next firmware that starts from the branch of 06/11 is expected to fix the IVS but I got no answer.
It looks like wildcat ignores the IVS problems because he didn't find them.
Thanks for the warning @ArnonZ. At this point, I haven't really used the IVS yet. I tried it a bit earlier (on the Dec 2020 firmware) but couldn't really figure out how to get it to work with BI properly. So at the moment I'm just using BI's motion detection system. I will revisit this maybe once the new firmware that has the fix is out. I'm still at my very first weeks of using BI / camera etc. still lots to learn. I've upgraded my firmware before reading your posts. Is there a way to revert in case I might want to play with things?
There are a few places you need to set this up in Blue Iris.
In Camera configure setting check the box "Get ONVIF triggers".
Hit Find/Inspect on the camera setting to pull the coding for the triggers.
Go into Motion Setting and select the "Cameras digital input" box.
I believe I have done all the above, and BI would create an alert marked as "External". However, the triggers were mostly (if not all) miss i.e. false positives. The alert clips showed nothing happened. No cars etc. At this point I'm going to just use BI's motion detection because I want to be able to differentiate triggers from different zones, which AFAIK, can't be done with in-camera IVS.
IAmATeaf
Known around here
Bit late to the debate 
but I downgraded one of my cams back to the Dec 2020 firmware and can confirm that IVS for me is working 100% on that cam where with the 07 2021 firmware that cam would hardly ever trigger but would always be triggered by another group camera.
Although I’ve got the latest iteration of the firmware from Andy I’ve not yet tried it as I was waiting to do a long test on the Dec firmware. I’ll reflash this to the latest over the weekend and do some testing over the course of next week.
but I downgraded one of my cams back to the Dec 2020 firmware and can confirm that IVS for me is working 100% on that cam where with the 07 2021 firmware that cam would hardly ever trigger but would always be triggered by another group camera.Although I’ve got the latest iteration of the firmware from Andy I’ve not yet tried it as I was waiting to do a long test on the Dec firmware. I’ll reflash this to the latest over the weekend and do some testing over the course of next week.
Not ignoring, busy assisting other forum members too @ArnonZ + also doing the multi cam test of this issue reported here 
As I mentioned, the 6/11 FW is the good branch (was the best of the 4K to date) that needs to be used as the base code at this point which I’ve reported back to Dahua and continue to push them on. This is also why in the 4K thread I recommend that anyone that has a 4K shipping with 7/09, they roll back to 6/11 and most have seen an improvement there. This is a step up and in the 09/08 FW (currently being tested on 4K) does have further improvements on the 4K too as I mentioned in that thread. Specifically doesn't bog down the cam as much, which assists in other functions working better including target acquisition, improves the AA a ton too, super important to PQ. As I mentioned however, there are still other bugs in 09/08 that need fixing hence wanting them to focus on that too to make sure we all benefit from a good end release FW.
Moving to the 5442, the IVS is not bad in the 7/29 by any means (as I clearly stated above @ArnonZ , DO NOT USE 8/28 it is less stable overall than 07/29 so you and I are on the same page with that FW) but target acquisition can always be better in any FW which is why the continued testing and evolution of FW. We also have to remember hardware build dates or version of the cams plays a role too. I asked you for this above but you sent me FW build date not HW. There is a difference between V1 and V2 of the 5442's in these FW's for sure. I've tested against 5 cams recently across build dates + FW revisions and do see differences in HW vs FW build.
Now with that said, testing on cam directly through day and night, I see SMD is more on point in 7/29 than previous FW (and is improved still in 09/08). With IVS there are crisper acquisitions on different revisions of the turrets with 7/29 for sure but I see some tweaks that can be made to address the IVS even finer across V1/V2 turrets/bullet cams. In V2 (strange as newer revision) I see more of a delay / lag (processing) between tripping of rules vs target acquisition (more so on tripwires but still present in intrusion zones) which of course can then delay, mis-tag or just miss a target altogether based on size of FOV and target time within it after the lag.
Other than the above, the changes I see in testing this and isolating the environment (local cam caps vs movement on scene instead of using NVR or NVR platform) are small in nature and again look in code to be caused more by timing of acquisition processing leading to the other issues with IVS i.e. easy to fix by Dahua. The AI could also be tweaked a little BUT you have to be careful what you ask for as there is a fine line between being more liberal with AI algorithms that lead to incorrect targets (animals vs humans) vs too tight and missed caps. For reference, in my testing I've set intrusion zones to push this cam covering tree's, bushes, fences etc and purposefully adding foreground and background objects to throw the cams off and even when deer's, dogs and people are on scene I still see both SMD and Intrusion IVS capturing well in a medium to wide FOV. This is even when a target appears between tree's bushes. Again only issue I've seen is the processing delay/lag which although there across the board is more present on V2 HW in 7/29 which can have the issues I mentioned above and of course play into target acquisition as I stated.
With regards to 09/08, I've cautioned Dahua that although this was built on a good codebase (6/11 as I recommended), that base was primarily focused on 4K therefore I've fed back that IMO they need to be careful merging 4K and 5442 in same FW (since these are VOLT enabled). My recommendation to them is to actually keep them separate branches that way focus can be given to the areas specific to 5442 that need tweaking without causing issues (or missing issues) relating specifically to the 4K.
My recommendation for all setting ups these cams or having issues is absolutely isolate the cams first for testing (if you haven't already) i.e. throw an SD card in and then compare your testing (do a test then review) vs SD caps first then start adding back in the other infrastructure such as NVR or NVR platform (BI) and look for those changes there too. That way if your NVR or NVR platform is adding other issues (not seen on local caps) then those can be separated out to address too. This approach can be very beneficial to fault isolation and leads to a number of bugs being found across the path of comms. In my testing here I started with straight to SD then added in Dahua NVR's for test too.
Lastly with regards to factory reset, you will find a number of us here always recommend it before and after FW upgrades because we've experienced issues or hold over bugs with a crazy number of features when this has not been followed. I mentioned this myself with 5442 and the Smart IR fixes too.
HTH and have passed my findings from this multi cam test back to Dahua as well.
As I mentioned, the 6/11 FW is the good branch (was the best of the 4K to date) that needs to be used as the base code at this point which I’ve reported back to Dahua and continue to push them on. This is also why in the 4K thread I recommend that anyone that has a 4K shipping with 7/09, they roll back to 6/11 and most have seen an improvement there. This is a step up and in the 09/08 FW (currently being tested on 4K) does have further improvements on the 4K too as I mentioned in that thread. Specifically doesn't bog down the cam as much, which assists in other functions working better including target acquisition, improves the AA a ton too, super important to PQ. As I mentioned however, there are still other bugs in 09/08 that need fixing hence wanting them to focus on that too to make sure we all benefit from a good end release FW.Moving to the 5442, the IVS is not bad in the 7/29 by any means (as I clearly stated above @ArnonZ , DO NOT USE 8/28 it is less stable overall than 07/29 so you and I are on the same page with that FW) but target acquisition can always be better in any FW which is why the continued testing and evolution of FW. We also have to remember hardware build dates or version of the cams plays a role too. I asked you for this above but you sent me FW build date not HW. There is a difference between V1 and V2 of the 5442's in these FW's for sure. I've tested against 5 cams recently across build dates + FW revisions and do see differences in HW vs FW build.
Now with that said, testing on cam directly through day and night, I see SMD is more on point in 7/29 than previous FW (and is improved still in 09/08). With IVS there are crisper acquisitions on different revisions of the turrets with 7/29 for sure but I see some tweaks that can be made to address the IVS even finer across V1/V2 turrets/bullet cams. In V2 (strange as newer revision) I see more of a delay / lag (processing) between tripping of rules vs target acquisition (more so on tripwires but still present in intrusion zones) which of course can then delay, mis-tag or just miss a target altogether based on size of FOV and target time within it after the lag.
Other than the above, the changes I see in testing this and isolating the environment (local cam caps vs movement on scene instead of using NVR or NVR platform) are small in nature and again look in code to be caused more by timing of acquisition processing leading to the other issues with IVS i.e. easy to fix by Dahua. The AI could also be tweaked a little BUT you have to be careful what you ask for as there is a fine line between being more liberal with AI algorithms that lead to incorrect targets (animals vs humans) vs too tight and missed caps. For reference, in my testing I've set intrusion zones to push this cam covering tree's, bushes, fences etc and purposefully adding foreground and background objects to throw the cams off and even when deer's, dogs and people are on scene I still see both SMD and Intrusion IVS capturing well in a medium to wide FOV. This is even when a target appears between tree's bushes. Again only issue I've seen is the processing delay/lag which although there across the board is more present on V2 HW in 7/29 which can have the issues I mentioned above and of course play into target acquisition as I stated.
With regards to 09/08, I've cautioned Dahua that although this was built on a good codebase (6/11 as I recommended), that base was primarily focused on 4K therefore I've fed back that IMO they need to be careful merging 4K and 5442 in same FW (since these are VOLT enabled). My recommendation to them is to actually keep them separate branches that way focus can be given to the areas specific to 5442 that need tweaking without causing issues (or missing issues) relating specifically to the 4K.
My recommendation for all setting ups these cams or having issues is absolutely isolate the cams first for testing (if you haven't already) i.e. throw an SD card in and then compare your testing (do a test then review) vs SD caps first then start adding back in the other infrastructure such as NVR or NVR platform (BI) and look for those changes there too. That way if your NVR or NVR platform is adding other issues (not seen on local caps) then those can be separated out to address too. This approach can be very beneficial to fault isolation and leads to a number of bugs being found across the path of comms. In my testing here I started with straight to SD then added in Dahua NVR's for test too.
Lastly with regards to factory reset, you will find a number of us here always recommend it before and after FW upgrades because we've experienced issues or hold over bugs with a crazy number of features when this has not been followed. I mentioned this myself with 5442 and the Smart IR fixes too.
HTH and have passed my findings from this multi cam test back to Dahua as well.
I do not use BI. My sister is very happy with it. The BI is deferentially the best way to go.
But yes, importing triggers from the camera works better and the May, Jul and Aug firmware ALL suffers from poor IVS reliability.
** poor = comparing to the excellent performance I used to get in all 2020 FW
Using motion detection is not the best idea IMO
At least with Dahua cams, for some reason the IVS was close to perfect while the SMD (Smart Motion Detection) was never reliable. I get lots of events of my cats and dog.
The new FW of 2021 introduced "SMD 3.0" it suppose to be better but still misses a lot.
There is not problem to revert back to 12/2020 FW.
@IAmATeaf If you are thinking about the 8/2021 FW, don't bother trying it if IVS is something you count on. I was (and still am) trying it. Just an hour ago I got an alert from my dog. Never had those with the Dec FW.
I have another cam (color 4k 5849) that point to the same gate and I can tell you that it's not only false alarms: the 28082021 FW of the 5442 misses alerts (most of them at night time).
It's not something you'd notice right away. most of the times the IVS alerts work great but it's not close to the reliability of the Dec FW.
Thank you @Wildcat_1
I'm also currently testing the 0809 for the 4k and the 2808 for the 5442 cams.
I do use SD cards but since I don't have POE switch, I'm running everything VIA NVR (NVR5216-16P-I).
As for the color 4k, I have full list of bugs but it's not the place for those. In general, I share the view that it's the new king of the hill. My sister started with one and since then we've added together 8 more of them.
I'm very happy with that model but if it was a European or American product, it would not be ready for market
Back to the 5442:
I missed your question about the revision. If I read it right, both my E-ZE bullet and T-ZE turret are V2.840
I must admit that I didn't get to test the 2907 FW myself because a friend told me that the IVS problem is still there. I can confirm from a personal experience that the problem is there with the 2808 FW.
I do know enough about the fine line between false positive and false negative EXCEPT here, the 122020 FW was close to perfect (way better than I could ever expect from AI) while the 2021 FW have BOTH more false positives AND more false negatives.
The SMD 3.0 was also a big disappointment for me but today I was testing the results of SMD 3 on the 4K and I've had a very good surprise: everything I tested (so far) was 100% accurate.
What I meant to say about the factory reset was that I too do reset before and after upgrade and manually sets parameters. I meant to say that the problems is NOT factory reset and NOT global settings as I've done then.
Not sure if I can find now the 2907 FW or I should already wait for the 0809. Everything I was testing so far from 2021 preformed bad for IVS. With the Dec. 2020 the performance was so good that I felt ready to add siren for the nights.
IF I would not integrate the siren it's just because:
1. fitting a relay with WIFI and integration to HA to my NVR fells stupid because I'm not happy with it. There are lots of bugs and some features are useless and not being taken care of. Eventually I'd have to migrate to BI.
2. the brilliant color 4K cams have their siren is it's already half solution.
Thanks again
** WARNING ** I wanted to list another issue I've found (now able to repeat on demand) with the 08/28 FW that as I mentioned above DO NOT INSTALL. Specifically if you try and flash back from this to an earlier version it will put the cam into a locked state. Specifically although boot loader appears intact you cannot access the camera at all. Luckily it appears that a factory reset will let you boot back into the cam and then IF you do a downgrade immediately you should be good. @EMPIRETECANDY my recommendation again is NOT to distribute the 21-08-28 FW and have Dahua look into this as I mentioned. Thanks
Jayordon
Getting the hang of it
I'm currently running 2.820.15OG001.0.R, Build Date: 2021-05-25 on two 5442's. I have my main stream encoding on H.265 on both of them. I use Home Assistant and I like to have the camera stream there too. But Home Assistant doesn't support H.265 (I'm not sure if it's a limitation of Home Assistant or just the web browser). My workaround has been to enable Sub Stream 2 encoding in H.264.
Here's the problem. After a few days both cameras automatically change the encode mode on sub stream 2 to H.265. Has anybody else noticed this bug? It does this no matter how I change the setting. Same result whether I do it from my NVR or from the camera webpage. Works fine for a few days and then just automatically changes back. The bit rate changes with it too. Has anybody else run into this?
Here's the problem. After a few days both cameras automatically change the encode mode on sub stream 2 to H.265. Has anybody else noticed this bug? It does this no matter how I change the setting. Same result whether I do it from my NVR or from the camera webpage. Works fine for a few days and then just automatically changes back. The bit rate changes with it too. Has anybody else run into this?
Just curious. It seems like most people agree the 12/03/2020 firmware release for the 5442's is the best for IVS. So why is IVS WORSE in 2021 these newer June-Sept releases? if they're just trying to improve SMD in the newer firmwares, then why is IVS effected/worse? Why not just leave IVS alone as it was working great in the 12/03/2020 release? Doesn't make sense to me.
Well remember as I stated above, 7/29 isn’t that bad and can be tweaked easily to really lock it in based on my testing however you can use any FW you like (but DO NOT use 21-08-28). Also remember that the VOLT range of cams has increased including newer 4Ks (check the review if interested) and others (like dual lens). One of the consequences of this is multiple cams are using the same branch albeit with different sensors and features. This can cause spill over issues and when updates are made to improve 1 feature for 1 model, might in turn cause issues for another model covered by the same branch.
Hence my reco to Dahua to split the branches at this point and move the 4K (even the dual lens) to separate branches going forward therefore allowing these final issues with the 5442s I mentioned to be taken care of.
Otherwise you end up with the balloon effect. Push down on one side (fixing or tweaking for 1 model) and the other side pops up (issues seen in other models in the range).
HTH