I ended up having webCoRE send me notifications for unlocking events; seems to be triggering correctly in realtime so far. If all goes well over the next few days, I'll pair in the other locks.
You have to poll the locks every 2 minutes with ST or since migrating to HE?
That update button is only visible when there is an update. When there is a Z-wave update, it is always separate from the normal hub updates.
Could you post a screenshot of your complete Z-wave details page (all columns and rows)? We can take a look and see if there is an underlying issue that may be causing this.
Do you think that indicates the problem is on the notification side? Or are you polling with it with webCoRE? I haven't seen this with my very old Schlage FE599 (not Z-Wave Plus). Anyway, glad you have it working.
I poll them since getting on HE just to keep the status current.
They do update but very slowly. I also have hundreds of route changes for these 3 locks while all my other ZW devices have almost none.
1 Like
This is likely the source of your problem...when migrating from ST or other systems, you want to build you mesh/repeaters from the HE hub outwards first, and then add things that rely on them like locks (which really want nearby beaming repeaters), at the end of the process. Even if the hub is nearby/direct site of the lock this is a best-practice. When I moved from ST I moved my lock over late in the conversion process. It's a Z-Wave (non-plus) Schlage and I get immediate reporting of lock/unlock events at the lock.
I would put the lock back on ST and then move over your other "supporting actors" (Z-Wave switches, plugs, etc., that repeat) and then bring the lock back over again. You can also leave the lock on HE and after moving switches/plugs over, then reset and re-pair the lock.
See this post for more context/details...
1 Like
I'm unsure. I'm guessing it could be the notification app itself maybe? After pairing the lock to HE a second time, I was still experience delayed notifications and when looking at the details page of the device, its status would sometimes simply stay on the previous state, especially if I was to quickly unlock from the keypad and then lock manually. From the webCoRE side however, it seems to respond to correctly to those changes in realtime and sends out the notifications I want accordingly. But webCoRE is getting the same information from the hub itself, so I'm at a lost as to why the native notification app doesn't.
What about users that doesn't have Z-Wave repeater devices? Does the ST hub have a built-in repeater? Hence, why it was able to get those notifications instantaneously, whereas HE hub doesn't have the repeater hardware?
To me, that doesn't look so good. The PER is high, and you have LOTS of route changes. It is no wonder things aren't working great with only two devices. You can't form a mesh, which is how Z-wave operates without enough devices to make a mesh.
Things sometimes or often don't work very well, as you have experienced.
No, just like Hubitat repeaters are separate devices from the hub. There are differences in the ST hub radio and Hubitat. It could be the radiation pattern, how strong they each transmit, location of the hub, or any number of things. Just because one hub worked, doesn't mean a different brand will.
It is very typical for users of locks to have to add a repeater whether a dedicated one, or something like an outlet or light switch that repeats. Once they do that, their issues almost always go away.
3 Likes
The mains powered Z-Wave devices on your ST hub (light switches/dimmers, plugs, outlets) are repeaters. If you have those devices on your ST hub they were helping to build a strong Z-Wave mesh. You have none of those on the HE hub, just the lone lock. Not a recipe for success.
If you didn't have any of those repeaters on your ST hub then you were just lucky, IMHO.
Read the post I linked you to and consider following the advice there about transitioning over and building a strong Z-Wave mesh.
1 Like
Disappointing, but I understand. The holiday migration continues haha
Seems like it. But I wouldn't mind switching some regular outlets into smart ones to make the Z-Wave network better. Growing pains I suppose.
1 Like
These locks are so fussy. I did the antenna upgrade a while ago and my locks will often have 100+ route changes, go DIRECT for a day and then right back to finding a repeater.
90% of all my devices are solid DIRECT with the upgrade but the locks, mind of their own.
1 Like
Same locks, same issue. I just tested my garage-house door lock by unlocking and locking from either the keypad or the turn button inside, and the notification was exactly 20 minutes. If I lock or unlock from the dashboard the status is immediate. I have both the regular lock and the Reliable lock app displayed. Have you made any headway on this?
My suggestion would be to divide and conquer.
In other words, turn on logging for your device. Try the device from the device itself, and from the device's settings page. See if the lag happens in the logs. It will probably help if you post a screenshot your Z-wave details page so we can see if there is anything we can spot as being an issue.
From there, you must be using a rule to get notifications? Do the same logging routine as above and see if the app is where you lag is occurring. Also, post a screenshot of that rule so we may see if there is any issue in the way it is written.
No headway. I think the door lock drivers that HE uses vs the ones ST use are different? I have WebCoRE setup on both HE and ST; each having the same model of door lock.
When I setup a call to send me variables from a lock/unlocking event, ST will send out a lot of info. (i.e. the lock name, method of lock/unlock, the code used, etc.). HE will send a null message.
Thank you for the reply. I had not been prioritizing this but will now try to be more deliberate about troubleshooting. I have gone to each lock device. All are using the same driver (Generic Z-Wave Lock) which appears to be the only one available. Text logging was already on but I turned on debug logging. I also went into the Notification and turned on debug logging. I will try to screen shot that and post as well. I will go to each device as you suggested and test the various methods of locking and unlocking and then see what we get.
After more extensive testing with my Kwikset Zwave locks here are the results. Hopefully this will be of use to others:
- Hubitat C-7, most current firmware release
- Five Kwikset ZWave door locks, primarily 912TNL TRL ZW L03 SMT CP, using the prescribed generic zwave lock driver
- Hubitat notifications app
- Reliable Door Locks app
The symptom was isolated to delayed or complete lack of locked/unlocked status ONLY from the "Garage-House Door Lock" and ONLY when using the inside turn button. Locking/unlocking this lock from the outside keypad and the status to Hubitat worked fine. Locking/unlocking any of the other four locks from the outside keypad or using the inside turn button and the status changes to Hubitat were reported immediately.
Interestingly, on the Garage-House Door Lock, arbitrarily up to 30 minutes later the status would update. This was apparently a result of Reliable Locks app setting that forced a 30 minute update. I changed this to "never" on this lock, and then the status indeed never changed for that lock. Changing it back and the status updated.
I contacted Kwikset as they have a lifetime "mechanical" warranty on their locks, but they consider this issue electronic since the inside turn button indeed locks and unlocks the door. They had no recommendations except zwave excluding and re-including the lock to see if that fixes the status reporting issue. Rather than doing that I swapped this lock with another that I never use the turn button on.
Here are the debug logs with my notes, for future reference. Obviously they have to be read from the bottom-up:
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
