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.
(3) Powered (all ZWave Plus)
(5) Battery (1 Schlage deadbolt, the rest the FE599’s)
So if you count the controller (Aeotec Gen5, also ZWave plus) its 4 powered, 5 battery. Most ‘distant’ devices are literally line of sight 30’ or less.
In the screenshot, not sure if this graph is gospel. I’ve been messing with it from the start, this is a current shot with just clearing the browser cache. Notice one of the dimmers (node 26) says unconnected when it works flawlessly. Also, node 27 is a FE599 right next to the dimmer (node 26) and it shows the controller as a neighbor when the dimmer does not…?
Very odd, I have the same stick and all but one of my devices are directly connected to the stick. All of various distances and multiple walls/floors, some stucco. Only difference is my network is 99% mains powered. Only thing I can think of in your situation is there’s just not enough mains powered devices to give you a health mesh network.
That’s where I struggle in understanding and why I think my network is not using the mains powered devices properly. Any diagnostic tools or logs to help me out?
5.4 Installation and Maintenance Application (IMA) feature
When the Z‐Stick acts an independent/secondary controller that has been un‐plugged from the USB host,
it also can measure the network health for each device in the network. The different colour of LED on the
Z‐Stick indicates the communication quality between the Central Controller and devices in the network.
Short press the Action Button 5 times, if the colour of LED is changed to purple and then it follows with
fast blink, which means it goes into the IMA feature. The colour of LED will be changed according to the
network health level. If the colour of LED is changed to green, which means the current communication
quality is more than 95% on ‐7dBm. If the colour of LED is changed to yellow, which means the current
communication quality is more than 95% on 0dBm. If the colour of LED is changed to purple, which
means the current communication quality is less than 95% on 0dBm. If the colour of LED is changed to
red, which means the current communication has failed.
Short press the Action Button 5 times again, the Z‐Stick will automatically exit the IMA feature.
So, how’d the reset go. I added the zwave panel, and found that even over 100+ feet that I did not have more than 2 hops (stick to device to device). Sounds like maybe the stick is/was the issue?
Before a complete reset of the stick I installed Domoticz (OpenZwave included), nothing huge here, just a cool mesh graph and one detail I was unaware of - my powered ZWave tstat does everything but repeat…? I had a screenshot but lost it on a reboot before I saved it. Either way, that node is on the opposite side of all the locks
After resetting the USB stick, removing everything Zwave, adding .old to all relavant files in HASS, some of the locks came back with OLD names that I once named them for testing. Not even the most recent ‘friendly names’ and I cannot rename those. IS HA MESSING WITH THIS TOO?!
I just wish there was something that said, Node 1 asked Node 28 to lock and attempted to contact Node 28 through Node 26 but the message dropped after Node 26
Only thing I can think of is not enough mains powered devices relaying your mesh here’s my mesh, and the only devices with high response are those with batteries (or backup batteries):
The naming issue is most likely related to the zwcnfg file. When you reset the stick, etc it probably was left behind. It’s not a huge deal, just a pain in the butt. There are a few posts about zwave and naming since 81.x? somewhere a few updates back. I will say at this point, I do believe that your issue is not lock related, but zwave related. You might want to start a new thread about how to improve the mesh, or asking about hops, etc. Might get more response than in the schlage thread.
Thanks for the great work here. I’m a newb so still learning here but I have a few questions.
I have my single schlage lock connected and I’m able to set a code via the lovelace UI.
I’m seeing the following error when checking config though. Configuration invalidCHECK CONFIG
Invalid config for [automation]: required key not provided @ data[‘action’]. Got None required key not provided @ data[‘trigger’]. Got None. (See ?, line ?). Please check the docs at https://home-assistant.io/components/automation/
I read somewhere that you can’t have a blank automation file and so I copied their dummy automation into the automation.yaml but not sure if there’s something else I may be missing. I also had to use a merge command in my configuration.yaml to get the package working.
I get a Date Invalid error on the card for setting up a key for both start and end date
I don’t currently seem able to setup a 2nd code although the lock took my first one.