That's actually exactly what that means. Being Certified means that it passed the qualifications "originally" similar to A steak you buy at the grocery store being "FDA certified"
Now if you take that steak home and leave it on the counter for a few days, then try to cook it and get food poising then you can narrow down the cause of the food poisoning because you didn't maintain safe food temperature, instead without being certified that cause "could be" the butcher who processed the steak.
Without Hubitat being certified no one is assured "originally" that the hub has ever properly implemented the zwave specifications from even it's inception.
Sorry. You're not correct here. Find in the certification that it states all certified controllers, routers and end devices must function perfectly with every Z-Wave device in existence. Or even find where is states that even every Z-Wave Certified device must work perfectly together.
@jeubanks I read through the first 30 posts or so then things seemed to get derailed so I skipped to the end. But I feel you may be on to something. I can't count how many times I've seen posts, most specifically about Schlage locks, where people are migrating from other platforms that they've been using for years (ST, Wink, etc..) and suddenly are having issues with the lock. Only to be told it's the lock itself, bad firmware, etc.. and switch to a Zigbee lock. I've never bought into this. If the firmware was terrible, why'd that exact same lock work on another platform for 2 years? The only thing different would be the Hub.
For someone like me, with 5 locks, a large house and no other Zigbee devices switching to Zigbee is just not a viable solution. For that reason I kept my Schlage locks on ST where they work perfectly and use HubConnect to bring them into HE. It's no ideal, but it works.
I've long said my suspicion is that it's something in the HE z-wave radio. I've done some very rudimentary testing where I put a couple ST hubs and an HE hub in the corner of the basement and attempted to include a device on the opposite side of the house. Both ST hubs could do it no problem, the HE hub's signal was too weak to reach.
It's possible it's not the weaker radio signal at all, but more so something (even something minor) may be lacking in the z-wave implementation. It would explain why these devices work flawlessly long term on other platforms and not on HE.
This also leaves me scratching my head wondering why they wouldn't take that step to get it certified as a controller? While all the competition is doing it, this could actually put them behind the rest from a marketing standpoint.
That's not what was claimed. What was claimed is the DID work perfectly to get the certification. Nothing is claimed that it isn't changed after the certification.
no, that is not what it means. It means it was tested in a specific way under certain conditions. That does not guarantee interoperability with all controllers, nor in all installed locations and situations.
Certification is reassuring in that it can pass the standardized tests though. I certainly prefer devices to be certified versus not certified. I don't think it's worthless, it just isn't a guarantee.
Given the choice between 2 devices, if 1 is certified by a 3rd party governing body and the other is not, I will choose the certified device 100% of the time.
Well I guess 99% of the time since I chose HE without realizing it wasn't z-wave certified
I however i live in the real world, I write drivers for real devices that get used on real networks.
And certification zwave or zigbee, or whatever, isn't a guarantee of bug free operation or implementation.
Per your own link to the Device Type Specification document from Silabs
If you look at the different command classes and inter operations spec if clearly states "MUST" work. There are optional "SHOULD" work defined as well and then there's the completely "OPTIONAL" that are vendor extras that are allowed.
Because the favorite topics is locks currently from the spec:
Table 2, Minimum requirements for controlling Device Types (page 11)
HC1 Door Lock – Keypad Lockbox The application MUST be able to Lock, Unlock and check the Status (Locked/unlocked) using Door Lock Operation CC with Security 0 CC
A "certified" device and gateway must implement the raw basics to be certified. The whole point of certification is to ensure BASIC functionality between devices/vendors/controllers/gateways.
This is my assumption as well. I have done extreme testing and it appears the way "Secure Device" communication is implemented is not correct and is the cause of the problem. But I have no data to validate this only extensive real world testing (along with many other platforms)
This is very true. The certification is a "Base Line" and provides little beyond the basic functionality has been verified to meet the basic criteria. This base line is also generally done under optimal conditions which is not reflective of real world use due to things like lack of repeaters and bad signal issues.
However once signal, repeater issues and the pointing at mesh problems is resolved that leaves the barest of items left in the equation of functionality and that goes to driver (software) implementation. This can't be a "radio" issue unless the z-wave chip is counterfeit so that leaves the software being the differential factor. Software is always the hardest part and is always prone to bugs or implementation quirks.
How many beaming repeaters do you have in place? Doesn't matter if Hubitat can't reach your Z-Wave lock and SmartThings can. Have you followed best practices for creating a properly formed Z-Wave mesh?
Don't need to take advice from me, but the experts and the Z-Wave Alliance will tell you you're doing it wrong if you don't have repeaters.
"I can’t tell you how many people I’ve worked with that had a door lock and a hub and nothing else, maybe a battery powered thermostat. And they wondered why the connection to the lock was unreliable when the hub was at the far end of the building! Z-Wave relies on Always-On (110VAC powered) nodes to build a “mesh” network. The mesh is the key to Z-Wave reliability. Every Always-On node acts as a repeater in the mesh and is able to forward a message from one node to another in the mesh. But only the Always-On nodes can forward a message. Battery powered devices like door locks and battery powered thermostats cannot forward messages. Only the Always-On nodes can.
Solution: If some devices are not reliable, add more Always-On devices. Add a Z-Wave repeater or any device like a lamp dimmer. Even if you don’t use the lamp dimmer it will act as a repeater and improve the network. I have a few lamp switches I use for my Christmas lights which I leave plugged in year round because they help the Z-Wave network since these nodes are at the periphery of my home.
Distance between nodes is not always the criteria for adding more nodes in a network. The Z-Wave radio signals may bounce off metal objects like mirrors or appliances and cause two nodes that are only a few feet apart be completely unable to talk to each other due to reflections of the radio signals. Adding more nodes in the mesh provide alternate routes to nodes that otherwise might be in a dead zone due to these reflections cancelling out the radio signals."
Repeating for the 16th time. Zwave is a device controller having a mesh is NOT MANDATORY for devices to operate. This is only valid once the HUB ITSELF can accurately control the device by itself with no other devices present. At current time it cannot.
Please pay attention to whom I am replying to. It wasn't you.
You guys are going to hammer this with your own interpretations of the facts and an unusual resistance to real world experience from experts until the you find someone to agree with you. I'm not seeing the point to this thread any longer.
The facts are that the hub itself cannot control the device accurately. Adding more devices to "create a proper mesh" does zero to fix that. It only creates more confusion by pointing to areas of irrelevance as the potential cause.
