It still uses the same config file, but in order for HA to identify the lock properly you need to provide the Type and ID in Hex, which is obtained here: Link: https://products.z-wavealliance.org/products/3130
This needs to be submitted to OZW but I don’t know how to do git pushes… until it makes it into their GitHub, every update wipes this setting away. But once the lock is setup and identified it doesn’t matter since it no longer has to look it up.
I am trying to implement this. I am getting the following error when scanning the config files.
Error loading /config/configuration.yaml: while scanning a simple key in “/config/config/customize.yaml”, line 8, column 3 could not find expected ‘:’ in “/config/config/customize.yaml”, line 9, column 1
Here is the contents of my customize.yaml
group.keypads:
order: 10
group.all_locks:
friendly_name: Locks
hidden: false’’’
group.all_automations:
hidden: false
lock.zw_005_schlage_door_lock
friendly_name: Front Door
‘’’
How is one supposed to know this? I thought I was going to migrate to Z-Wave because it was standardized but it seems there’s plenty of guessing here as well.
Seriously though, I am curious how to know if devices pass pairing commands.
I personally feel like zwave is very stable and works well. I cannot speak 100% to the pairing process, but almost every zwave device I’ve purchased has a line or two that say, bring the device within a few feet of the controller when pairing. With that said, I almost never have to do that. I have a lot of zwave devices. Some of which are quite far and on a different floor from my controller.
I will say that people who have a controller and one or two devices, and maybe an extender over a longer distance are more likely to have issues. There are so many factors that can cause interference that it’s hard to say why. The more you add, the better it works.
Bottom line: zwave works well, the more powered devices you have the better it works. If you only have a couple devices and they are not near the controller, its possible you are going to have issues from time to time, and battery devices like locks for example are even more likely to “fall off the network” or have intermittent issues.
I sure hope I’m not expecting too much for range. To me, it’s like my powered devices aren’t repeating even after countless reboots, heals, tests, ect…
For example, my USB stick is direct line of sight to a powered dimmer (30’) works no problem, but it is not direct line of sight of one FE599. This FE599 lock is direct line of sight (40’) from the powered dimmer and it stuggles at 4000ms RTT give or take.
I took HASS with the USB right to every lock within 2’ and paired them all successfully, gave it a couple minutes and rebooted HASS, gave it a couple minutes and ran a network heal. Both locks that are line of sight to another powered dimmer (that works perfectly) both have TimeOuts and are presumed dead. I’ve also tried ‘waking up’ the locks while doing a heal. Basically any lock that isn’t close enough to the controller fails as if messages are not being repeated by my powered devices.
A lot of random info, hopefully there is some troubleshooting I can do that gives me direction.
Is that all of the devices you have. One dimmer, one lock and the stick. (I feel like there is a song lyric in there somewhere, haha)?
When you look at the zwave device, does it show each device as a neighbor to the others? in the arrtibutes? In a perfect world the lock should see both the stick and the dimmer as a neighbor, but if the stick is too weak or far away, then as a minimum it should see the dimmer.
The issues I tend to notice on these posts, is that when you only have a few devices, if any one of them is not available for any amount of time, there is no where else to “hop”.
When it is working, does the lock fully work? You can lock/unlock, it reports its state properly? You can change codes, set zwave parameters?
With that said, the FE599 is a bit tricky and slightly different than other locks. Have you added the lock to group 2 node to control
I seen the post about adding my controller to group 2, but nothing pops up when I click the drop down. Every other node I can set groups. Does it need to be associated to group 2 and this is all of my issue?
I have the hub, 2 powered dimmers and a powered tstat, all z-wave plus and line of sight. The locks that work show neighbors in HA, and the dimmer shows the 2 ‘dead’ locks as neighbors.
I get that many people expect too much on little equipment, but I’ve purposely placed powered devices closely and line of sight. I install cell boosters and WiFi networks with controllers so I understand RF and obstacles.
I think you have enough devices to get a decent mesh. I suspect your issue with the FE599 is the group 2 issue. If its not there, then something may not be set up correctly. I’ll see if I can get a screen shot in a bit to send
Ahh, Dont go into your controller, go into your lock (like in the screen shot.) from there you should see the group 1 and group 2. Select group 2, then add the USB controller
Honestly I don’t know but I believe it is something fairly unique to the fe599. The fact you’re not seeing it and you’re having issues makes me wonder if it’s paired correctly.
Did you pair it securely?
Do you have a network key set up?
What kind of zwave controller do you have.
All locks paired securely directly to the Aeotec Z-Stick Gen5 through HASS and work perfectly after I see ‘AllQueriesComplete’ and test the functions.
This morning I removed all of my nodes via HASS then restarted and added each one watching the logs. Once everyone was added in I shut down HA then started it back up, let the logs quit firing events, then ran a network heal. Any lock that wasn’t close enough to the main controller went dead while the dimmer farther than most locks (and neighbors with most) responded instantly with ‘averageRequestRTT: 29’ and ‘averageResponseRTT: 42’. This makes me wonder if the repeating and hopping is disabled or something…?
One cool thing is adding them to group 2 makes them respond quicker for sure.
Well I’m glad you were able to add them to group 2. Responsiveness is what adding to group 2 is supposed to improve. Going dead is still a bit weird. As far as the distance, its not super surprising that the powered device is responsive even at a further distance. It will be listening full time, where as battery devices, like the lock listen differently. Still though, it should not go dead.
So if you do a restart and dont do a heal, do the locks show as active?
If so try that, and maybe turn off the automatic daily network heal. If you’re not moving devices you should not need to do it often. See if your locks stay active for a while after that
Also post a pic of the node information for a working lock, just for refrence
Only the locks close enough to the USB stick stay active, it’s clear by looking at the RTT that it’s trying to talk directly to the controller vs going through the dimmer that is 5’ line of sight from it.
Attached the node info from a working lock. Interesting neighbor notes:
Node 1 = Controller
Node 25 = ‘Dead’ Lock
Node 26 = Dimmer right next to it
Node 28 = Not neighbor - 5’ line of sight from lock and dimmer
Node 28 only shows 26 as a neighbor (dimmer), but 27 is a lock 1’ closer than the dimmer and it’s not neighbor…?
Dead node 25 shows ‘Dead’ in the states menu with ‘query_stage: CacheLoad’ and shows no neighbors, 25’ line of sight from 26 (dimmer), 27 (working lock), and 30’ line of sight from 28 (barely working lock).
Thats what is confusing, I know it’s supposed to be able to use any neighbor (powered) and the powered dimmer is well within 4 hops of the controller.
How far away are we talking for these devices? Like for example. It’s odd that 28 does not have the stick as a neighbor? It made me look a little closer at the neigbors for my devices. I do have 30+ zwave devices, 3 of them locks and one of those is the FE599. I was a little suprised to find the lock that is farthest away of the three has my zwave controller as a neighbor, but none of the other two locks do. But, all of my devices have 6 up to 12 neighbors. All I can say is that maybe this is a case where zwave is really not the best solution. I feel like the people with even a few powered zwave devices usually dont have issues, and people with a large amount of both powered and battery (like myself) usually dont have much of an issue, but people with just a couple of each, seem to have issues with the battery devices. Maybe get a few more dimmers? I would suspect they dont even have to be closer to the lock, just more paths for the locks to communicate on.
Other than that help (not much help sorry), maybe look at the location of your stick, is it near your router? search the forums for wifi interference, channels etc. maybe you can improve your zwave signal.
28 is 5’ away from 27 (another lock) which is 1.5’ from 26 (dimmer that has controller as neighbor). The RF path to 28 from the controller is more of a stretch because of obstacles, but it should have no issue going through the dimmer if the repeating was in fact working. It would be nice to know what path messages take and where it ‘stops’.
One shouldn’t need 30 devices in a small setting to have a reliable mesh network, that being said I have no way of know if the mesh can communicate properly.
I would go WiFi but Z-Wave should be a better solution given the frequency and meshing.
