Hass crashes Aeotec Gen 5 zwave stick #5501
Comments
|
Start by checking if stop and then start home assistant produces the same error. The log you provide looks good. All normal. What does the ozw_log.txt show after restart when the error is present? |
|
I mean, the complete logoutput for ozw_log |
|
Restart and stop/start both produce the same error. The full log for starting with a failing stick: And then it just sits there. |
|
Looking at the logs for shutting down, I notice that HA shutting down has a few extra lines: Which shutting with Domoticz or ozwcp doesn't produce. Home ID 0xca4e8fa0 is ok, but the 900821088 part? I've never seen that anywhere. Is HA trying do something here? |
|
Ok, after looking at the code and logs I have found the following: The log lines that are printed in HomeAssistant are printed because we use the python-openzwave wrapper, and the wrapper issues some extra commands at network stop to check that the network is really stopped. https://github.com/OpenZWave/python-openzwave/blob/master/src-api/openzwave/network.py#L390-L431 |
|
Thanks! Will double check all permissions and test. Will double check all settings and make sure hass hass write everywhere and report back. Thanks for looking into it! |
|
Ok, checked everything.
As I said: |
|
The thing is that this all happens outside HA. There is no Zwave managing code in HA, that is all done by OZW. And we tap in to the values of the network. Meaning if the network provides no devices, HA will not see any devices, and OZW will save the network config to be 0 at stop. |
|
Ok, I see where you're coming from, and I agree. |
|
First time github user here, I've got the same error. Started with a fresh install of raspbian with the AIOI, 90% of restarts end with a crash. Rebooting the pi fixes this and everything loads correctly. |
|
Can you please confirm that:
If the above are true, can you confirm that removing the stick and plugging it in again also solves the problem? (Rebooting could solve other problems if there are any, which wouldn't necessarily isolate this issue) |
|
Yeah, I'm using an Aeotec Gen5 and it crashes when stopping. However I'm unable to reproduce the same results this evening. |
|
Have a very similar setup. ESXi on a mac mini, with a Aeotec Gen 5 usb stick. And i'm not running into this issue. Do you have any secure zwave devices? (door locks etc?) I also noticed that if some of my nodes don't have great signal the shutdown process can take a lot longer. |
|
Yes, I'm running two secure devices. A Fibaro Wall Plug Gen 5 and a motion sensor Gen 5. And I have a strong feeling this started when those were added. I had to add the network key to a second file by the way, which might be interesting. When I first added the network key I did it here: After that I noticed HA not being able to switch this devices. After a lot of debugging I noticed there was a second options.xml, which HA was using: Signal isn't an issue, the devices are close to the controller and working fine. It's only the shutdown by HA which locks the stick. |
|
Hmm.. wait.. triggering myself. I changed openzwave configs for the two gen5 nodes to get them working. Those changes were done in /edit Did that before, must have removed it.
This could be a problem, considering the changes to configs above. Will test later tonight. |
|
Ok, checked, I did provide a config_path. I just didn't pushed it to my GitLab, that's why I missed it above. |
|
Interesting.. Stop HA, stick "crashes", start HA, no zwave as logs above show. Stop HA, start again, stick works and reports devices. Was able to reproduce that multiple times yesterday. Running out of options to debug this problem. Checked everything I could think off. Pretty annoying problem. |
|
Did you add the secured devices via HA or via other means? |
|
I added them via ozwcp just like all my devices. Now that's strange if that's the case. And it is not cool to test because of id changes. Ok, not that hard to do but still. |
|
I'm not sure it was exactly the same, but I had issues with secure device added via ozwcp probably because they looked at different options.xml |
|
Upgraded to 0.40.0, pulled python-openzwave for latest changes and recompiled it. |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 |
|
I am having this issue, I think. I'm a new user. Running Ubuntu 16.04 VM on top of ESXI with the Aeon Gen5 usb plugged in. I'm able to add a node (light) in HA - it blinks to confirm it's been added - but I don't see a device anywhere in HA. I am also able to remove it. As far as I know I'm not getting a crash, just this: Here is the logs, the last thing I did was Stop Network. |
|
Oh wait, I just hit Start Network and the node is not appearing. Weird. Hope this helps. |
|
This is in no way the same issue. Can't see your stick locking up in the logs :) -- I followed most upgrades, and when I upgraded to 0.45.1 with the "bundled" zwave the problem seems not reproducible anymore. No clue, but it seems to be fixed. Will report back if it is reproduced. |
|
I'm running Hass in Docker on a Synology together with an Aeon Z-stick and are experiencing similar problems. Whenever I restart Hass, the Z-stick no longer works.
I tested this procedure as well, and it actually seems to works. At least once. |
|
Just upgraded to 0.47 and at first restart of HA got the same problem again. As @binbin2000 says, same here, second restart and it works. |
|
@rossdargan That is your stick that has failed. Home id is 0000000. |
|
Now it is August 2018 and I am having the same problem. Running HASSIO on Rasp Pi3. Everytime I restart the drivers get unloaded and I have to reset the Aeotec USB stick and re-pair Zwave devices to recover. Has there been any progress made on this issue? |
|
I have the same zwave stick and don't have this issue at all. Running HA 0.73.2 in a virtual environment with 7 zwave plus devices. |
|
I just experienced this today for the first time ever. Same error messages in both the HA and OZW logs. Hard takedown of my Pi and a few HA restarts finally resolved my panic though. I moved a few months ago from one pi running an old AIO install at 0.65 to a new pi running hass.io. I've been upgrading to current versions and doing restarts both warm (HA only) and cold (Hassio Host) prior to this without any issues until today. I was running 0.78.1 but due to CC/Google TTS issues I downgraded to 0.77.3. That's when this happened. Let me know if I can provide any further info to help. |
|
I'm having this on Hassio using HA on 0.81.6 on rpi3+. Been happening for months on older versions also. Just restarting HA using Configuration/General/Restart does NOT cause it. However if I go to HASS.IO/System/Reboot Host System or I cold boot the rpi by unplugging/replugging power supply happens EVERY time. Also happens to my zigbee2mqtt stick, but a simple press of the little button on the stick and a stop and start of the zigbee2mqtt addon gets it back online. However I have to fight this zwave stick for an hour or more to finally get it back online. Replugging the stick and restarting HA doesn't cut it for me. If HA hangs up and won't restart, I know I'm in for trouble because I will have to restart the host system. |
|
Is there some progres with someone to solve this? I now experience the same problem on my Intel Nuc. What strikes me most is that after a second restart of HA, I just get back my zwave nodes. And that the problem is probably in this line in the OZW_Log.txt: "Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt (s)". The controller is temporarily unavailable for a moment, so HA is skipping and you will not see anything, at least I assume that I have to explain it so. The only question now is how do you solve this? |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 |
|
Is this still an issue you are experiencing? Can you please try upgrading to the latest version of Home Assistant (0.90) and report back if this is still a problem? Thanks! This is similar to #21165 |
|
I saw the issue once where with 0.90. I had to restart once to make the stick come alive. I reported #21165 which for the most is the same issue. I find it sad if this severe issue gets closed without a fix. I am personally using z-wave for doors and window sensors and two sirens as a security system. And I have taken the consequence of the poor performance of z-wave in Home assistant to migrate away from z-wave. I have already replaced 4 of my 10 sensors with wifi based sensors and the remaining windows have now additional 433 MHz sensors. I simply cannot trust the z-wave network. I think z-wave should be considered a key basic foundation feature in a home automation system and I wonder why a bug like this is allowed to stay open since 2017 and now being considered closed with no action. What is Lovelace and other cool bells and whistles worth if the foundation is not stable? Z-wave is so essential in the world of home automation. |
|
Issue still exists. It happens when HA restarts. I have to wait about 2 minutes to system kills the HA service. Raspbian, Python 3.7.2, venv, HA 0.90 |
|
@bieniu thanks for reporting back on this one. I can entirely understand your frustrations with this specific bug as a Z-Wave user. Sadly, we are really at the mercy of the OpenZWave project for things like this. You may be interested to listen to the most recent episode of the Home Assistant Podcast in which Paulus gets into detail about our potential plans to build our own Z-Wave stack. Don't worry, I'm not closing this. @ocatelle just asked for a status update because I asked him to. |
|
I just reproduced it again. |
|
@KennethLavrsen sorry, it's late here in California and I thought @bieniu had left both update comments, so thanks to you as well for reporting back. I can try to help triage this a bit more for you in the morning. In the meantime, if you want to go above and beyond in helping me, can you take a look at the OpenZWave and python-openzwave issues to see if there's anything similar there? If you don't have time i'll take a look in about 8 hours when I wake up. |
|
@robbiet480 I'm not complaining. I'm a patient user and full of admiration for the hard work of HA developers. I learned to live with this issue. The problem occurs when I don't restart the HA for a long time. Over a week of continuous work is needed. Sometimes after this error, the HA doesn't start without restarting the entire system (there is nothing special in the log). The start of the HA stops at "Starting Z-Wave network ...". |
|
@bieniu yeah sorry, as I just said, I got you and @KennethLavrsen confused :) |
|
@robbiet480 We write too fast ;) As @KennethLavrsen writes, you can quickly reproduce issue by restarting HA several times with less than a minute between (before the "Z-Wave network is complete" in log). |
|
I will gladly scan through some of the bugs of the upstream projects. I am in the EU time zone (Denmark) so I need to get off from work first but I am home alone Saturday so I also have some reading time available there. |
|
OZW author here. Just a few thoughts:
regarding the messages at shutdown: Thats something the python wrapper does and is harmless... |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
|
We know that most people have a problem on machines that have Modem Manager installed and that the issue is that when a Docker is restarted it runs udev and initiates Modem Manager. Result is that both during boot and during restart the Modem Manager and HA tries to talk to the Aeotec stick. The easy work around is to disable Modem Manager. systemctl disable ModemManager.service The documentation for HA has had this addressed now but the documentation suggests to purge the ModemManager from the system. This however can have negative effects on distros with Gnome desktops so best advice is to disable the service. I still believe HA should be coded to take an approach that allows people that may need ModemManager or simply have not seen or understood the documentation. Modem Manager only runs for a few seconds so HA could simply retry maybe 30 seconds after a failed init and the user would be happily ignorant about the issue. There are so many other integrations that have mechanisms to reconnect when the link fails. That would be the best solution. But at least with the documentation update people can now use the stick. |
This did the trick for me when encountering this issue using the Zwave2MQTT container! |
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. |
and others
Home Assistant release: 0.40.0
Python release: Python 3.5.2+
OpenZwave: 1.4.2253
Component/platform: zwave
OS: Ubuntu 16.10 running on ESX 6.0.0 U2, Intel NUC6I3SYH
Description of problem:
Restarting Home Assistant results in the Aeotec Gen 5 Z-wave stick needing a poweroff/poweron to start working again. It looks like being hung up at stop of Home Assistant, and reports 0 devices at startup.
Expected:
To be able to restart Home Assistant without the zwave stick hanging up.
Problem-relevant
configuration.yamlentries and steps to reproduce:Zwave logs report the following in the faulty situation:
I cannot reproduce this using Domoticz or OZwcp. Restarted those countless times and not a single problem. Restart Home Assistant and the stick dies. No clue where to start troubleshooting.
Extra information;
I symlinked the xml:
/home/hass/.homeassistant/zwcfg_<homeid>.xml -> /srv/hass/src/open-zwave-control-panel/zwcfg_<homeid>.xmlSince Home Assistant wrecked the xml a few times, I figured it didn't need write access and just set read-only for the hass user. After remembering that, I figured that might be a problem, and tried with write access, same result.
As far as I can remember, it looks like this started when I added secure nodes to the network. Might have something to do with it.
Further details, hass is showing clean logs, as is OZW_Log.txt on a shutdown of the network. All looking good. Until trying to restart.
OZW_Log.txt at shutdown by Home Assistant:
Shutdown by ozwcp:
Additional info:
Just a side thought, why do we restart the zwave network every time we need to restart for a config change?
The text was updated successfully, but these errors were encountered: