Pictured are a Aeotec ZW090 Z-Stick Gen5 US and a Sigma Designs UZB Z-Wave USB Adapter. Both work equally well with the Theatersoft ZWave service and the underlying stack consisting of the libopenzwave library and openzwave-shared Node addon.

You might not need another controller until your Z-Wave network reaches the 232 devices per controller limit, but it's useful to have a second controller connected to the same machine to use for debugging and testing purposes. It can be time consuming to need to wait for initialization of a large Z-Wave network if you need to restart frequently for whatever reason. With a second controller you avoid downtime or destabilization on the primary network.

Theatersoft allows any number of device services, including multiple instances of the ZWave service, so using multiple controllers is not a problem.

Here's how - add a new service in config.json:

{
  "module": "@theatersoft/zwave",
  "export": "ZWave",
  "name": "ZWave",
  "config": {
    "port": "/dev/zwave",
    "options": {
      "Logging": true,
      "ConsoleOutput": true,
      "SaveLogLevel": 5
    }
},
{
  "module": "@theatersoft/zwave",
  "export": "ZWave",
  "name": "ZWave2",
  "config": {
    "port": "/dev/zwave2",
    "options": {
      "Logging": true,
      "ConsoleOutput": true,
      "SaveLogLevel": 7
    }
  }

Bus services names must be unique, so I've just named the second service ZWave2 and also changed the port to /dev/zwave2. Why use custom symlinks like /dev/zwave to the controller devices instead of /dev/ttyACM0? The symlinks are associated with a particular controller, while the tty device names can change depending on enumeration order. I'll show how to create the symlinks in a followup post.

Services config files (e.g. OpenZWave zwcfg_0x<home_id>.xml) are stored separately in corresponding service directories, e.g.: /opt/Theatersoft/.config/theatersoft/ZWave2

I also find it useful to increase the OpenZWave log level, using the options property shown above.