20180523 Firmware for DH_IPC-HX5X3X-Rhea

eagle_eye said:
Hi,
I am using the IPC-HDBW4631E-ASE and I am quite happy with it. Particularly the IVS is working fine - to detect persons moving in a No-Go area.
Now I have an other task to solve. Based on the experience with the 4631, I ordered a IPC-HFW81230E-Z (staring camera with 12M Pixels). Cause by the dramatic huge price I expect to have the same IVS and motion detection in the firmware.
But surpringly: motion detection is available, but IVS NOT!
The Motion detection is quite unusable for my application - Persons are roughly 30-40m away and caused by the IR light I have some more flys in front of the camera. I am getting lots of detection, caused by flys and wind. Therefore I need to use the IVS, which is working quite fine at the 4631.
I am using the latest more-or-less official FW "DH_IPC-HX8XXX-Nova_Eng_P_Stream3_V2.622.0000001.16.R.171215.bin".

Any ideas to activate the IVS?

The zooming is NOT important for me. The field-of-view of roughly 90° is fine. So maybe I can use an other FW, which has IVS but the zooming is not working any more??
Click to expand...

For IVS to be available, Smart Codec needs to be turned off. Is it?
SmartCodec.JPG
 
  • Like
Reactions: nymphaeles and aristobrat
@weigle2 and nymphaeles: GREAT! Now it is working. :goodpost:

Just disable the moving detection and enable the IVS. This night I will check it. I hope my problem is solved now :)
 
After receiving a new camera (HDW5231R-ZE) that had the March firmware installed I updates it to this version and everything worked great until I tried to change the zoom, it didn't work from BI so I tried it from the cameras web interface also and I could change the focus there but not the zoom, anyone else able to zoom after this firmware is installed on the HDW5231R-ZE?
 
The zoom works fine on this firmware on the HDW5231R-ZE I have here - have you tried a reset to defaults or failing that rolling back to an older firmware (assuming you can)
 
No, I haven't tried the reset yet as that is a pain, but I will now that I know it works on someone else's camera. Thanks.
 
I updated the web plugin and now i can zoom and focus from the web just not from Blue Iris so at this point I think the issue is only on the Blue Iris configuration for that camera so I'll try a few more things on that side first as I probably will never want to zoom it from BI anyway as long as I can from the web for setup. Thanks.
 
Have any of you noticed the cameras rebooting on this firmware outside of the auto maintenance window?

I have syslogging enabled for all the 5231 cameras (2x Z & 1 ZE) and network switch and noticed that I'm seeing events for the cameras showing the microSD storage being added and before this happens you can see the network port goes down then up (the camera rebooting). The storage add event is what you see as the camera has booted up.

Bizarrely it happened on all 3 within seconds of each other - yet all the other cameras on my network (two Dahua PTZs and 2x Hikvisions) and 4x Unifi POE Wifi access points were stable with no signs of a reboot.

The 5231s are spread out across a 48 port switch so it's not like POE to the cluster of ports is dying.

The fact all 3 rebooted at a very similar time suggests switch or firmware, and as only the 3 5231s on this firmware had the issue I'm leaning towards the firmware.

Maybe another to report to Dahua please @EMPIRETECANDY
 
  • Like
Reactions: EMPIRETECANDY and Pneuma
reverend said:
Have any of you noticed the cameras rebooting on this firmware outside of the auto maintenance window?

I have syslogging enabled for all the 5231 cameras (2x Z & 1 ZE) and network switch and noticed that I'm seeing events for the cameras showing the microSD storage being added and before this happens you can see the network port goes down then up (the camera rebooting). The storage add event is what you see as the camera has booted up.

Bizarrely it happened on all 3 within seconds of each other - yet all the other cameras on my network (two Dahua PTZs and 2x Hikvisions) and 4x Unifi POE Wifi access points were stable with no signs of a reboot.

The 5231s are spread out across a 48 port switch so it's not like POE to the cluster of ports is dying.

The fact all 3 rebooted at a very similar time suggests switch or firmware, and as only the 3 5231s on this firmware had the issue I'm leaning towards the firmware.

Maybe another to report to Dahua please @EMPIRETECANDY
Click to expand...
How about the frequency about the rebooting?? I will check if they have any newer FW or not .
 
  • Like
Reactions: reverend
I'll pull some stats together Andy in case there are any trends - I wondered if maybe it was a memory leak or something.

I've enabled SNMP across all cameras and set up a LibreNMS system to see if anything gives a clue as to what is going on - I get CPU and network stats but not memory unfortunately on the cams but those may give a clue :)

Saying that I'm just manually analysing the syslog output and it's thrown up some very interesting trends indeed.

Here are the reboot times (the difference is the time the camera was up before rebooting) of the two 5231-Z cameras:

0


0


And then the 5231-ZE:
0


Ignore the 63 hours uptime as I didn't have syslog enabled during that period.

Straight away what stands out is that since I turned off P2P and Genetec services the cameras are all only staying up for 0.8 days (just over 19 hours) before rebooting.

Andy if it helps the engineers I can email over settings backup files for if they want to try and reproduce it.

It was the 26th July where all 3 rebooted within a minute of each other and although the times have drifted apart where I was tinkering with settings etc you can see they're all getting to 0.8 days before rebooting.

It's as though there's a timer in the camera where if it can't do something within a certain timeframe it just reboots - maybe a memory leak or similar?
 
As per the last message I set up LibreNMS which is a free SNMP monitoring solution which polls all the devices and gives graphical output for things like CPU usage, network usage and uptime on the Dahua cameras as well as other kit that supports SNMP (I tried adding my Hikvision cameras too but they didn't seem to expose any data to LibreNMS or snmpwalk).

It graphs the data for you and then you can see things really easily - like uptime:
Screenshot 2018-08-05 at 11.png

The legend on the graph is wrong as it suggests they're rebooting at 800 minutes but when you zoom into that graph it's actually the 19 hour mark again but you can easily see the sawtooth pattern that's going on where the camera is rebooting.

You can see my 59225 rebooting this morning at the auto maintain setting and you can just see the bottom of an uptime from one of my Unifi APs at over 7 days uptime (but rebooted for new firmware today).

The ones showing 80 days are my ESXi servers which need patching soon but they show the actual power etc here is stable and I normally only reboot anything to upgrade firmware or software.

CPU usage seems pretty flat on the cameras - unfortunately memory stats aren't exposed via SNMP so you can't easily see if there's a leak there:
cpu usage.png

Those images show the 5231s are pretty flat, other than the path camera which spikes a lot which is strange as video wise it's the quietest so not sure what causes the extra CPU on that camera.
 
What is the most current working firmware for IPC-HDW5231R ZE ?
I'm trying to line up my home firmware with one at a building we deployed a large amount of cameras.
 
The most stable for me so far was the November 2017 firmware.

I've rolled back one of my IPC-HDW5231R-Z to the November 2017 firmware yesterday and you can see the camera has gotten past 19 hours uptime:

upload_2018-8-15_8-36-55.png

There's definitely something wrong with the newer firmwares at least when microSD cards are in use anyway.
 
I didn't/don't know where to set up video encryption password for Lechange, P2P yet the mobile app keeps asking me for video encryption password to view the live stream.
 
reverend said:
As per the last message I set up LibreNMS which is a free SNMP monitoring solution which polls all the devices and gives graphical output for things like CPU usage, network usage and uptime on the Dahua cameras as well as other kit that supports SNMP (I tried adding my Hikvision cameras too but they didn't seem to expose any data to LibreNMS or snmpwalk).

It graphs the data for you and then you can see things really easily - like uptime:
View attachment 32096

The legend on the graph is wrong as it suggests they're rebooting at 800 minutes but when you zoom into that graph it's actually the 19 hour mark again but you can easily see the sawtooth pattern that's going on where the camera is rebooting.

You can see my 59225 rebooting this morning at the auto maintain setting and you can just see the bottom of an uptime from one of my Unifi APs at over 7 days uptime (but rebooted for new firmware today).

The ones showing 80 days are my ESXi servers which need patching soon but they show the actual power etc here is stable and I normally only reboot anything to upgrade firmware or software.

CPU usage seems pretty flat on the cameras - unfortunately memory stats aren't exposed via SNMP so you can't easily see if there's a leak there:
View attachment 32097

Those images show the 5231s are pretty flat, other than the path camera which spikes a lot which is strange as video wise it's the quietest so not sure what causes the extra CPU on that camera.
Click to expand...
Good job!!!
 
I have P2P disabled from UI but still see DNS requests for easy4ip from my Dahua IPC-HDW5231R-ZE and it tries to connect AWS. I don't see the same for IPC-HDW5231R-Z. Both are at firmware 2.640.0000002.0.R, Build Date: 2018-05-23 posted on this thread.

Also after reboot the P2P option gets back enabled!? How to disable completely?
Anyone else experienced this?
Screen Shot 2018-09-24 at 9.49.22.png
Screen Shot 2018-09-24 at 9.37.11.png

Maybe I'll test the 20180813 firmware next.

Edit: I exported the configuration, reset the configuration to default (not factory default), disabled P2P, rebooted and see it was still disabled. Then imported configuration back. Now P2P keeps disabled and don't see the traffic anymore.


Code: 
# tcpdump -vvv -i eth1.100 "udp port 53 and host 192.168.0.105"

tcpdump: listening on eth1.100, link-type EN10MB (Ethernet), capture size 262144 bytes

09:34:46.208924 IP (tos 0x0, ttl 64, id 27677, offset 0, flags [DF], proto UDP (17), length 72)

    192.168.0.105.53570 > lede.lan.53: [udp sum ok] 52573+ A? devaccess.easy4ipcloud.com. (44)

09:34:46.209028 IP (tos 0x0, ttl 64, id 19658, offset 0, flags [DF], proto UDP (17), length 166)

    lede.lan.53 > 192.168.0.105.53570: [bad udp cksum 0x825e -> 0xe283!] 52573 q: A? devaccess.easy4ipcloud.com. 3/0/0 devaccess.easy4ipcloud.com. [2m54s] CNAME drs-fk-1362203262.eu-central-1.elb.amazonaws.com., drs-fk-1362203262.eu-central-1.elb.amazonaws.com. [54s] A 3.120.61.170, drs-fk-1362203262.eu-central-1.elb.amazonaws.com. [54s] A 54.93.160.208 (138)

09:34:51.867232 IP (tos 0x0, ttl 64, id 27795, offset 0, flags [DF], proto UDP (17), length 72)

    192.168.0.105.52077 > lede.lan.53: [udp sum ok] 18021+ A? devaccess.easy4ipcloud.com. (44)

09:34:51.867341 IP (tos 0x0, ttl 64, id 19834, offset 0, flags [DF], proto UDP (17), length 166)

    lede.lan.53 > 192.168.0.105.52077: [bad udp cksum 0x825e -> 0x6f60!] 18021 q: A? devaccess.easy4ipcloud.com. 3/0/0 devaccess.easy4ipcloud.com. [2m49s] CNAME drs-fk-1362203262.eu-central-1.elb.amazonaws.com., drs-fk-1362203262.eu-central-1.elb.amazonaws.com. [49s] A 54.93.160.208, drs-fk-1362203262.eu-central-1.elb.amazonaws.com. [49s] A 3.120.61.170 (138)

09:34:53.768048 IP (tos 0x0, ttl 64, id 27956, offset 0, flags [DF], proto UDP (17), length 61)

    192.168.0.105.51495 > lede.lan.53: [udp sum ok] 31597+ A? www.easy4ip.com. (33)

09:34:53.768143 IP (tos 0x0, ttl 64, id 19934, offset 0, flags [DF], proto UDP (17), length 158)

    lede.lan.53 > 192.168.0.105.51495: [bad udp cksum 0x8256 -> 0x184e!] 31597 q: A? www.easy4ip.com. 3/0/0 www.easy4ip.com. [30s] CNAME p2pweb-fk-1138989288.eu-central-1.elb.amazonaws.com., p2pweb-fk-1138989288.eu-central-1.elb.amazonaws.com. [30s] A 52.28.9.4, p2pweb-fk-1138989288.eu-central-1.elb.amazonaws.com. [30s] A 52.57.28.20 (130)

09:34:57.588005 IP (tos 0x0, ttl 64, id 28338, offset 0, flags [DF], proto UDP (17), length 72)

    192.168.0.105.34132 > lede.lan.53: [udp sum ok] 55918+ A? devaccess.easy4ipcloud.com. (44)

09:34:57.588087 IP (tos 0x0, ttl 64, id 19967, offset 0, flags [DF], proto UDP (17), length 166)

    lede.lan.53 > 192.168.0.105.34132: [bad udp cksum 0x825e -> 0x2182!] 55918 q: A? devaccess.easy4ipcloud.com. 3/0/0 devaccess.easy4ipcloud.com. [2m43s] CNAME drs-fk-1362203262.eu-central-1.elb.amazonaws.com., drs-fk-1362203262.eu-central-1.elb.amazonaws.com. [43s] A 3.120.61.170, drs-fk-1362203262.eu-central-1.elb.amazonaws.com. [43s] A 54.93.160.208 (138)

09:34:58.712781 IP (tos 0x0, ttl 64, id 28382, offset 0, flags [DF], proto UDP (17), length 66)

    192.168.0.105.37166 > lede.lan.53: [udp sum ok] 4238+ A? www.easy4ipcloud.com. (38)

09:34:58.712862 IP (tos 0x0, ttl 64, id 20053, offset 0, flags [DF], proto UDP (17), length 194)

    lede.lan.53 > 192.168.0.105.37166: [bad udp cksum 0x827a -> 0x2c4a!] 4238 q: A? www.easy4ipcloud.com. 8/0/0 www.easy4ipcloud.com. [23s] A 52.29.55.151, www.easy4ipcloud.com. [23s] A 18.195.211.66, www.easy4ipcloud.com. [23s] A 18.196.59.57, www.easy4ipcloud.com. [23s] A 18.195.41.243, www.easy4ipcloud.com. [23s] A 52.29.242.163, www.easy4ipcloud.com. [23s] A 18.196.36.18, www.easy4ipcloud.com. [23s] A 18.196.36.68, www.easy4ipcloud.com. [23s] A 18.194.213.49 (166)
 
Last edited:
EMPIRETECANDY said:
Hey guys

Here we go for the latest new firmware (with Dahua logo or no logo )for the IPC-HxW5XXX, this suits for most cams we posted here, before updating, please check carefully if your camera support or not.

DH_IPC-HX5X3X-Rhea_Internal_PN_Stream3_V2.640.0000002.0.R.180523.bin



IPC-HDW5231R-Z/ZE
IPC-HFW5231E-Z/Z5/Z12/ZE/Z5E/Z12E
IPC-HDBW5231R-Z/ZE
IPC-HDBW5231E-Z/ZE
IPC-HDW4231EM-AS/ASE, IPC-HDBW4231F-AS, IPC-HDBW4231E-AS/ASE , IPC-HFW4231S,IPC-HFW4231E-S/SE.

And all models with DH_IPC-HX5X3X-Rhea also can use this one, new firmware can select PAL/NTSC. So future all cams will no PAL or NTSC, this is good for some guys, because they always think PAL can't work at US or NTSC can't use at PAl regions.


Andy
Click to expand...

Thanks Andy!

Works OK on my
Device Type IPC-HFW4830E-S
System Version2.640.0000002.0.R, Build Date: 2018-05-23
 
  • Like
Reactions: EMPIRETECANDY
You must log in or register to reply here.
Top Bottom