Health checks show that things are broken (no pings one direction), but clearly they work fine.

[gdt]

I'm running up-to-date zwave-js-ui (most recent tag). I did a health check to a mains-power node that is 100% reliable and that other nodes have chosen to route through. Subjectively, it works just fine. This is an aeotec Gen5+ stick and a Leviton DZPA1 appliance module. Old stuff, but as i understand it perfectly ok.

I ran a Health Check, 5 rounds. All of them get the same result, so only talking about the first.

Max latency is 20 ms. That's great. But it's formatted to go with both directions. 1->12 has 0 failed, and presumably that's a echo request from1 and echo reply from 12. 1<-12 would be the other way, and it's 10/10 failed. yet the latency is including that.

I am guessing that somehow, node 12 does not support the "please ping node 1 and tell me how that went" command. Or maybe it does and then instead of doing it, reports that things are bad.

As a user, I'm baffled as to what's really going on. Should there be some way to ask for ping from 1 only? A quirk table that says this node doesn't do remote-originated pings? Something else?

[zwave-js-bot]

Beep, boop! 🤖

I've found existing posts that look similar to yours. If they don't help, please wait for a human to show up.

These existing posts look similar to yours and might be related — a maintainer will confirm:

• Zwave Multicast Unhandled Errors (discussion)
• Nodes sent to sleep during interview (open issue)

---

These suggestions were generated automatically. AI can make mistakes, always check important info.
Was this helpful? React with 👍 or 👎 to let us know.

[gdt]

I did Health Check on several nodes that are 1 or 2 hops away in the graph. Those did not show return ping at all.

[robertsLando]

Thanks for the detailed report @gdt — there are actually two separate things in this thread.

Your follow-up comment: "several nodes did not show return ping at all"

That one is a UI bug and it's fixed in #4799 (issue #3557).

The driver only fills in failedPingsController when no power level was found where all pings were ACKed, i.e. only when things went badly:

if (powerlevel == undefined) {
    ret.minPowerlevel = Powerlevel["Normal Power"]
    ret.failedPingsController = failedPingsController  // only set here
} else {
    ret.minPowerlevel = powerlevel                     // nothing set
}

The UI was gating the whole 1 ← N row on that field, so a perfectly healthy result (0 failures) and a node that can't be measured at all (no Powerlevel CC) both rendered as nothing. After the PR both always show — 0/10, or not measured with a tooltip saying why.

Your original post: node 12 showing 1 ← 12: 10/10

That row was already being displayed, so the PR doesn't change it. This is a different problem and I think you're right that the node is fine.

failedPingsController = 10 comes from Node.testPowerlevel(), which returns 0 acknowledged frames in three situations that all collapse into the same number:

if (continuousErrors > 5) return result(0)                   // node never answered, 6 polls in a row
if (status.status === PowerlevelTestStatus.Failed) return result(0)
else if (Success) return result(status.acknowledgedFrames)   // genuinely 0 acked

plus an outer catch (Controller_CallbackNOK) that sets failedPingsController = 10 outright. Then the rating does Math.max(failedPingsController ?? 0, failedPingsNode) → 10 → rating 0. So a node whose Powerlevel CC implementation doesn't actually run the test gets a 0/10 overall, which is exactly what your screenshot shows.

Your own numbers argue against a real radio problem: the SNR margin of 28 dBm is computed from txReport.ackRSSI - measuredNoiseFloor, i.e. the RSSI of the ACK measured at the controller. That characterises the node → controller path — the same direction the powerlevel test claims failed 10/10. (Caveat: on a routed path the ACK comes from the repeater, so it's strong evidence rather than proof.)

Two smaller things from your post are also worth answering:

• "Max latency is formatted to go with both directions" — correct, and that was undocumented. Latency and route changes are measured only on the controller → node pings; SNR margin is derived from the ACKs and therefore describes the opposite direction. The Info dialog now says so (same PR).
• "Min power level w/o errors: Normal Power" while pings were failing at normal power — that was actively misleading. It now shows none, since there is no error-free power level in that case.

Where the actual fix belongs

The UI can't tell "the node never ran the test" from "10 frames genuinely failed" because the driver collapses both into 0. I've opened an issue upstream so the driver can report them separately and stop letting an unmeasurable direction force the rating to 0.

The "quirk table" you asked about does exist, by the way: a device config can carry compat.removeCCs: { Powerlevel: "*" }, which makes the health check skip that direction entirely instead of scoring it as a failure. If you can attach a driver log at loglevel debug covering one health check on node 12, we can confirm the DZPA1 isn't running the test and get that flag added to its config. Right now no device in the DB uses it for Powerlevel, so we'd want the evidence first.

There is no way to skip the powerlevel test for a single check — checkLifelineHealth(rounds, onProgress) has no such option today.

[gdt]

Thanks for the detailed response. I suggest that there be a vertical split to separate controller ping vs device ping, and then all of the measured values can be n their proper vertical cell within the column, sparing the user who hasn't read and remembered the help text some confusion. That might even lead to separate scores by direction and a combined (min?) score.

I will retest all of this after I am updated to a ui release with zwavejs that splits the 3 zero cases, and probably then I will have more clarity about the DZPA1 behavior.