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.
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. 
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"!
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.
Given the extreme quirks of zwave certification I've often wondered why its considered to be so great.
Mysterious stuff happening at the "sdk layer" no one seems to understand. What is the gain to being zwave "certified"?
Sorry to derail. Just generally curious. I'm more or less off the zwave bandwagon. Too many oddities there aren't answers for.
One network is Hubitat. Remind me - what's the other? Is there a Node-RED integration for it? I bridge, for the purpose of automation, two zigbee networks and one z-wave network (Hubitat, non-Hubitat, Hubitat) using Node-RED.
Not even remotely as many as there are in zigbee though with a looser protocol spec and multiple silicon companies involved.
The "problem" as a new protocol (which zwave was at one point) is that if you make the certification too stringent or too expensive (and they are related), nobody will bother getting it or will favor a different protocol altogether.
It is easy to look at a protocol after it already has wide acceptance and see that they can strong arm their user base into what they want... But it is really hard to do so at the beginning. And is exactly why "fringe" features often have lesser certification testing and requirements.
I think it's a perfectly valid thing to wonder about. Forget about secondary controllers. Why is it that some relatively simple device like a zwave controlled power strip can wreak havoc on a network How could such a device pass certification?
I went down the zwave path because my first alarm panel, a Simon XTi, had a built-in zwave controller and I was getting fed up with my X10 stuff.
My current alarm panels also have zwave controllers and they are extremely stable. And I want to keep things connected to the panel's zwave controller because it has features I don't want to lose.
For example, if a smoke alarm goes off it can automatically turn off the HVAC system through the zwave thermostat. The smoke alarms are part of the security system and are not zwave. Many other examples of alarm system <-> zwave interactions that I don't want to lose.
If it wasn't for all this, and the $$$ investment I have in zwave devices, I'd go a different route with automations.
We'd need a whole other thread for my thoughts on zigbee lol. Just figured I'd ask about the zwave while we had an interested group of of zwave enthusiasts. I'm very much a laymen but all this stuff interests me.
It is always a good discussion. As an engineer I would love if everything was perfectly predictable and to a detailed written spec.
The reality is that rarely happens on 100% of the feature base, and the commercial and licensing considerations often impact the technical side as well.
It is a simple reality, especially in the world of cheap consumer electronics. If these devices sold for a significant premium over the current price point - or were sold/purchased in a lot larger volume - sure, you could afford a lot more rigorous testing and interoperability requirement.
As it is Zwave is just trying to SURVIVE versus zigbee, wifi, thread, and other protocols coming out. They are in no position to increase requirements on manufacturers.
Z-Wave certification is required in order to be allowed to purchase 700 series chips. As for being "great", it isn't.
Z-Wave Long Range, made possible with 700, is a potential game changer.
The other is my alarm system. Currently a Qolsys IQ2+ panel, previously a Simon XTi. Both work fine with a ST hub, with the ST hub being a secondary.
The alarm system devices (door sensors, water sensors, smoke alarms, etc.) are based on the PowerG protocol. Rock solid, no mesh business to worry about, encrypted by default with frequency shifting and jamming protection, long range signal, long battery life, etc. The second one of these devices are tampered, has a low battery, etc. the alarm monitoring center is notified and they make every attempt to contact me. In addition, the panel notifies me as does the mobile app. It's a very robust, reliable and trustworthy system.
There is no way I'd trust the safety and security of my home to a zwave based security system, when something like a rogue power strip can flood the network and cause havoc.
Now, the alarm panel also has an integrated zwave controller (500 series) that is also very robust. And I can create rules that are triggered from alarm events. For example, if the alarm is tripped I can turn every zwave light on. If a smoke sensor trips, I can turn off the HVAC fan through the zwave thermostat. If an exterior door is left open, I can turn off the ac or heat until it is closed. If a water sensor trips, I can close a zwave water valve. And so on.
I also use the alarm state as our presence indicator. Off = home, Armed Stay = night, Armed Away = away. Various lighting, etc. is controlled by that and I don't need flaky presence reports from our cell phones.
What I do not have is something like Rule Machine or Webcore to create rules based on conditionals that have AND or OR conditions. Smartthings solved this issue very nicely via its ability to work as a secondary controller to the alarm system's zwave network. But my confidence in ST is as close to zero as it can get, especially after the debacle with their current Alexa integration. I desperately want to retire my ST hub and I was hoping HE would allow me to do that.
For security reasons, my alarm system (and virtually all alarm systems) do not have any API or access into the system, so something like NodeRed is not an option. Zwave is the only way.
In the absence of HE supporting secondary controller functionality, conceptually what I need is something like HubConnect, but that bridges two zwave networks.
True. That is a bit of a change from 500, so is a bit counter to my thought that they aren't in a bargaining position.
With emphasis on POTENTIAL. I'll believe it when I see it and can buy off the shelf products that support it.
Heck, I can barely find regular non-LR 700 series devices in many areas/types. Although some are just now hitting market (finally)...
Hmm. The Home Assistant community seem to have figured out how to get the Qolsys IQ Panel 2 into Node-RED.
Yup, start your reading here:
". . . do not have any" published "API or access into the system."
Which is (in my OPINION) the main reason it was not used more...
It is an awesome panel - but the closed wall nature of it relegates it to using it exclusively, or pay through the nose and go to control4.
They always intended that device to be for professional integrators - not hobbyists.
I always worry about undocumented access to any kind of security system or function.
Download the Hubitat app
