openHAB Z-wave Secondary

Installed openHab2 with Z-wave binding, openHAB is a z-wave secondary to Smartthings.
Install went well and so far openHAB looks good!

Using paperUI it’s discovered all my devices but Aeon Multisensor 6 ZW100’s and Fibaro Motion V3.2 are added as unknown devices- even with the Aeon on USB and set to “wake”. I’m not sure if this is because they are using secure include.

I’ve captured the Smartthings security key using Zensys Tools and put it in the Z-stick thing config and setup z-stick controller as secondary, but looking at openhab.log I think it indicates it’s a primary (paperUI definately has "controlller is master switched off):-
2017-03-17 19:11:55.561 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
2017-03-17 19:11:55.562 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
2017-03-17 19:11:55.562 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2017-03-17 19:11:55.563 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 28
2017-03-17 19:11:55.564 [INFO ] [age.SerialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------
2017-03-17 19:11:56.300 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 1: Restore from config: Error. Data invalid, ignoring config.

The z-stick was also set as a secondary in Zensys tools before I moved it to openHAB2.

Any suggestions? Specifically, I don’t know:-

  • which file has the settings for the z-wave primary/ secondary
  • how to enable logging on openHab2
  • how to check the key is working
  • where to then start debugging why the Aeon (V1.06)/ Fibaro (V3.2) devices aren’t recognised, or if I need to delete them to have them re-discovered, etc.


Err… not sure what you try doing there, you shouldn’t expect us to be experienced Smartthings users.
That ‘security key’ you copied probably is the controller ID?
If so, you can’t copy that. Every controller has it’s own ID, and that’s why yours is showing the error in openHAB.

To keep running Smartthings in parallel to openHAB is no good idea.
A ‘secondary’ stick basically just allows for sending commands, like a portable remote.
But all devices can just have a single master configured, which is the primary. So e.g. your sensors will report to Smartthings only. Sooner or later, this ‘split-brain’ setup will drive you into control trouble.

On your questions, the related parameters are stored in the stick, you can access them through Zensys or any other zwave interface tools such as the habmin part (paper UI) in openHAB.
On how to enable zwave logging, see docs. You already see (at least) INFO level, and it can be overridden from the Eclipse console.

The z-wave security key is the security key set in the openHAB z-wave binding- part of the z-wave protocol and not SmartThings specific. It’s not the system ID- I know this is correct as the z-stick paired correctly and is seeing some devices.

It’s strange that I’ve set controller master to off in paperUI but it seems to be reporting as a master unless the log message is cryptic. Tried a soft reset but still get the log message above.

Trying to go through docs but it’s hard to understand what’s current with the many updates for openHAB2- in particular it’s hard to understand which files are used when, and when these are configured ( I mistakenly thought re-initialise device would configure it with settings from openHAB but found a snippet that indicates the opposite- this deletes the settings in files and downloads them from device again.)

Secondary devices do also receive commands if you have association groups configured on things to send data to openHAB- hence my dimmers, for instance show correct value when turned on. Without association groups they don’t- they just go straight to 100% when turned on, even when the dimmer is less.

Note that security isn’t supported in the current master version of the binding, so this won’t work. If you want to use security, you’ll need to be using the bleeding edge version of the binding (see a separate thread about this).

Maybe there’s a bug here - feel free to open an issue on this.

Yes, this is what it does.

Not always… Often there’s only a single node allowed for the ‘lifeline’ group which is meant to be used for sending reports to the controller. Additionally, battery devices can only have a single wakeup node set so you won’t be able to configure battery devices from a secondary controller.

Thanks. Unfortunate secure binding isn’t quite quite there- otherwise the openHAB zwave binding has been a really good, painless experience.
Don’t feel brave enough to mess around too much and run the Beta binding on the Qnap NAS I’ve been using for openHAB2, will get a dedicated PI 3.

Is there an openHABian/ Raspain build with the new Beta binding in it? I’d like to try it but code abilities are limited…

I’m still confused by the reinitialise. I read another post that this deletes the xml for settings then downloads the settings again from the device. Is this wrong?

A bit more digging on the Smartthings forum gave comments that SmartThings will work as a secondary, it’s also supposed to support SIC/ SUC. This is a promising as the openHAB handler are much better for setting up all setting including association groups, etc- if I can make openHAB the primary then SmartThings can just get reports via association groups so I can use it to interact with some Zigbee things I have.