-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compatible firmware #1
Comments
Did you do these tests with the latest 0.0.7 version, or the previous 0.0.6 version? I don't believe the PR to bump HASS up the 0.0.7 has been merged into stable yet. The 0.0.6 version uses a hard coded XML namespace which it seems may not match as many cameras as I though it did so I made the XML namespace discovery dynamic in the 0.0.7 version. If you were on the 0.0.7 version could you post some XML samples from the cameras when they are running a firmware version that produces the error? It's more than likely just an XML formatting change that I should be able to easily accommodate. |
I found 0.0.6 was under the deps directory and 0.0.7 was in dist-packages.
I tried a simple test of pyHik from command line and it failed on loading
pydispatch, so I will assume that the deps version (0.0.6) is running in
hass, because pydispatch is also in "deps".
Unfortunately (for troubleshooting) , I have since upgraded my 5 cameras
to 5.4.0 , and all are working fine.
I have never successfully downgraded a camera, so I won't be much help for
XML samples since all mine are working.
If you have any additional test or confirmations you need, I'll be glad to
help any way I can.
boverby
…On Thu, Dec 29, 2016 at 4:51 PM, John Mihalic ***@***.***> wrote:
Did you do these tests with the latest 0.0.7 version, or the previous
0.0.6 version? I don't believe the PR to bump HASS up the 0.0.7 has been
merged into stable yet.
The 0.0.6 version uses a hard coded XML namespace which it seems may not
match as many cameras as I though it did so I made the XML namespace
discovery dynamic in the 0.0.7 version.
If you were on the 0.0.7 version could you post some XML samples from the
cameras when they are running a firmware version that produces the error?
It's more than likely just an XML formatting change that I should be able
to easily accommodate.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGgk3U2DNshVA2y1LqkRWKt3YbwGBSOSks5rNCtwgaJpZM4LWjza>
.
|
Also, as another data point, this library was developed with two cameras, both on V5.3.0 build 150513 firmware, which you seemed to have issues with. So maybe there is something else at play here. |
Since you mentioned the build number, I recall that on other programs
following the IPMD docs from v1.4.4 and v2.0, I frequently ran into onvif
commands that would stop working or act differently between 5.x.0 and 5.x.N
versions of the firmware. I have also made the mistake of skipping a
revision level ( 5.1.x to 5.3.0) and having to revert back with a hard tftp
upgrade (no fun). That might be the extra sauce in the mix. If yours were
virgin 5.3.0, and mine were migrated versions, there may have been some
additional differences we will never know.
…On Thu, Dec 29, 2016 at 6:08 PM, John Mihalic ***@***.***> wrote:
Also, as another data point, this library was developed with two cameras,
both on V5.3.0 build 150513 firmware, which you seemed to have issues with.
So maybe there is something else at play here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGgk3WJXBiNzh-JFYrVw31iAZf_o4YDvks5rND1ugaJpZM4LWjza>
.
|
Im experiencing the same issue with V5.4.0 build 160826 where its flooding the logs with list index out of range. Previous,y was on 5.3.4, and that was also having the same issue, decided to upgrade thinking it would resolve and no go. There was no interim release from LTS (rebranded firmware - not directly Hik) so I had to go straight to the latest. On the other hand, I have another camera (EU version) running on V5.4.4 build 161125 and that works fine without issue and able to see all the binary sensors associated (line crossing, motion, etc). If there's further logs or testing I could perform, let me know as I'd like to get this working inside of Home Assistant. Thanks! |
See my reply to your issue on the HASS repository. You're running one version behind on the pyHik library. Your LTS camera should work with pyHik 0.0.7. |
I have two DS-2CD2532F-IWS cameras, (chinese version) with fw V5.2.5 build 141201 onboard. I get all motion, line detection and Intrution detection sensors triggered, but after a while, these sensors stop updating (in e.x HA). |
The cameras used for development were both on V5.3.0 build 150513. I have not personally tested with anything else. If the updates stopping is repeatable, please turn on debug logging for the component in HASS and look for any instances of the connection being dropped. There is logic to reconnect automatically, but something may be getting hung up somewhere. |
I did a new test with 2CD2142 V5.4.0 build160511 which I borrow at work. |
Can you post the debug log? |
At the moment, the line crossing and field detection is hung up, since I restarted HASS: |
The key to debugging is enabling it for pyHik, not so much the HASS hikvision component. Add the following to your logger settings: pyhik.hikvision: debug |
Good tip! I have activated logging now, and I can see all the event changes. I'll check the log after a while. |
I have now got the logs filling up, and lost the events from the cameras at around 17:04 tonight. 17-01-25 00:52:03 homeassistant.loader: Unable to find component switchWD |
You have lots of network errors in that log, not just from pyHik, but multiple other components. What platform are you running HASS on? Can you ping the cameras from the HASS host after the updates stop? |
Hi, |
The only thing I can think of, given all your connection errors, is that the stream is getting corrupted in such a way that it's not disconnecting, but it's also no longer producing usable output. If I remember correctly the "videoloss" alarm is continuous within the event stream so I suppose I could possibly use that as a keep-alive message. Would you be able to do a simple curl request direct to your camera event stream and post the output here after letting it run for 60s or so? From your logs, I still believe the root of your problems lies in networking, but i'm willing to work with you to make the connection lost/reconnect methods more robust and hopefully work around your issue. |
The log is really not representative of how my connections are. I usually get +-5 connection error in 24 hours. Not sure why I got all those in the previous log. |
I think most of the Pi distributions have curl installed by default. Try the following command in an ssh window replacing the relevant details with the correct ones for your setup. curl -u USER:PASS http://YOURCAMIP/ISAPI/Event/notification/alertStream It should start dumping a bunch of XML into your session from the stream. Let it run for 15-30seconds then break the connection with CTRL+C. Post the output here. |
Here is my log: |
Ok, you also get a repeated 'videoloss' event when connected to the stream so I can use that as a connection check. Give me some time to work in the changes and i'll have you do some testing. |
I put together a simple watchdog class and implemented it to monitor the event stream. I think this should fix your issue, but it's hard for me to test. In order to minimize the HASS interactions i've pushed the changes to a new testing branch you can find here: https://github.com/mezz64/pyHik/tree/watchdog-test Please download that branch to your PI and edit the "test_simple.py" file to match up with the settings for a camera you are having problems with. Once the file is correct run it from your ssh session with: If all is well you should get the camera name, id, and supported events printed in the shell and a log file named "api_out.log" should be created in the same directory. The log file will catch all pyhik actions and should let me know if things are working as expected. Feel free to check it periodically and make sure events are being logged. Upload it here after a 24hr run. It may also be beneficial to start this test in conjunction with a fresh start of HASS. That way I can compare HASS logs with the logs from the watchdog version. |
Hi, pi@HomeAssistant:~/Documents/pyHik-watchdog-test $ python3 test_simple.py |
Quick solution is to install pydispatcher through pip. The command below should get it in the right place for your python3 install. sudo python3 -m pip install PyDispatcher |
Here is my 24 hour log: 02/06/2017 07:54:20 PM Initializing new hikvision device at: http://192.168.1.254 |
Ok, so it looks like everything stayed connected just fine for the complete 24hrs, correct? Did the HASS version stop itself during this same time period? I don't see any instances of the watchdog or connection reset mechanisms kicking in during your test so there may be something weird going on with the pyhik/hass interaction on your system. |
Yes the HASS version stopped registering the line detections pretty quick after I restarted HASS, yesterday at around eight oclock afternoon. |
What other components are you running in HASS along with hikvision? Have you tried running a HASS instance with just the hikvision component setup? |
I have not tried that, but I have noticed that when I run generic cameras (hikvision) together with binary sensors (hikvision), it seems to be more unstable. Other components are Hue, sonos, some mqtt, snmp... |
Watchdog and improved notification functionality are now available in 0.0.9 and should show up in the next version of HASS. I'm closing this issue for now. Please open a new one if issues persist after using 0.0.9. |
Thank you for your support. Im looking forward to test v 0.0.9 in Hass. |
Thank you for contributing phHik. When using homeassistant, I ran into the log filling up with the error
16-12-27 20:53:30 pyhik.hikvision: Problem finding attribute: list index out of range
My experience with hikvision firmware leads me to believe this a firmware related problem.
I am documenting my experiences to save other people some head scratching:
hikvision firmware V5.2.0 build 140721 (works)
hikvision firmware V5.3.0 build 150327 ( list index out of range)
hikvision firmware V5.3.0 build 150327 ( list index out of range)
hikvision firmware V5.3.0 build 150513 ( list index out of range)
hikvision firmware v5.3.3 build 151019 (works)
Looks like 5.3.0 has a problem, firmwares below and above that seem to work fine. The first solution for problems might be to upgrade the firmware on the camera.
@boverby
The text was updated successfully, but these errors were encountered: