(05-11-2018, 09:05 PM)Dean Roddey Wrote: [ -> ]So 24/25 are secure ones. It got one but not the other. So it's not a security issue, probably just an inability to consistently communicate with one. So if 24 is the back door, is that further from the Z-Stick than the front door (25)?
Yes, No doubt  Units 24,23,16,20,22 are way to far away and timing out. I see long wait times on the master controller also. I have ordered a repeater and will test again.
Problem is it seems to affect the local working lights:
When CQC driver is not running: 
    lights on Z-Stick are BYR(Blue, Yellow, Red:  in order which is normal)
When CQC driver is running: (Sorry damn notepad didn't have seconds)
    When stick is in BYR all lights seem to work great(except those out of range)
    When stick is in solid Red no Z-wave lights works.(get driver exception).
    Seems to be every 30-60 seconds alternates between BYR and Red.
10:08 AM 5/12/2018  started driver  light red
10:09 AM 5/12/2018  BYR
10:10 AM 5/12/2018 Red
10:11 AM 5/12/2018 BYR
10:11 AM 5/12/2018 Red
10:12 AM 5/12/2018 BYR
10:13 AM 5/12/2018 turn Fish take light on (works) Stick all lights off
    Tried to turn off fish tank light..  exception on driver
10:14 AM 5/12/2018  BYR again
10:15 AM 5/12/2018 Red Again
10:16 AM 5/12/2018 BYR
10:16 AM 5/12/2018 All lights off
10:17 AM 5/12/2018  BYR
Can you unplug one of your modules and see if you can get your Z-Stick to alternate between BYR and Red?  and try a light when in Red mode?
Thanks
Kevin
One thing to do is disable the master controller. The driver is supposed to do that himself, but for some reason it doesn't seem to get it right. It's likely unit 1, since it's always the first thing in the network. So disable that guy and see if it makes a difference. It's supposed to disable any controllers and it seems to have gotten itself and the VRC0P correctly, but not the master. That just means that driver ignores them, it's not actually disabling them of course. There's nothing we want to know from them.
Actually you might want to try disabling all the units that have not made it up to a final state, and see if the issue goes away. I'll try to simulate it here as well.
Basically the driver is re-trying operations about every 30 seconds on units that have not gotten all the way through the process. So that would explain why there might be a 30 second period. Bad units will absolutely slow things down, but shouldn't cause a failure unless it's one of the units that is experiencing issues. When a unit isn't responding the Z-Stick retries a few times, and we can't do anything else until it gives up. But that means that anything else waiting to be sent is held up.
I wonder if maybe the output queue is getting filled up because of so many bad units and the output being held up so much. Enable the trace file, let it run for a minute and do a few operations until one fails, then stop the trace and post the file. Let's see what it's saying.
(05-12-2018, 09:13 AM)Dean Roddey Wrote: [ -> ]One thing to do is disable the master controller. The driver is supposed to do that himself, but for some reason it doesn't seem to get it right. It's likely unit 1, since it's always the first thing in the network. So disable that guy and see if it makes a difference. It's supposed to disable any controllers and it seems to have gotten itself and the VRC0P correctly, but not the master. That just means that driver ignores them, it's not actually disabling them of course. There's nothing we want to know from them.
ok disabled unit #1(master controller) still stops everything every X seconds.
I think the system goes out to lunch during this part of the trace.
I just put a stopwatch on it and it goes out to lunch for 1 minute and 12 seconds before resuming normal function.
see attached trace-file:
15:16:43 - [TRACE]- Sending msg, AckId=9600, Attempt #1
15:16:43 - [TRACE]- Transitioned from Idle to WaitAck state
15:16:43 - [TRACE]- Retry #1 for state: WaitAck, same CBId=4
15:16:43 - [TRACE]- Sending msg, AckId=9600, Attempt #2
15:16:43 - [TRACE]- Retry #2 for state: WaitAck, same CBId=4
15:16:43 - [TRACE]- Sending msg, AckId=9600, Attempt #3
15:16:43 - [TRACE]- Retry #3 for state: WaitAck, same CBId=4
15:16:43 - [TRACE]- Sending msg, AckId=9600, Attempt #4
15:16:43 - [TRACE]- Too many retries for state: WaitAck, giving up
15:16:43 - [TRACE]- Transitioned from WaitAck to Idle state
15:16:53 - [ZW->DR] - RES,Msg:ReqNodeInfo/0x60,Recvd: 15:16:53) 10307MSs
Oh, no, that's just that it doesn't have anything to do. It tried to get the node info, that fails because of bad comms. It retries it a number of times then gives up. After that it just doesn't have anything else to do until time comes to try again.
The weird thing is that it gets a bunch of cancel responses from the Z-Stick all at once after it requests node info. That's not a good sign, and may indicate that the stick itself is hung up for a while. The driver does a number of retries, which get no response, then suddenly its gets a cancel msgs for each one.
I may try changing the callback id if I don't get an ack. I thought that wasn't necessary because it just means that the Z-Stick never queued it up to send. But, maybe I should do that. It may be just ignoring these messages because they have the same callback id as one it's currently hung up on, so that the driver thinks it should just try it again.
BTW, I unplugged one of my units, a wall powered one, and it doesn't make the Z-Stick change its color. So I'm guessing that is something to do with it getting hung up on trying to talk to some other unit, possibly made worse by me not changing the callback id on retries.
I'm going to create a field that shows the number of msgs queued up to be sent, so that we can monitor how far behind the driver is getting due to the stick hanging up on trying to transmit. I don't think it should get out of hand, because other than when it first comes up or after a replication when a bunch of new units show up, or after you delete the config file and start it fresh, it doesn't do much otherwise. It just slowly tries to keep units moving forward, and very slowly pings good listening units if it hasn't gotten anything from them in a while.
(05-12-2018, 06:27 AM)kfly Wrote: [ -> ] (05-11-2018, 09:05 PM)Dean Roddey Wrote: [ -> ]So 24/25 are secure ones. It got one but not the other. So it's not a security issue, probably just an inability to consistently communicate with one. So if 24 is the back door, is that further from the Z-Stick than the front door (25)?
Yes, No doubt  Units 24,23,16,20,22 are way to far away and timing out. I see long wait times on the master controller also. I have ordered a repeater and will test again.
Make sure you do a zwave network repair once you put the repeater in so that the mesh will recalculate itself.
(05-12-2018, 11:35 AM)Dean Roddey Wrote: [ -> ]Oh, no, that's just that it doesn't have anything to do. It tried to get the node info, that fails because of bad comms. It retries it a number of times then gives up. After that it just doesn't have anything else to do until time comes to try again.
The weird thing is that it gets a bunch of cancel responses from the Z-Stick all at once after it requests node info. That's not a good sign, and may indicate that the stick itself is hung up for a while. The driver does a number of retries, which get no response, then suddenly its gets a cancel msgs for each one.
OK I think I have it figured out now...
If I disable the front door and backdoor locks ( the Schlage BE469) the Z-Stick stays working.
Just FYI.   If I do a "Query unit info" when one of the locks are disabled I have to stop and start CQC(odd) to get the Z-stick driver working again.
Will leave the door locks disabled for now.
    
The Drive/Z-stick don't seem to have a problem with units that it has communications issues with. Once I disabled the lock units all the hard to contact units came up eventually.
Just these two locks seem to cause major issues !!!
Kevin
Dean did you get the GE zwave switch I sent you into the last drop? It's not showing up...
Oh, no. I was so wrapped up in other details I forgot to add that switch. I'll do that.
On the locks, enable them again after the next drop. I've continued to make improvements and find small bugs that could always account for something non-obvious. But, if it's causing communications issues with the other units, and causing the Z-Stick to go into flashy red state, then maybe there is an issue there.
My lock isn't responding now either. I've removed and re-added, taken the batteries out and put them back in, restarting the driver, etc... and it won't respond to anything.
OK my Z-Stick has been solid and reliable last 6 hours after disabling the 2 locks. Works great with the Fibaro RGBW led controller.  Already working on swapping out fish tank lights for RGBW lights.
The new Z-Wave Gen5 stick and driver is such a great improvement over the old Z-wave driver. Thanks again for all the headaches getting it going.