Hubitat Z-Wave Plus Certification ID

I never said I disliked Zigbee. In fact I've stated several times on this forum and others that I prefer it for sensors.

I could go through your bullets but why? It's irrelevant to the topic and just a sidebar distraction.

Who has been disregarded? @bcopeland was active last night on this thread and I suspect will be again. @mike.maxwell did chime in a little.

Nothing is being disregarded but I do agree this is going in circles as most topics seem to do because the "use zigbee" gets tossed out and issue avoidance at all costs becomes the goal of the topic.

I suspect this is related to the influx of users from other platforms, primarily from Wink...

At the beginning of the Wink era, they supported locks in a generic fashion... There was a spate of problems with the Schlage locks (which also carried over to other controllers)... and they "partnered" with Schlage... They eventually eliminated the issue with the Schlage locks... BUT... It broke compatibility with the "generic" locks... The Wink solution to that was "That brand of lock is unsupported. We do not guarantee compatibility with unsupported products"... Shortly after this, Schlage updated the firmware in the Z-Wave modules, and most of the compatibility issues with other controllers went away as well...

With all the refugees converts from Wink and other platforms, I think we are seeing quite a few older locks being moved to HE. These older locks, with older firmware/modules, worked well with Wink due to some under the hood magic that is not present in HE.

As with other industries, the Z-Wave manufacturer will set up a testbench system to specifically target the system that is used by the testing authority for certification (If the manufacturer cares about certification)... The device firmware is then tweaked to perform well with that test system... Since the real world does not resemble the test system, the certification means very little... You can see this in all technical endeavours (ie: volkswagon diesel engine ECUs tuned to "cheat" when undergoing emmissions testing, Graphics card firmware tweaked for better performance in benchmarks, cpu microcode tweakd to show better performance for overclocking, etc)

8 Likes

Mike Maxwell has been saying that locks are the exception of pair in place for a very long time. I think that's probably posted "ad barfum" as he put it, on this forum and probably when he was posting on the SmartThings forum too.

Why did I not pair my lock next to the hub? Didn't need to. If I needed to I would have. If I needed a repeater, I would have added one. I'm not into pounding my fist until I get a perfect world. I make changes until I achieve what I'm looking for. I could care less how many hubs, bridges or devices it takes to get there. If it makes sense to me and I see value, I do it. If I don't see the value, well that's me and my opinion. It's not proof.

But let's not mistake facts for opinions. There are facts that because a Z-Wave device is able to communicate over a Z-Wave node (certified or not) doesn't ensure it's perfect function or ability to stay connected. Z-Wave is a mesh and it works by relaying signals from mains powered devices to other mains powered devices, and then eventually the non-repeating battery powered devices. If it works without a repeater, great! But the protocol isn't designed to work entirely without, so I cannot see the point in arguing that it shouldn't need any. That's WiFi, not Z-Wave or Zigbee.

Now this makes logical sense as to why there's the inrush of problems with a particular product and category.

2 Likes

This has actually been the support strategy for many of the lock manufacturers and closed-system controllers...

When is it time to just say: "This isn't working for me... What else is there that could work better"?

A move to a Zigbee/Wifi/whetever device is sometime the best solution... It is not avoidance, it is pragmatism.

1 Like

This is not accurate. The protocol has no stipulation on repeater requirements and in fact some functions of the protocol DO NOT repeat AT ALL such as direct associations aka scenes where repeaters do nothing.

Your back to the irrelevant mesh again, you missed the point. I'm done.

This has actually been ongoing since I joined HE a year ago well before any inrush of Wink.

Also long time user here, ordered mine on 2/2/2018. I can support this "idea". I have two smart locks, at the time both zwave:

  • One on my garage door I could never pair to HE even though it worked OK on ST. I bought it in 2015 and it had very old v5.x firmware.
  • Second lock is not too far from other lock but leads out to my patio with v7.x firmware, and I was able to pair this lock in place. My hub is under my stairs towards the front of the house and I have a closet, bathroom, and pantry in between the hub and this lock.

I ended up moving that lock back to ST because at the time HE didn't have LCM and I preferred my ST app to manage that - plus my other lock wouldn't pair at all so my ST hub basically has these two locks only. I used Other Hub (pre-Hubconnect) to keep things in sync.

Then once LCM came along I tried again but I could never pair this patio lock again even moving the hub within inches of this lock. Fast forward many other HE firmware versions and after replacing my problem garage lock with a zigbee version last summer 2019 I tried to pair this patio lock in place and boom it paired. It has been rock solid since then.

So I don't know what to say but like others I do have a working Schlage lock that I was able to pair in place and batteries last nearly as long as they did on ST.

Yeah me too. Z-Wave is a mesh technology. It's not irrelevant.

From the Z-Wave Alliance website.

" What is Z-Wave's range?

It is recommended to have a Z-Wave device roughly every 30 feet or even closer for maximum efficiency. While Z-Wave has a range of 100 meters or 328 feet in open air, building materials reduce that range. The more line powered devices in your Z-Wave network, the better, as they also act as repeaters to extend the Z-Wave signal. Z-Wave’s mesh networking allows a Z-Wave signal to “hop” through other Z-Wave products to reach the destination device to be controlled. If there is a wall interfering with this signal, all you need is a simple Z-Wave repeater or other line powered device to work around the wall so the signal can continue on to its final destination. Z-Wave supports up to 4 hops so the total home coverage will grow depending on the amount of Z-Wave products in the network. The maximum range with 4 hops is roughly 600 feet or 200 meters."

2 Likes

This is true. From an individual stance there comes a point of something not working and it becomes time to find something different.

I like HE and think it has a great future but there's so many problems (in rush from new users) that could cause long term effects from complaints of devices not working as they should or "did" with other platforms such as the Wink users and Schlage locks.

At best case I think things like this should be identified and a sticky put up or added to the compatible device list as a guideline/warning to new users?

From the top of the compatible devices doc.

"Devices listed here are confirmed to have worked with Hubitat, but this does not mean the device will be guaranteed to work with Hubitat."

Do you know the difference between "recommended" and "required" ?

I think it may need to be a little more explicit and call out "known problem" devices. This won't stop a lot of the thread noise but it could possibly simplify the responses of just pointing to that?

Jesus you're insulting. If I wrote "required" is was a mistake. You can stop responding to me now.

1 Like

No, you didn't "write" it......you are mis-quoting from the documentation. The documentation you posted from says "recommended" yet you are still inferring that it is "required" to have other device.

I'm a former Wink hardware beta tester. The recollection of events you have indicated is exactly correct. I remember how ridiculously unstable Schlage locks were on the Wink hub (hub 1) in August/September 2014, when compatibility was being tested. The instability was sorted out shortly before the SSL certificate debacle of April 2015.

The problem is that a lot of Schlage locks that date to that era with problematic firmware (5.8, 6.8, 7.1) are still in circulation. Of course they work "fine" with Wink, but move them to any other platform and one is left dealing with the same instability that Wink had with these locks.

2 Likes

I don't understand why you are involved here with the above statement? What is you objective if it's not finding a solution?

I have four Z-Wave Schlage locks all with older firmware. They all paired on the first attempt with Ring and I haven't had a single issue. Just sayin'