I may have hosed something. Pause the driver, delete the driver's configuration file, and start it up again. Or copy the config file away to a different name. Either way, to let it start over again. Does that get them all run back up to either wait approve or wait wakeup? Of necessity I've been deleting the config file a good bit lately for testing, so I may not have noticed some sort of backwards compatibility issue I'd introduced.
Connecting to Kevin's system has been quite useful. I fixed a few issues that might be causing you guys problems of various sorts. Hopefully I can get back on it tomorrow for some spelunking. There was an issue with light switches that could cause them to generate a system exception which may 'splain why something like Ben's issue above, and other similar failures to move forward.
I'll get any subsequent fixes I find tomorrow if I get some more time on his system, and get a new drop up.
His two secure devices still are not responding to secure messages. I'm not sure what's up with that. It doesn't makes any sense. And they just don't respond, no error or anything.
OK, bunches of problems now that I'm seeing it working on a system that's struggling a lot harder than mine. I'm just banging through them as quickly as possible.
Dean, maybe after you finish banging through Kevin's system and get those fixes out to use I can open mine up to you as another perspective. I have 28 zwave devices (3 are repeaters) of which only 6 are in Ready state. I will have time on Friday to grind through trying to the battery units to register properly but probably wait until you get the fixes in place.
Yeh, we can do that...
So, one thing that seems to be happening on Kevin's system is that, when I ask for the basic information on the nodes, I get inconsistent information. So any time you do anything that causes it to check nodes that are in ready state to make sure they still match the basic info last stored (such as approve units or when the driver starts up), it gets information that doesn't match what it had last time, seemingly random information sometimes. That makes it think that the unit has changed behinds his back and so he resets them and starts gathering their information again.
So every time this happens, you have to wait for the units to be ready again, when really it should be a quick check and they are back up. I don't have this issue in my system. I always get the same info as I got last time.
I got screwed by the docs and did something it said I should do but it ended up resetting his Z-Stick, so I'm locked out again until he can do an include for me again. But in the meantime I verified that I don't have this inconsistency problem.
The weird thing is that this info is coming from the Z-Stick itself. It is cached info that the stuck got the last time it replicated from the master (was included.) How that could possibly change without a replication having happened, I don't know. I'll have to dig a bit deeper when I get back into his system.
Well, as best I can tell the fundamental node info query is just not reliable in Kevin's system. That makes for a lot of complications. That is used to know if its a listening unit, or frequent listener, which tells us what we can talk to and what we have to wait to wake up. That's core, important stuff. If we can't get that reliably, then I'm not sure what to do.
It's made worse by the brain dead Z-Wave protocol which does not return the node id in the response. So, if something goes wrong and a msg gets re-transmitted or we think it timed out and try it again, we have no way of knowing that the one we get is not for the node we asked for. It's just so pathetic.
I'm going to have to think about this. Sigh...
I guess I can really only query this info once. Subsequently I guess I have to just go with what I have and only decide it's not good if the man ids don't match. It does work correctly the first time after a replication. That's going to take a bit of swizzling of stuff around. I wonder why getting it more than once works on my system but not his? Anyhoo, I'll make that changes tomorrow and see if it does better.
(05-02-2018, 07:51 PM)Dean Roddey Wrote: [ -> ]I guess I can really only query this info once. Subsequently I guess I have to just go with what I have and only decide it's not good if the man ids don't match. It does work correctly the first time after a replication. That's going to take a bit of swizzling of stuff around. I wonder why getting it more than once works on my system but not his? Anyhoo, I'll make that changes tomorrow and see if it does better.
Not that it should matter. On this network (besides the new z-wave stick) I have the master controller(Vizia RF VRUSB), old CQC(VRCOP) controller, Elk M1(VRCOP), and Smartthings hub controller.
Dean, it if would help for a sanity check / comparison I can open my system up, on my ZWAVE network I have SmartThings as the Master Controller, the old VRC0P as a secondary and the ZWAVE stick as a secondary. As long as the VRC0P configuration in CQC is not affected that is...
(05-03-2018, 03:19 AM)kfly Wrote: [ -> ] (05-02-2018, 07:51 PM)Dean Roddey Wrote: [ -> ]I guess I can really only query this info once. Subsequently I guess I have to just go with what I have and only decide it's not good if the man ids don't match. It does work correctly the first time after a replication. That's going to take a bit of swizzling of stuff around. I wonder why getting it more than once works on my system but not his? Anyhoo, I'll make that changes tomorrow and see if it does better.
Not that it should matter. On this network (besides the new z-wave stick) I have the master controller(Vizia RF VRUSB), old CQC(VRCOP) controller, Elk M1(VRCOP), and Smartthings hub controller.
I bet your Z-Wave network is very over-burdened, which may 'splain why it is so slow. Our old driver doesn't poll and neither does the new one, but the M1 and Smartthings might. So it could be getting beaten on hard.