So when installing on a raspberry pi running raspbian, after installing Openzwave from sources after installing libopenzwave-dev, I was getting a symbol lookup error when homebridge was attempting to fire up the plugin:
symbol lookup error: /usr/lib/node_modules/homebridge-openzwave/node_modules/openzwave-shared/build/Release/openzwave_shared.node: undefined symbol: _ZN9OpenZWave7Options3GetEv
I was able to resolve this and ultimately get this working on raspbian and learned a lot about the nuance of installing this on that platform and wanted to document it here in case anyone else comes here with the same intention I had of installing this on an already running RaspberryPI3/Raspian system running homebridge (as a systemctl service too!)
Short version:
The crux of this issue is that if one installs openzwave from sources (currently 1.6) then does apt-get install libopenzwave1.5-dev then the 1.5 version of the lib will become the new system default and when building homebridge-openzwave it'll be linked against that lib which is missing the symbol indicated in the error. Installing from sources installs the 1.6 version of the include headers, so installing the libopenzwave1.5-dev package is redundant. Doing so after installing 1.6 from source will cause the plugin to be built linking to 1.5 which is missing the symbols indicated. Fix this by uninstalling the build homebridge-openzwave:sudo npm -g uninstall homebridge-openzwave (or using the webUI from config-x) and then nuking the libopenzwave1.5-dev package:
sudo apt-get remove libopenzwave1.5-dev
Deep dive:
Learnings about Raspberry PI install:
Installing OZW dev package 1.5 after installing OpenZwave (currently 1.6) links libopenzwave.so.1.5 (the 1.5 version) as the system libopenzwave.so in
/usr/lib/arm-linux-gnueabihf/ causing the build of homebridge-openzwave to be linked against the 1.5 version as was evidenced by the error I first encountered:
homebridge: symbol lookup error: /usr/lib/node_modules/homebridge-openzwave/node_modules/openzwave-shared/build/Release/openzwave_shared.node: undefined symbol: _ZN9OpenZWave7Options3GetEv
One would ask, why don't you then install openzwave via apt-get and then install the lib and then build. Well, I did that and building-installing homebridge-openzwave failed with source headers not being found:
find: ‘/usr/local/include/openzwave//’: No such file or directory
Sure enough the source headers from apt-get are shoved into /usr/include instead of /usr/local/include, as is the rest of the openzwave environment. But my node environment was relying on /usr/local/include/
I could have gone to town symlinking stuff into alternate directories but that felt gross to me, so instead I built openzwave from sources.
So the steps that worked for me were to blast away the 1.5 dev package, then install OpenZwave1.6 from sources:
sudo apt-get remove libopenzwave1.5-dev
wget http://old.openzwave.com/downloads/openzwave-1.6.1123.tar.gz
tar zxvf openzwave-1.6.1123.tar.gz
cd openzwave-1.6.1123
make
sudo make install
the default prefix for make install is /usr/local which differs from where apt-get throws everything so I then added the new directories to the LD path:
sudo sed -i '$a LD_LIBRARY_PATH=/usr/local/lib' /etc/environment
and rebuild the lib caches:
After that, I was able to get MinOZW test application to talk to /dev/ttyACM0 correctly.
Then I installed homebridge-openzwave package via the README instructions, causing it to get built properly against libopenzwave.so.1.6. Again, checked with ldd -r:
If you have things scattered over multiple directory trees (node and other things installed in /usr/local/ and apt-get installed things going in /usr/) then be prepared for some manual mucking about.
Being aware that things from packages want to install wherever they want by default and may differ from where another package, will assume the files are at when compiling from source is involved.
So when installing on a raspberry pi running raspbian, after installing Openzwave from sources after installing libopenzwave-dev, I was getting a symbol lookup error when homebridge was attempting to fire up the plugin:
I was able to resolve this and ultimately get this working on raspbian and learned a lot about the nuance of installing this on that platform and wanted to document it here in case anyone else comes here with the same intention I had of installing this on an already running RaspberryPI3/Raspian system running homebridge (as a systemctl service too!)
Short version:
The crux of this issue is that if one installs openzwave from sources (currently 1.6) then does
apt-get install libopenzwave1.5-dev
then the 1.5 version of the lib will become the new system default and when building homebridge-openzwave it'll be linked against that lib which is missing the symbol indicated in the error. Installing from sources installs the 1.6 version of the include headers, so installing the libopenzwave1.5-dev package is redundant. Doing so after installing 1.6 from source will cause the plugin to be built linking to 1.5 which is missing the symbols indicated. Fix this by uninstalling the build homebridge-openzwave:sudo npm -g uninstall homebridge-openzwave
(or using the webUI from config-x) and then nuking the libopenzwave1.5-dev package:sudo apt-get remove libopenzwave1.5-dev
Deep dive: Learnings about Raspberry PI install:
Installing OZW dev package 1.5 after installing OpenZwave (currently 1.6) links libopenzwave.so.1.5 (the 1.5 version) as the system libopenzwave.so in
/usr/lib/arm-linux-gnueabihf/
causing the build of homebridge-openzwave to be linked against the 1.5 version as was evidenced by the error I first encountered:I was able to trace this down:
showing:
One would ask, why don't you then install openzwave via apt-get and then install the lib and then build. Well, I did that and building-installing homebridge-openzwave failed with source headers not being found:
Sure enough the source headers from apt-get are shoved into /usr/include instead of /usr/local/include, as is the rest of the openzwave environment. But my node environment was relying on /usr/local/include/ I could have gone to town symlinking stuff into alternate directories but that felt gross to me, so instead I built openzwave from sources.
So the steps that worked for me were to blast away the 1.5 dev package, then install OpenZwave1.6 from sources:
the default prefix for make install is /usr/local which differs from where apt-get throws everything so I then added the new directories to the LD path:
and rebuild the lib caches:
After that, I was able to get MinOZW test application to talk to /dev/ttyACM0 correctly.
Then I installed homebridge-openzwave package via the README instructions, causing it to get built properly against libopenzwave.so.1.6. Again, checked with ldd -r:
correctly showing:
Takeaway:
If you have things scattered over multiple directory trees (node and other things installed in /usr/local/ and apt-get installed things going in /usr/) then be prepared for some manual mucking about.
Being aware that things from packages want to install wherever they want by default and may differ from where another package, will assume the files are at when compiling from source is involved.