Installation on Windows

[tilleul]

I tried to install this on a Win 8.1 64bits. (nodeJS v0.12.0 & node-gyp v1.0.2) npm install openzwave-shared would not work since I had to edit the binding.gyp file as mentioned in the docs. This is what I did:

• download the latest release of ozw-windows from ozw website
• unzip it
• compile ozw with VS2010 using default params (32 bits) in Debug, DebugDLL, Release and ReleaseDLL versions (these first steps worked fine)
• download the master for ozw-shared from git and unzip it
• move the ozw-windows to a folder inside the ozw-shared for ease of use
• edit the binding.gyp file like this:

['OS=="win"', {
    "include_dirs": [
        "ozw/cpp/src/platform/windows","ozw/cpp/src/","ozw/cpp/src/value_classes","node_modules/nan"
    ],
    "link_settings": {
        "libraries": ["-l../ozw/cpp/build/windows/vs2010/Release/openzwave.lib"]
    },
    'msvs_settings': {
        'VCLinkerTool': {
            'AdditionalDependencies': ['setupapi.lib'],
            'IgnoreDefaultLibraryNames': ['libcpmt.lib','libcmt.lib']
        }
    }
}]

• all rebuilding tests were made using the option --target_arch=ia32 since it's not possible to mix 32 & 64 bits libs
• but at this stage, node-gyp rebuild was unable to autolink nan so I installed it manually with a simple npm install nan and referenced the path in the include_dirs section and the problem disappeared (I suppose there's a magic param -- as in linux -- to auto-include nan without specifying the path but since this worked I stopped searching)
• running node-gyp rebuild at this stage would give an error about the inability to include tr1/unorderd_map in openzwave.hpp. After a quick search on Google, I've removed the tr1/ part and the error disappeared
• running node-gyp rebuild at this stage would then give the following errors

..\src\openzwave.cc(207): error C3083: '{ctor}': the symbol to the left of a '::' must be a type [E:\dev\ozw\node_modules\openzwave-shared\build\openzwave_shar
ed.vcxproj]
..\src\openzwave.cc(209): error C2533: 'OZW::OZW::New' : constructors not allowed a return type [E:\dev\ozw\node_modules\openzwave-shared\build\openzwave_share
d.vcxproj]

• so I edited line 209 and removed the first OZW::. The error disappeared but I'm not sure it's the right way to go
• I had to add the IgnoreDefaultLibraryNames parameters because compilation was giving a lot of errors of conflicting functions from msvcrt.lib with those in libcmt.lib etc.
• now, apart from a lot of conversion types warnings (C4244) & two or three "behaviour change" warnings (C4344) I have an error I can't fix:

openzwave.obj : error LNK2001: unresolved external symbol "class std::basic_ostream<char,struct std::char_traits<char> > std::cout" (?cout@std@@3V?$basic_ostre
am@DU?$char_traits@D@std@@@1@A) [E:\dev\ozw\node_modules\openzwave-shared\build\openzwave_shared.vcxproj]
E:\dev\ozw\node_modules\openzwave-shared\build\Release\openzwave_shared.node : fatal error LNK1120: 1 unresolved externals [E:\dev\ozw\node_modules\openzwave-s
hared\build\openzwave_shared.vcxproj]

It seems it has something to do with the standard C++ libs as found in MSVCRT.LIB. I tried several include <ostream> and using namespace std; but nothing worked and I don't know what to try next.

I suppose I could try with another version of node-gyp but it seems more like a windows-specific/compilation problem.

Any clue would be welcome. Thanks.

[ekarak]

Hey,

Many thanks for the info! Windows has been completely left behind when I forked from the parent repo. Unfortunately I've got no Windows development environment (I mostly work with Linux - the last Win32 C++ env I worked with was... Borland C++Builder).

Could you please join forces with @ldhertert and add the missing parts of the puzzle so as to have this addon on Windows too?

[tilleul]

Ok thanks to ldhertert (https://github.com/OpenZWave/node-openzwave-shared/pull/30/files) I've edited my binding.gyp file like this:

['OS=="win"', {
    "include_dirs": [
        "ozw/cpp/src/platform/windows","ozw/cpp/src/","ozw/cpp/src/value_classes","node_modules/nan"
    ],
    'msvs_settings': {
        'VCCLCompilerTool': {
            'AdditionalOptions': ['/MD' ]
        },
        'VCLinkerTool': {
            'AdditionalDependencies': ['setupapi.lib', '../ozw/cpp/build/windows/vs2010/Release/openzwave.lib']
        }
    }
}]

and now I'm able to compile. The problem was mainly that I added openzwave.lib as a library instead of an AdditionalDepencies

Note that, unlike ldhertert, I've been able to compile/rebuild as win32 (ia32) and not x64 ! (using node-gyp rebuild --target_arch=ia32)

[ekarak]

Please note: there was a very recent commit to OpenZWave to have the compilation enviroment more accessible (ozw-config was its name) - could it be used to determine the correct architecture? https://github.com/OpenZWave/open-zwave/commit/8d56562d908e02aec2a87409e65821770034552d

[ldhertert]

Man I spent like an hour looking for that 32 bit compile flag (was looking for a setting to put in the bindings.gyp.

[tilleul]

I'm not sure ozw-config will be of any use for windows compilation. It would be easier IMHO to have a separate script in the windows folder (like ldhertert's) or to use Visual Studio directly (simply add a x64 platform from the IDE and it works).

[tilleul]

about nodeJS, would there be a possibility to make a simple command like npm install openzwave-shared work on windows ? I don't know enough about building node modules :-(

[ldhertert]

Isn't that what we're working on? I'm not sure if I understand the question. Are you asking if we can compile/install the openzwave dependencies during the package installation for openzwave-shared? If so, I think the entire point of this effort is to decouple the ozw lib installation from the npm module, so I don't know if that fits with the goal of this project. That said, I'm also not sure if the goal of this project makes any sense on windows, as there is no ozw installation for windows, so there's no way to add a dependency on it without knowing where it would be.

[tilleul]

I think your compilation script is a pretty good start. What I don't know is If an npm installcan automatically

• download the latest openzwave-shared module (without "running" binding.gyp)
• download the latest ozw for windows and copy it in a sub-folder of ozw-shared
• run your script (or similar) so that ozw is compiled
• run binding.gyp

All in all I suppose a simple powershell script could do it as well.

[ldhertert]

Yeah, so if we really wanted to, you can update the package.json to have a more complex start command, but again, I think that goes against what the author of this package is intending to do.

Secondly, since someone else is looking at this now, I pushed up the changes I mentioned in the pull request that define a couple build time variables. I've also updated my install gist to copy the appropriate files.

Lastly - did you actually try using the final node module when you compile with your --arch=ia32? I was able to get it to compile fine, however when I tried to use the module, it said that it was not a valid win32 application.

[ldhertert]

Ok, so I think another option would be to use https://github.com/mapbox/node-pre-gyp, which would allow you to package/publish main node-openzwave-shared binary for windows. This would be done during the node-openzwave-shared build process, and the npm install hooks would try to download the binary (windows) and fall back to the build (non-windows).

Here's a blog post talking about their usage: http://cylonjs.com/blog/2014/11/19/creating-multiplatform-precompiled-binaries-for-node-modules/

[tilleul]

Yeah I have the same problem: although I was able to compile the ia32 version, it does not seem to work... no problem with the x64 version though ... don't know what's wrong .. need more time to look into it ...

The node-pre-gyp option seems like a good start but first I'd like to make sure that ozw-shared really works on windows :-)

[tilleul]

I had some trouble connecting to my zwave USB sticks mostly because I didn't know how ozw is expecting windows port notation ... I tried simply "COM13" but it didn't work and it turns out it has to be something like \\.\COM13, meaning that in JS it's written \\\\.\\COM13 .... Now it seems to work ok (still in x64 -- not ia32) with both my zwave sticks (Sigma UZB_EU and Aeotec Z-STICK S2) ... however both these sticks have no nodes associated so they're not showing much for now ... :-)

[ldhertert]

Nice! I left my z-stick at home so I can't try it with mine, but I was just using COM3, so that was probably the problem. Just curious, how did you figure out the correct format for the com port? I looked all around the source code for ozw-shared, ozw, and libusb.

[tilleul]

Found it here: http://www.openzwave.com/dev/classOpenZWave_1_1Manager.html#a8b29f783f894d4e530eeffe20ace37a0

[tilleul]

Ok I've associated a Fibaro wallplug with the Z-STICK S2 and turning it on/off activates events ... Now I wish I could associate another wallplug with my UZB stick using ozw-shared ...

[tilleul]

Ok, to make the 32 bits version work you have to use node JS 32 bits ... makes sense ... note that installing nodeJS x86 will remove nodeJS x64 ... not sure if it's possible to have both versions installed ...

Also, if you use VS 2015 (Community Edition), there's no need to edit openzwave.cc and remove the OZW:: ... don't know why ... still need to remove tr1/though ...

Tested on Win 8.1 32 bits AND Win 8.1 64 bits with latest versions of NodeJS (4.x), OZW (v1.3.x) and VS2015 Community (make sure you install the VC++ part) using node-gyp rebuild -target_arch=ia32

[ldhertert]

@tilleul Please take a look at the recent changes I pushed up to my pull request. I moved the compilation away from the vcxproj files in open zwave, and started using node-gyp for compilation. I also moved the installation location to a central location to be more in line with the linux dependencies. For right now I've kept the dependency installation out of this project, again to stay in line with the other OS dependencies, but the way that I wrote it, it could easily be included in the npm install scripts.

The install script is here: https://gist.github.com/ldhertert/6a5597a93013da06044a#file-install-ozw-windows-js You can do a one-line install from powershell with this command: $x=[System.IO.Path]::GetTempFileName(); (new-object net.webclient).DownloadFile("https://gist.githubusercontent.com/ldhertert/6a5597a93013da06044a/raw/install-ozw-windows.js",$x); node $x;

Let me know what you think.

[ekarak]

Does this mean that for Windows the script is taking care of downloading and compiling OZW itself?

[ldhertert]

Yes, that script does the following:

• Downloads the latest ozw from github to a temp directory
• copies a bindings.gyp over there (which is brittle but can be made less so by automatically generating it based on the file/folder structure)
• compiles with node-gyp (you can pass any custom node-gyp params you need to this script)
• copies the compiled lib, config files, and headers to a central location
• sets an environment variable for that install location (which I've updated the node-ozw-shared gypfile to respect)

[ekarak]

My brother Luke, Do you hereby solemny swear that you'll be faithful to your beloved gist and never ever touch it to add ransomware and trojans to the user's PC? Till 'git unmerge' do you apart? If yes, please sign here < > and wire in a check for the sum of 365 billion. PR approved :)

[ldhertert]

I'd actually prefer not to keep that in a gist. The question is where should it go? Since this project depends on an open zwave installation, and there is none for windows, I think that it either needs to be a part of this project, or needs to have very clear instructions on how to install it (since I made up a random environment variable/folder structure that this project depends on).

[ldhertert]

Also, did you look over the c++ changes that were made? I have no idea why they were necessary, or what impact they will have. I just had compilation errors, and my changes made the build run.

https://github.com/OpenZWave/node-openzwave-shared/pull/30/files#diff-029cc5ebec5955c4f364155485889aa3L207

https://github.com/OpenZWave/node-openzwave-shared/pull/30/files#diff-8594b3ea93db93f6e490273fbf442cf4L26

[ekarak]

They are both correct. First is a typo (duplicated class name) and the second one (related to the tr1 prefix is probably due to the unordered_map being promoted to an actual C11 standard, but gcc still supports its legacy name. In both cases, gcc is more lenient and doesn't stop compilation, whereas Microsoft's compiler does.

Thanks again, Luke.

[ekarak]

You should fork the project, add the Windows compilation script, update the binding.gyp and the README to clarify that for Windows, user doesn't need to download OZW but its done for him/her. Then open a pull request and I'll merge these changes in.

[ldhertert]

the second one (related to the tr1 prefix is probably due to the unordered_map

I actually wasn't talking about that change, but the one right below it. (removing the node.h include).

[ekarak]

Hmm, thats a nice find, Actually I don't really use any API call directly related to Node.JS (all the stuff I've added use Google's V8 javascript implementation, and it probably was missing from your box. This apparently wasn't an issue for Linux (as I've had numerous success emails from fellow Linux'ers) - see, node-gyp usually fetches and installs the full Node.JS source repo, and I suspect that this wasn't exactly the case with Windows.

[tilleul]

could it be specific to VS2013 ? I've never had to remove node.h using VS2010 & VS2015 Community

[ekarak]

No, i think its a path issue. The header is not needed anyway.

Στις 16 Οκτωβρίου 2015 10:19:12 π.μ. EEST, ο/η tilleul notifications@github.com έγραψε:

could it be specific to VS2013 ? I've never had to remove node.h using VS2010 & VS2015 Community

---

Reply to this email directly or view it on GitHub: https://github.com/OpenZWave/node-openzwave-shared/issues/33#issuecomment-148635305

Sent from my mobile device with K-9 Mail. Please excuse my brevity.

[ldhertert]

@tilleul Were you able to test out the changes from the recent pull requests (they've been merged into master). I want to make sure that it works for someone besides me.

[tilleul]

Luke, I'll try to find some time this Sunday to do that ...

On 16/10/15 15:38, Luke Hertert wrote:

@tilleul https://github.com/tilleul Were you able to test out the changes from the recent pull requests (they've been merged into master). I want to make sure that it works for someone besides me.

— Reply to this email directly or view it on GitHub https://github.com/OpenZWave/node-openzwave-shared/issues/33#issuecomment-148718996.

[tilleul]

ok, so apart from a problem with the tempPath in the script (see pull request #37 ) the install script worked (I had to manually download the master from github and make a npm install but I suppose that's the way to go until all the windows-related changes are validated and submitted so one can make a npm install openzwave-shared directly ...

so everything compiled and went fine but ... when I tried to test the install with node test3.js I had an error cannot find module openzwave-shared ... weird ... might this be linked to the fact that it was a "manual" install ? What am I doing wrong ?

[tilleul]

Also I have all sorts of problems if I try to reapply the install ... temp folders already exist, impossible to write/delete files to local\openzwave\ etc ...

is the OZW_HOME env variable used for anything else but this install script ?

[tilleul]

ok I found why test3.js was not working ... (improper require call) test2.js and test.js work with USB sticks plugged in using node x64 or node x86 ...

still have some problems when reapplying the install (it seems rmdirSyncRecursive is not always properly working ...)

[ekarak]

is the OZW_HOME env variable used for anything else but this install script ?

Yes, its used at OZW initialization. (search for Options::Create, 1st argument). This directory holds the device database (a set of XML files describing all the known ZWave devices and their properties).

[ldhertert]

@ekarak - That method actually references OPENZWAVE_ETC, which is defined in bindings.gyp. For windows, I have changed that to set it to OPENZWAVE_ETC=<(OZW_HOME)/config (which does a full path replacement. I made up OZW_HOME, and am setting it during my openzwave installation.

[ldhertert]

@tilleul - I assume that the pull request fixes the issues that you ran into are all addressed with your pull request? I was installing/reinstalling repeatedly without running into issues, so I think other than that temp dir issue, it should be fine to run multiple times.

[Fishwaldo]

I think there was a question about Windows Builds for OZW.

I'm already doing compile tests for VS2010, VS2013 and VS2015. It's trivial for me to publish the output of those to the a download site you could pull from. All I would need to know is what files you need (apart from header files)

(See http://bamboo.my-ho.st/bamboo/browse/OZW-OZWLNX/latestSuccessful as a example. That's where the snapshot source files come from after a successful build)

(And I'll add this repo soon to the build tests so you can easily monitor for breakages)

[ldhertert]

@Fishwaldo the main thing is that there is no installer for windows (i.e. the equivalent of the distribution packages for other platforms). So publishing the outputs from your builds, while helpful, would only get us partway there. What is able to happen on linux from this apps perspective is that it's able to query for the libopenzwave package via the pkg-config command, and find out where the relevant files are.

We don't necessarily need a full msi-level installer, even a self extracting zip file that puts the files somewhere and sets an environment variable would be fine.

In regards to what files are necessary, I don't know C++ very well, but from what I've been able to determine, we need:

• Win32 + x64 versions of OpenZWave.lib
  • There was some difference in the default cpp compilation flags that node-gyp (the compilation tool this project uses) and your visual studio projects. I had to pass a specific flag (/MD) to get it to compile. This isn't a big deal, but I don't know the benefits/tradeoffs of the various flags. The defaults that I see are /MP (compile across multiple CPUs) and RuntimeLibrary=0 (static release). If you need/want more info, let me know. I can also send you a zip with the vcxproj that is generated using the build that we are currently using.
• The relevant header files
• The config files (in /config)

[Fishwaldo]

I can make a installer no issue. (There is a outdated Nullsoft installer file in the repo that I can tidy up) I also got a guy that's sent me a Nuget config file if that helps.

I also under stand Visual Studio versions are a issue. I can pack all three versions up into the installer as well if needed.

I do know there are about 4 variants of compiler flags. Static/dynamic, multithreaded/single thread and debug/release (run times). Can you send me the compiler flag changes you made and I'll have a go at this soon.

[ldhertert]

@Fishwaldo Shouldn't matter what version of VS you use to build the artifacts - the issue is that if we were downloading the source and building it locally, we had to detect which version of visual studio the user had installed and select the right visual studio solution. In my case, I didn't even have 2008 or 2010, so I had to create a new solution that was an upgrade from your 2010 solution. If you are building the artifacts on your build server, this is a non-issue.

Here's a link to the project with the auto-generated vcxproj from node-gyp. The solution file is in the /build directory. Note that it only has an x64/release build target because node-gyp determines your os architecture and builds the binary accordingly, and my system is x64. I believe that your project would require release/win32 and release/x64.

Let me know if you have any questions.