I have a Z-Wave.Me UZB using the Z-Wave integration on 0.97 (saw this on 0.95 too, just upgraded):
When I restart Home Assistant, it appears my ozwcache_0xdeadbeef.xml file wipes itself–at least, all the query stage “complete” devices are removed. I started running:
while I restart and a few seconds after startup all the lines disappear.
Is this expected? It doesn’t seem so from what I’ve been reading. I see a lot where people basically have the opposite problem and need to delete their cache, mine is all too happy to do it for me. Can/should I stop this?
I think this problem may go away if I fix #1, but when these devices get wiped from the cache (I think), they disappear from the list of nodes in the Z-Wave configuration UI, and from the dashboard (usually*), until they reach QueryStage “complete”. I realize that the battery powered devices not completing all query stages quickly is expected, and that “these devices will continue to operate normally while this process takes place” as I’ve seen multiple people reiterate–but the devices disappearing from the list of nodes and from the Lovelace UI is not “continuing to operate normally”.
This is a particular problem because I’m trying to use the HomeKit hub integration, and when HomeKit starts up and HA is missing the devices, the devices don’t get published to HomeKit…which is a real bummer because they get wiped from their HomeKit rooms any any automations, of course. This is especially problematic for battery powered devices because they never come up in time for HomeKit’s start (I already have that on a 5-minute delay automation, per the setup recommendation)–there’s no way the query will be complete in a reasonable amount of time for them to show up before the HomeKit automation starts.
“usually”: I see some disparity between the cache file, configuration nodes list, and what’s in the Lovelace UI (still using only the default view). Right now, for instance, I have two Monoprice/Vision ZP3111 motion sensors that do not show in the cache xml file, but they do show in the dashboard UI and Config > Z-Wave > Nodes list. I guess this is normal? But I also have a Monoprice/Hank door sensor that shows in the Nodes list, but not in the cache file and not in the dashboard UI. I’m not sure what the relationship is or why this happens. I’ve seen worse craziness in the last few days, but attributed that to the Aeon Labs Energy Meter that was crashing OZW when I tried to add it secure (now it’s not crashing, but not updating…guess that’s next…)
ozwcache_*.xml is generated by OpenZWave 1.6. HA uses OZW 1.4, which generates the file zwcfg_*.xml. Make sure you’re looking at the zwcfg file. Did you run the OZW Control Panel or some other program that would have been using OZW 1.6?
I’m on macOS (in a venv), and if I recall correctly, HA’s pyozw wouldn’t build until I installed OZW via brew (and added the lib directory to the dylib path)–and something gave me the impression that 1.6 was the right one (think it’s the only one in brew perhaps)…I specifically remember reading some post saying that the OZW in brew was too old, but checked and it was the latest version (1.6), so perhaps that made me assume latest was good… anyway…
Now what? If I can downgrade the brew installed OZW in /usr/local will that be better or worse?
HA will install OZW by itself, when it installs the python module, so there’s nothing extra to install manually. You may need some compiler tools and libraries in order to install/build the python module, but you don’t want to install OZW outside of the venv. You should uninstall the version provided by brew completely (make sure all the config files in /usr/local/etc are gone).
I think I’ve done that. And wiped out my homeassistant venv dir, starting over for now. But I’m getting the following during onboarding when trying to set up the Z-wave integration:
...
File "/Users/username/homeassistant/lib/python3.7/site-packages/openzwave/option.py", line 29, in <module>
import libopenzwave
ImportError: dlopen(/Users/username/homeassistant/lib/python3.7/site-packages/libopenzwave.cpython-37m-darwin.so, 2): Library not loaded: /usr/local/opt/open-zwave/lib/libopenzwave-1.6.dylib
Referenced from: /Users/username/homeassistant/lib/python3.7/site-packages/libopenzwave.cpython-37m-darwin.so
Reason: image not found
The dylib is not there–that’s correct. But it’s like it’s dragging this already compiled libopenzwave.cpython binary out of some global cache somewhere and it’s still linked to the upstream .so that’s been removed. How do I clear this out??
The wait when onboarding the integration is very short–I’m pretty sure it’s not compiling anything meaningful, and nothing appears in the logs until this stack trace. After that short wait, I do see:
> pip3 list | grep ozw
homeassistant-pyozw 0.1.4
which was not there before. Uninstalling it with pip3 doesn’t help, it comes back and has the same problem.
I should add I’ve tried deleting all the open-wave stuff out of the venv site-packages…but of course I’ve started with a brand new venv (twice now) too, so it’s not that. It seems it must be getting those files from a global location… but my python-fu is weak. I’ve done a locate wave and looked for likely offenders but can’t find anything.
What version of Mac OS are you running? On my Mac with 10.14.6 and a python test venv, I was able to install the homeassistant-pyozw module successfully, but I had to set an environment variable. Basically, I did this from scratch:
$ python3 -m venv testenv
$ cd testenv
$ source bin/activate
$ pip install wheel # i don't think there are macos python wheels for ozw, so this probably isn't necessary
$ export MACOSX_DEPLOYMENT_TARGET=10.9
$ pip install --log /tmp/pyozw.log --no-cache-dir homeassistant-pyozw
Collecting homeassistant-pyozw
Downloading https://files.pythonhosted.org/packages/2e/48/ffc8e03c7249a68bdf35bc5e9fa2af2222acab16eb4f0022d7626c34e83a/homeassistant_pyozw-0.1.4.zip (147kB)
100% |████████████████████████████████| 153kB 12.9MB/s
Requirement already satisfied: six in ./lib/python3.7/site-packages (from homeassistant-pyozw) (1.12.0)
Requirement already satisfied: PyDispatcher>=2.0.5 in ./lib/python3.7/site-packages (from homeassistant-pyozw) (2.0.5)
Installing collected packages: homeassistant-pyozw
Running setup.py install for homeassistant-pyozw ... done
Successfully installed homeassistant-pyozw-0.1.4
You are using pip version 19.0.3, however version 19.2.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
~/src/testenv 1m 42s
$ python
Python 3.7.4 (default, Aug 18 2019, 19:49:31)
[Clang 7.1.0 (tags/RELEASE_710/final)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import openzwave
>>>
Without the export MACOSX_DEPLOYMENT_TARGET=10.9 I was getting a linker error. You can examine the verbose log file to see if there are any compiler errors, or how it’s compiling.
I am also using Nix to install python3, not homebrew. I’ve never installed OZW via brew.
Maybe a reboot is in order to clear some caches? Also make sure you’re version of the XCode command line tools are the latest version. I did have an upgrade available, not sure if that mattered.
(homeassistant) username:homeassistant > export MACOSX_DEPLOYMENT_TARGET=10.9
(homeassistant) username:homeassistant > pip install --log /tmp/pyozw.log --no-cache-dir homeassistant-pyozw
Collecting homeassistant-pyozw
Downloading https://files.pythonhosted.org/packages/2e/48/ffc8e03c7249a68bdf35bc5e9fa2af2222acab16eb4f0022d7626c34e83a/homeassistant_pyozw-0.1.4.zip (147kB)
|████████████████████████████████| 153kB 928kB/s
Requirement already satisfied: six in ./lib/python3.7/site-packages (from homeassistant-pyozw) (1.12.0)
Requirement already satisfied: PyDispatcher>=2.0.5 in ./lib/python3.7/site-packages (from homeassistant-pyozw) (2.0.5)
Building wheels for collected packages: homeassistant-pyozw
Building wheel for homeassistant-pyozw (setup.py) ... error
ERROR: Failed building wheel for homeassistant-pyozw
Running setup.py clean for homeassistant-pyozw
Failed to build homeassistant-pyozw
Installing collected packages: homeassistant-pyozw
Running setup.py install for homeassistant-pyozw ... error
ERROR: Command errored out with exit status 1: /Users/username/homeassistant/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/private/var/folders/pl/qrsmdmtx66l924k747v067wc0000gn/T/pip-install-d665l5av/homeassistant-pyozw/setup.py'"'"'; __file__='"'"'/private/var/folders/pl/qrsmdmtx66l924k747v067wc0000gn/T/pip-install-d665l5av/homeassistant-pyozw/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /private/var/folders/pl/qrsmdmtx66l924k747v067wc0000gn/T/pip-record-ih87pz3r/install-record.txt --single-version-externally-managed --compile --install-headers /Users/username/homeassistant/include/site/python3.7/homeassistant-pyozw Check the logs for full command output.
Which turned out to be this in the log output:
2019-08-28T20:54:04,301 fetching https://raw.githubusercontent.com/home-assistant/python-openzwave/hass/archives/open-zwave-hass-0.1.4.zip into openzwave-embed/open-z
wave.zip for version 0.1.4
2019-08-28T20:54:04,469 error: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)>
2019-08-28T20:54:04,487 ERROR: Failed building wheel for homeassistant-pyozw
Which was easy, I had to run the Install_Certificates.command script you can easily find on the net…
Then I got this next in the verbose log:
2019-08-28T21:05:34,301 error: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.9" but "10.14" during configure
2019-08-28T21:05:34,327 Cleaning up...
Okay… I’m on 10.14, but so are you… it doesn’t like the 10.9 value it seems… lets try 10.14…
I originally found the answer here w/o an explanation. The error messages matched and it happened to work.
It has something to do with libc++ vs. libstdc++. Sounds like 10.9 is when Apple dropped libstdc++ in favor of libc++. The pyozw build script is linking with libstdc++, I guess setting the deployment target forces it to use libc++ instead, or something like that.
I can’t say why 10.9 didn’t work for you, but maybe anything 10.9 or up works. Could be related to your version of Xcode, or maybe how your Python was compiled.