Recurring "NOT_RESPONDING" or "FAILED" on C-7

Did 2.2.3.144 address the issue mentioned this thread?

The fix is still being worked on. Should be in beta soon though.

3 Likes

It’s in beta now

4 Likes

Should 2.2.3.145 have fixed this issue, or is it in a still upcoming release?

2.2.3.145 is the release that @bcopeland was referring to.

According to his most recent posts if you have 2.2.3.145 loaded then I'd do a couple things assuming that now that you're on the new version:

  1. Shut down, wait for red light, pull power, wait 1 minute, reconnect and boot up and see if that helps.
  2. Do a general Z-Wave repair (Button at the top of the Z-Wave Details screen.
  3. I always do a reboot after the repair finishes, personal habit.

Im on .145 and have run a repair / reboot. I am experiencing very similar errors to this report. This is coming during a repair after all switches in the network(Leviton DZ15S with latest f/w) become unresponsive

sys:12020-09-07 12:24:44.864 pm warnZ-Wave Network responded with Busy message.
sys:12020-09-07 12:24:42.833 pm warnZ-Wave Node 12: Repair failed node neighbor discovery (report failed)
sys:12020-09-07 12:24:42.822 pm traceZ-Wave Node 12: Repair is running
sys:12020-09-07 12:24:30.563 pm traceZ-Wave Node 12: Repair is pinging the node
sys:12020-09-07 12:24:30.551 pm traceZ-Wave Node 12: Repair starting
sys:12020-09-07 12:24:20.568 pm warnZ-Wave Network responded with Busy message.
sys:12020-09-07 12:24:10.543 pm warnZ-Wave Network responded with Busy message.
sys:12020-09-07 12:24:08.527 pm warnZ-Wave Node 30: Repair failed node neighbor discovery (report failed)
sys:12020-09-07 12:24:08.522 pm traceZ-Wave Node 30: Repair is running
sys:12020-09-07 12:23:56.318 pm traceZ-Wave Node 30: Repair is pinging the node
sys:12020-09-07 12:23:56.315 pm traceZ-Wave Node 30: Repair starting
sys:12020-09-07 12:23:46.320 pm warnZ-Wave Network responded with Busy message.
sys:12020-09-07 12:23:36.319 pm warnZ-Wave Network responded with Busy message.
sys:12020-09-07 12:23:34.325 pm warnZ-Wave Node 2D: Repair failed node neighbor discovery (report failed)
sys:12020-09-07 12:23:34.311 pm traceZ-Wave Node 2D: Repair is running
sys:12020-09-07 12:23:22.057 pm traceZ-Wave Node 2D: Repair is pinging the node
sys:12020-09-07 12:23:22.054 pm traceZ-Wave Node 2D: Repair starting
sys:12020-09-07 12:23:12.057 pm warnZ-Wave Network responded with Busy message.
sys:12020-09-07 12:23:02.060 pm warnZ-Wave Network responded with Busy message.
sys:12020-09-07 12:23:00.056 pm warnZ-Wave Node 28: Repair failed node neighbor discovery (report failed)
sys:12020-09-07 12:23:00.049 pm traceZ-Wave Node 28: Repair is running
sys:12020-09-07 12:22:57.603 pm traceZ-Wave Node 28: Repair is pinging the node
sys:12020-09-07 12:22:57.595 pm traceZ-Wave Node 28: Repair starting
sys:12020-09-07 12:22:47.606 pm warnZ-Wave Network responded with Busy message.

What does your Z-Wave Details page look like? Are all nodes failing repair in the current FW?

Have you tried running any device-specific repairs on the failed nodes (devices) in the Z-Wave Details page? Using the individual Z-Wave Repair buttons provided w/each device?

Looks like we may need @bcopeland to chime in here again.

All failing switches are on the .20 leviton FW, and all sow failed or not responding. Individual repairs don't seem to help. My Aeotec Multisensor 6's are all still reporting motion and seem to be the only consistently working devices.

OK, thanks. I'm afraid I don't have any great ideas, and rather than send you down rat holes, maybe waiting for @bcopeland may be the best I can suggest at this point.

to add info, zniffer shows a lot of CRC errors

I've had trouble with the Aeotec MS6's acting as repeaters. I know in battery mode they should not do this. You didn't pair any of those as usb powered at first did you?

One old trick to get the usb powered MS6 to stop repeating was to exclude the device, put in a battery, include the device again and then put it back on power. Apparently the config for USB vs BATTERY didn't change after include. Not sure if this is true with the latest MS6 firmware though.

Unless the device in question is nearby to the sniffer, I wouldn't worry about the CRC errors. Devices that are at the edge of reception range will often show CRC errors because the signal isn't strong enough.

2 Likes

+1 !!!

I've encountered this as well. You can test this by moving your computer around to see if things change.

Zniffing is always on the outside looking in..

I did add all of my MS6's as USB powered, and they continue to be USB powered. Do they not repeat well with Hubitat while USB powered?

They don't repeat well at all.. And IIRC, I think they removed that with one of the firmware updates. I could be mistaken.

1 Like

they are all running V1.13, which is the newest according to aeotec. Is there a way to prevent them from acting as repeaters?

I think the simplest way is to not provide them USB power...AFAIK, battery devices don't normally repeat. But I'm not familiar w/these. I assume you don't see any setting on their device pages to turn off repeating?

Normally on devices that have dual power source, you have to include on battery to make them not repeaters. You can plug in the USB after it is included and it won’t repeat as long as it was included on battery.

3 Likes

Cool...did not now that. [Files away in huge "Stuff Bryan said" OneNote page.]

1 Like

Except I'm not sure it works that way with the new firmware. It now recognizes usb directly.. at least that was my experience. Still have one MS6 but it is on the edge of my network and haven't gotten around to swapping it out. Seems to work.