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.
Your use of this feature was not in fact required to work in order to pass certification, and I know that we never tested or explored what you're trying to do. The entire thing is now dropped from certification going forward, as I understand it (I am not SME for Z-Wave).
@JasonJoel has stated the situation pretty fairly: this is not a priority for us, for what should be obvious reasons, i.e., esoteric feature on its way to extinction.
5 Likes
I've done my complaining about this before. Seems to me that "certified" devices that don't work with each other would be fairly uncommon if the certification process did what its name implies.
Not at all, It's based on 40 years of experience writing code, including compilers, runtime libraries, commercial apps, custom apps, etc. A bug in a commonly used subroutine can affect lots of things, especially if you feed it input that the routine was not designed to handle. Edge cases that you never expected are not uncommon.
Not if you have a proper test suite. When you find an error, you add that case to the test suite before you fix the bug, and insure the test suite fails. Then you fix the actual bug and run the test suite again.
Sure, but that's a communications problem. Every bug should get at least a few minutes of investigation, and then be put into a queue where it is prioritized. Maybe it's such an outlier that it doesn't make sense to work on it. But at least you know where things stand. And if there are additional reports, then its importance could be adjusted accordingly. No software will ever be perfect, I know that as well as anyone.
I'm not going to belabor this discussion. You have now received the official answer from Bruce.
Good luck, though. I do hope you get things working the way you need/want. 
3 Likes
Ok, that's the first I've heard of this. So there's nothing at all in the zwave spec that allows for multiple controllers to control devices on the same network?
I get that secondary controllers have limitations and perhaps the original spec wasn't well thought out. But the idea of multiple controllers in some form doesn't really seem all that esoteric.
With respect to our user base, it is very esoteric. Hence, with respect to how we would spend our time, not a high priority.
Welcome to the wonderful world of Z-Wave "certification"!
6 Likes
Fair enough. So do you have any ideas on how I could bridge two independent zwave networks? Perhaps a Raspberry Pi with two zsticks that communicated with each other would work.
I suppose for security reasons, there's no way I can manually add a zwave device already paired to another network into HE.
The problem I have is that for my alarm controller to work, it has to be the primary otherwise I lose some important features. But I want to control certain things from HE because it has the ability to create complex conditional rules and such. which the alarm controller doesn't have.
