Premise Job Queue stalls requires manual port reset

[etc6849]

Now the question is: how/why did the burn in test stop?  Is it because the port quit working again until you manually reset it?  Were you able to examine port spy when the failure occurred?  If so, please paste the last few packets from port spy.
 
Below is an example of what you should see in port spy as you run the test.  You should see the "<E000 <X000 <E000" within 500 milliseconds of the command being sent (e.g. >N28ON).  If some device is taking longer, you have issues with your network or have some RF interference issues.  You can try using the Leviton USB stick and the RF Installer network to repair your z-wave mesh network.
 
When the port freezes, is the jobqueue timer (e.g. sys://Schema/Modules/Default/Timers/JobQueue_JobTimer_{......}) still present?  If so, the port should eventually reset on its own after 3 consecutive job failures (this means 3 job retries * 3 consecutive jobs = a long wait for the reset).  I have JobTimeout set to 10 seconds on mine, so this would mean a 90 second wait for a port reset.
 
 

>N28ON
>N28ON
<E000
<X000
<E000
>N35ON
>N35ON
<E000
<X000
<E000
>N38ON
>N38ON
<E000
<X000
<E000
>N46ON
>N46ON
<E000
<X000
<E000
>N7OF
>N7OF
<E000
<X000
<E000
>N42L50
>N42L50
<E000
<X000
<E000
>N43L0
>N43L0
<E000
<X000
<E000
>N42L0
>N42L0
<E000
<X000
<E000
>N43L0
>N43L0
<E000
<X000
<E000
>N2OF
>N2OF
<E000
<X000
<E000
>N3OF
>N3OF
<E000
<X000
<E000
>N6OF
>N6OF
<E000
<X000
<E000
>N8OF
>N8OF
<E000
<X000
<E000
>N9OF
>N9OF
<E000
<X000
<E000
>N11OF
>N11OF
<E000
<X000
<E000
>N13OF
>N13OF
<E000
<X000
<E000
>N16OF
>N16OF
<E000
<X000
<E000
>N17OF
>N17OF
<E000
<X000
<E000
>N18OF
>N18OF
<E000
<X000
<E000

 

[doczaius]

It was a busy month but I wanted to tie up this thread... for now.
 
Amidst the testing the issue simply dissapeared... My polling frequency was last set at 240. I really would have liked to find the issue, but at this point if it ain't broke...
 
 

 

[chucklyons]

you nailed it...do we have a way of identifying a thread is closed?

 

[etc6849]

That's the problem with mesh networks.  If a device is going bad, it could behave intermittently and cause packet failures for neighboring nodes.  If it ONLY sometimes happens when you run burn in, I think you'll be fine.  The burn-in test really stresses the network and helps find problems (which was why I came up with it).  Eventually I bet the device fails though or you have some intermittent RF interference.