No, do not have Hub Protect @rlithgow1
Cheers
Be aware, without hub protect, local backups do not restore radios (so if you have to reset a radio or restore to another hub, you will have to re pair all your devices)
Are things significantly worse now than before you migrated from the C8? Just wondeirng if you had some issues w/your migration to the C8-Pro and if it might be best to re-do your migration and start from there w/help from forum members.
fixed
1 Like
Ahhhhhh, did not know that @rlithgow1
As I was migrating on 05-25
- On the old hub, created a network backup
- Went to verify that the net backup was created. Didn't see it listed.
- Waited a couple min. Still no backup listed. (I shrug) "OK, I'll do a local"
- Did a local backup and restore
Seems we arrived at the root problem with the Zwave.
So, today, I see the 05-25 net backup. Evidently I was not patient enough. Time to restore that hub from the net backup.
Thank you for the info. Will return with updates later in the day
2 Likes
Spot-on @danabw ! Seems my methods may be at fault. See my other reply.
Will return here later in the day, after a net restore
Thanks much!!
3 Likes
Just remember if you have any ghosts or corruption on your old hub, that backup will bring the database corruption to the new one and you'll have to clean it up manually. But overall, doing the cloud restore should take care of you.
2 Likes
Restored from the network backup. Big improvements. 
- Devices are displayed in the *Z-wave Details *
- Lock #1 can now be manipulated
Now it's time to do some further testing. Especially with lock '#2
Will get back with more info a bit later. Thanks again!
3 Likes
Post your z-wave details page in it's entirety so we can look at its health?
1 Like
Glad that things look like they are clearing up for you.
BTW, small suggestion, but for clarity of communication, what you're calling a "network backup" is actually referred to as a "Cloud backup." 
1 Like
Right, @danabw ! Brain fart. Thank you. Cloud backup
I have not gotten around to test every device, but things seem to be working as desired so far.
@rlithgow1, the Zwave details .......
1 Like
Now ......... we are back to the lockcode or locks issue. Whew! 
Lock1 and lock 2 can both be locked and unlocked. Both are Yale YRD256 with a Zwave module.
This shows them logging the lock and unlock events.
Looking a bit deeper in the logs, you should see that I tried adding a new user, Frog. Looks like the getLockCodesFromDevices- device:Lock :: Front Door should .... no surprise ..... get a listing returned from the lock. I see no evidence of that having happened.
I sometimes see this sequence repeating several times. I think up to 9 retries after the initial try.
The Frog user does not appear in the Lockcode Manager.
What am I missing? Am I looking at this sideways?
Much appreciate your keen eye and good guidance.
Both locks seem to have some high route changes. This indicates a somewhat weak connection to the mesh. I would but some beaming repeaters next to the locks to see if they help (I recommend Ring Externder 2's)
1 Like
My locks always have a lot of route changes, they seem to flip routes for every command for no reason. Mine might have TOO MANY route options so they keep flipping around. They all work fine though.
@danabw and @bertabcd1234 was hinting at it above, but your best bet to get LCM working good again might be to wipe all the codes off all the locks, do a full code refresh to be sure all the slots are clear, then add them back through LCM. The full code refresh might take a minute because it queries every single code slot. I think the Yale only have 30 slots so its not too bad, my Schlage has 255 slots so that take a bit.
Personal experience for me was to add beaming repeaters next to my locks (I have 3) and basically solved the issues (I too had high route changes). Once I did that all lock issues stopped. Shrug.... A lot of people solved lock issues that way. Just a thought.
My locks do that also .. every command it logs a new route ¯\(ツ)/¯
But works just fine so I just ignore it
Yes I suspect it has to do with the way FLiRS works. Every time the hub sends a command to the lock first it sends the command blind, just hoping the lock is awake. There is a small chance they are awake so I think this is a horrible idea but I checked and it is actually written in the z-wave specs this way. Then after that does not get a response back a "beam" is sent out to get the devices attention so it will wake up, then the command is sent again. Once the device is awake there can be a bunch of back and forth commands before it goes back to sleep, so the beam is only needed once per session. The beam is supposedly somewhat taxing on the mesh (it is a large/long message) so the blind command sent first is to try and avoid the beam but it seems futile to me.
I suspect this process of try, fail, beam, try again, is triggering the route change due to the failed commands.
I did run a zniffer on this a while back and it did not seem to be causing any excessive traffic on the mesh so I just left it alone after that.
1 Like
I think this is a requirement after migration? I have seen that mentioned a few times on this forum that people had to do a factory reset and re-include the device to get codes to work. Otherwise, it seems that the lock holds onto the old codes somehow, and doesn't allow new ones to be set.
I am not sure if this is a security thing, a Schlage, thing, or what. It should be quick and easy enough to try. And not much to lose, what is the worst that could happen, it starts working right?
1 Like
I think that is only if you leave the code encryption enabled and then migrate. Somewhere was instructions to disable the encryption before doing the migration backup. Even then, I see no reason why you would have to reset and include the device again. You should be able to clear the codes out via z-wave commands and then do a full refresh to confirm all the slots are cleared.
1 Like
A little context, @rlithgow1
The "Lock :: Apartment" route changes may be understandble. It has been more problematic so I removed it from the door and had it in the garage trying to debug. Then moved to my office. It has been in 3 different locations.
The "Lock :: Front Door" may be more difficult to understand? It has been stationary and is about 12' from the hub. Maybe 10'. Very close.
I thought about it being a signal propigation issue so have had a couple of 2 AEON extenders running. Is it possible to identify if they are having any impact? Preferably positive impact! 
1 Like
