2.2.4: HE as secondary z-wave controller not working

I want to connect HE as a secondary zwave controller to my QolSys IQ2+ alarm panel. Was hoping that the 2.2.4 update would fix this.

On the HE I did a zwave reset and a hub reboot, then I put the alarm controller in inclusion mode, then put HE in learn mode. The alarm panel immediately detected HE, displayed a few messages and after about 30 seconds said the inclusion was complete. No errors or anything out of the ordinary.

On the HE side, nothing. In the system log there is a single "Z-Wave Learn Mode Activated" message. In the z-wave logs, not a single entry. No errors, no timeouts, nada.

My ST v3 hub as well as a ST Nvidia Shield Link works just fine as a secondary, with this panel as well as an older Simon XTi. On the ST hub, the alarm panel shows up correctly as a Z-Wave Controller, and the raw description is:

zw:Ls type:0200 mfr:012A prod:0001 model:0002 ver:4.24 zwv:4.24 lib:01 cc:5E,72,98,21,86,85,59,22,73,5A,56

How can I help get this resolved?


Maybe unrelated, but out of curiosity I clicked on Repair Z-Wave. A dialog comes up with "Stage: Mapping Network, Refreshing Node States". As there are no z-wave devices in the list, there shouldn't be anything to repair. Or is the alarm panel I was trying to add present in some partially initialized state? Clicking on the Abort button has no effect. Only two entries in the logs:

image

I am probably way out of my league here, but if nothing else is a free bump to the top of the forum.

So is this a C7 hub?

What does the Zwave device page look like (post a screenshot please).

Is this the only device you have tried paring to the hub?

How far away is the Hubitat from the alarm panel?

Yes, C7. There is nothing in the zwave device list or in the zwave log. No it's not the only zwave device I've tried to pair, so I know the zwave radio is functional. The HE is close enough to the alarm panel, It's not a signal strength or distance issue.

I don't think this will work.

You're currently putting both controllers into Inclusion mode.

You'd need to be able to send a NIF from HE when the other controller is in Inclusion mode, in order for the other controller to see it as a device that wants to be Included into its Z-Wave network.

You might be able to write a dummy driver that sends a NIF, but not sure how successful that would be. Even if it worked I'm not sure HE supports being a Secondary Controller .... there's a lot of things that it would need to do to support that, I don't believe that it's ever been a priority to support it.

Probably @bcopeland or @mike.maxwell would be best to confirm.

1 Like

Yes, as per the instructions. https://docs.hubitat.com/index.php?title=Z-Wave_Manual#Z-Wave_Learn_Mode_.28for_non-S2_capable_Z-Wave_radios.29_-_Receive_network_information_from_another_Z-Wave_controller_which_does_not_support_S2_secure_encryption

  1. Start by enabling Z-Wave Inclusion to add devices to the network of the Z-Wave primary controller.

  2. Using the Hubitat Elevation® mobile app, navigate to the Settings and press the Z-Wave Options button.

  3. Tap the Learn Mode button, then Start Learn Mode

  4. The primary controller should indicate a device has joined its Z-Wave network.

  5. When successfully added, network information from the primary controller will be replicated on the Hubitat Elevation® hub.

The primary controller (alarm panel) DID indicate a device has joined its Z-Wave network. Nothing (obvious) happened on the HE side though. There is nothing in the zwave device list or log.

I don't know what a "NIF" is.

I know it might not be a common use case, but HE must support being a secondary controller in order to be certified as a 700 series device, whether its a priority or not.

I know nothing about zwave implementation, but I assume that some sort of stack or sample code is provided by silabs along with the chip as part of the development kit. And someone went to the trouble of documenting how to do this with HE, so it ought to work.

Oh that's interesting, I wasn't aware they'd added that function to the C7 ..... I don't recall seeing it on any release notes. I don't use the HE App so had never seen that option, can't seem to find an equivalent in the web UI.

Based on the docs that should indeed work then, I tagged Brian & Mike so perhaps they can assist, or you might have better luck filling a support request (it's probably a bit of a corner case for many on the forum to have experience with).

While technically this would work.. As this was required to work to pass certification. I don’t think you would be pleased with the results.

1 Like

Can you elaborate please? I realize "certification" doesn't seem to mean squat in the zwave world, but I was hoping with the 700 series stuff it might mean things are actually supposed to work.

Sure you might get it to work.. but most devices there is only 1 lifeline .. and so state reporting will be very un reliable at best. Adding devices will be a pain.. You will be limited by the highest security of the primary SIS. Drivers and inclusion is written with the mentality that the hub is the SIS so you will likely run into a lot of problems there. You will have to manually manage all your device associations that you want to communicate with the hub. Some inclusion controllers may not even be compatible with the virtual nodes needed by the hub. I could really go on and on.. This route should only be used by z-wave experts who are willing to go through the pain.

3 Likes

Thanks. I'm willing to endure some pain, but I don't really need or expect much.

FWIW, ST works fine as a secondary controller (at least, for my purposes), and previously to a much older Simon XTi panel. My older ST Nvidia Shield Link (which never got updates) also worked with both alarm panels. State reporting always worked fine. Adding a device on either alarm panel was reflected back in ST in a few minutes.

I have no need to add devices to the secondary, and I don't use associations. All I want is for the devices on the primary to appear and be controllable by the secondary. Nothing fancy.

You might ask why I just don't use ST (or HE) as the primary. First, I have an alarm.com thermostat and while it's zwave, there are features like smart humidity settings, fan circulation modes, upper and lower limits on setpoints, etc. that are only available in the alarm.com app/website. Also, if a smoke alarm goes off or doors or windows are left open, there are rules to turn the HVAC system off. Alarm.com does not have an api so these events can't be exposed to another system like HE.

Second, I use the alarm state as our presense sensor; I don't use phones or other devices. If the alarm is disarmed, presense = "home". Armed away = "away", armed-stay = "night". I have lots of rules set up to trigger on these state changes, and alarm.com does not expose alarm state changes in an api.

Third, I've been told that alarm.com automations will not work if the alarm panel is configured as a secondary. Which means I would lose access to the advanced controls of my thermostat. Plus the alarm.com app is pretty good and I don't want to give that up.

Sorry for the long diatribe. Is there any chance that this can be fixed in HE? I'm just looking for plain vanilla, unidirectional updates from primary to secondary when a device is added.

Is there anything here from the raw description field in ST:

zw:Ls type:0200 mfr:012A prod:0001 model:0002 ver:4.24 zwv:4.24 lib:01 cc:5E,72,98,21,86,85,59,22,73,5A,56

that might give you a clue as to why it doesn't work with HE?

Actually I don't even need that. I rarely add new devices so I wouldn't have a problem excluding and re-including HE as a secondary if I add a zwave device to the primary. If the initial copy of devices from primary -> secondary worked, I'd be a happy camper.

I bought another QolSys IQ2+ for a rental property I'm setting up, and was curious to see if I could pair HE as a secondary controller to a panel that was in its factory default configuration.

Interestingly, it worked. There are no zwave devices on the panel, but eight entries showed up on the HE side. I tried adding a zwave bulb to the alarm panel, but it didn't automatically show up in HE like it would with ST as a secondary.

So I thought I would remove HE as a secondary and try again. Doesn't seem like there's any "unlearn" function in HE, so after resetting the zwave radio and a few reboots, I was able to again add HE as a secondary. But then I couldn't even get into the zwave details page, it just hung. Eventually I rebooted the hub and this is what is now showing:

On the alarm panel there are only 2 zwave devices: 11 is the zwave bulb, and 12 is the HE hub (no idea why it started numbering at 11 instead of 2)

I have no idea what devices 1-5 and 7-10 are. Looks like HE can talk to 2 through 5 so something is responding, but what? 8, 9 and 10 are in a failed state, but HE seems to think there's a real device at 10, but it doesn't do anything. The data for 10 is:

  • deviceId: 12344
  • deviceType: 18260
  • manufacturer: 335
  • inClusters: 0x5E,0x86,0x72,0x5A,0x85,0x59,0x73,0x26,0x27,0x70,0x7A
  • zwNodeInfo: 93 84 00 03 0F 02

The data for 11 (the bulb that works) is:

  • deviceId: 12344
  • deviceType: 18260
  • manufacturer: 335
  • inClusters: 0x5E,0x86,0x72,0x5A,0x85,0x59,0x73,0x26,0x27,0x70,0x7A
  • zwNodeInfo: 9C 00 04 11 01 5E 86 72 5A 85 5C 59 73 26 27 70 7A 68 23

If I set 11 to Generic Z-Wave Smart Dimmer, it actually works.

Any idea what's going on here? Perhaps HE is incorrectly parsing the info the primary is passing to it?


Edit
I cleared and paired my ZStick as a secondary to the new alarm panel and all these wierd nodes show up as Virtual Nodes, whatever that means.


I highlighted device 10 which HE thinks is some sort of real device.

I have a zniffer device but it just arrived yesterday and haven't had a chance to configure it yet.

Did you ever figure out how to get past the "discover" for the device from the primary hub. All my nodes imported, but I can't define them in HE under the zwave radio devices. There isn't any documentation that tells you how. I know that the drivers are there.

Did you do Discover Z-Wave device in Z-Wave Details after import from other hub?

Unfortunately, no. I keep trying after every FW update but it never works. HE seems to import all the devices from the primary, in addition to several that simply don't exist on the primary.

None of the imported devices have out clusters, and most don't have any in clusters either. Two of the devices actually created a device, but it is a "Device" device that has no real functionality. Changing the device type to the proper zwave device doesn't get it to work either. Discover, Refresh, Repair, none of those buttons fix anything. And to add insult to injury, the status of all the devices is "OK".

I know the alarm panel's controller (the primary) is working fine and able to work with a secondary because SmartThings works just fine with it. Actually two different generation of ST hubs work fine. I've been unable to get anyone at HE to look at the problem.

Aside from creating some entries in the zwave logs, Discover doesn't do anything. What is it trying to "discover"?

Doesn't the primary transmit all the necessary information about its devices to the secondary during the learn process? Far as the primary is concerned, the learn process completed successfully; I assume HE reported as such back to the primary.

However, there is no indication in the HE UI that the operation completed at all, or that it exited learn mode, or whether I should cancel learn mode or even if it is safe to leave that page (which is only available in the mobile UI).

Yes, when I select discover in the device column, there is a quick flash, but discover is still in the column. Hubitat hub node from my primary zwave hub is the only device in the device column, all other nodes have discover in the device column. I selected each one, no change. Looks like all the pieces are their, just can't get them talking...

I'll preface this by saying that I'm not trying to be negative/cynical - just realistic. I also do not work for Hubitat, so could be completely wrong.

All that said -

I doubt this will ever be fixed.

Unless one of their larger commercial partners that buys lots of hubs wants this, I don't expect they will spend any time working on it. Secondary controller operation is simply too niche / rarely used of a feature to warrant the engineering effort it would likely take to fix/work on it.

If you NEED a hub to act as a fully functioning secondary controller, I'm not sure Hubitat will be the right choice for you. At least not in any time frame that you will likely care about.

3 Likes

I hope you're wrong about that. There's always time and resource constraints, prioritization of issues, etc. Completely understood. I've been writing code for 40 years now and understand how bug fixes need to be prioritized.

However, it's a documented function and required for z-wave certification (such that it is) so the expectation that it works (or will be fixed if not) is perfectly reasonable, no mater if I purchase one or a thousand units.

And it could be a 5-minute fix. Maybe something as simple as incorrectly parsing the data returned by the primary, an unexpected null or out of range value, etc. Presumably the C7 passed certification, so it isn't like they have to write secondary controller functionality from scratch. HE is receiving the data from the primary, there's just some glitch in setting up the devices.

It's also possible that fixing the problem could fix something unrelated in the zwave code. There's been plenty of reports of orphaned devices, and this looks very much like an orphaned device issue since there are no out clusters for any imported devices, and no in clusters for most.

It's one thing to triage the problem and then say the fix is going to take a lot of work and can't be scheduled right now. Not even looking at the issue is another story.

It's also possible that the issue is in the 700 series firmware, in which case HE should report this to Silabs so it can be fixed. Or maybe HE is waiting on an FW update from them before investigating, which is also perfectly reasonable, but that would be nice to know.

Yes, the certification which they already passed and achieved... There is no "stick" there to make them fix it. Your complaint may be more with SiLabs that the cert process isn't sufficient to make sure this feature actually works as intended / is reasonable.

Agreed. I'm sure if they look at it and see it is simple, they would indeed fix it. I don't see any reason for them not to if that is the case.

Pure speculation / guessing there with no basis. On the same guessing premise it is equally likely it will break something already working as it is to incidentally fix something else that is already broken.

Who knows if they have looked at it? Just because they didn't post here doesn't mean they didn't. And even if they didn't that might be OK too. If only 1 or 2 people are asking for it, then it would be irresponsible for them to spend time looking at it over issues that many/more people are having. Right?

Agreed. It would be nice for them to confirm where the issue is, if they have time (and haven't already). The good part is if it is an SDK or firmware issue, it may magically fix itself eventually as other SiLabs customers will likely be interested in this working.