#Troubleshooting Node 24

1 messages · Page 1 of 1 (latest)

prisma cliff
#

I don't see node 24 being dead at 11:30. About an hour earlier, it was detected as being alive, and the only mention of the word dead in combination with node 24 is at 19:10.
At 19:10:07, the driver tries to refresh the Meter reading, 1s later Node 22 spams a wakup notification, another 5s later Node 19 spams a temperature reading.

#

This behavior could mean that your controller isn't acknowledging the commands it clearly receives. It could also mean that any node along the return route isn't receiving and therefore not forwarding it.

#

Anyways, this spamming goes on for a bit, and it seems to drown out the command the controller tries to send to node 24, so after 3 attempts with no response from 24, it gives up and marks the node as dead.

#

Interestingly, an hour later, Node 19 wakes up again just as the driver tries to reach node 24.

lusty granite
#

That matches with the activity log. I don't know why the last active was so different. I guess maybe more importantly I don't know what command was being attempted to fail to begin with.

prisma cliff
#

Node 24 supports Meter CC. If no command from that CC has been received in over 6h, Z-Wave JS refreshes the values to match the specification.

#

That's the original command that fails

lusty granite
#

Nodes 16-22 are very talkative because they are remote thermostat sensors.

lusty granite
#

I have the meter stuff all disabled.

#

*had the meter stuff disabled, they suspected this might be relevant

prisma cliff
#

Yeah, but the command doesn't even reach the node - or the acknowledgement doesn't come back.

#

Actually not answering wouldn't be an issue. It's not acknowledging the command at all

lusty granite
#

Afterwards, pings don't, either.

prisma cliff
#

You did the typical troubleshooting stuff?
Controller on a USB extension etc.?

prisma cliff
#

Probably not a big deal though, the issue looked more like temporary connectivity issues

lusty granite
prisma cliff
#

yeah, all of them

#

19, 20, 21, 22

lusty granite
#

OK, I'm going to paste four separate messages I got from Inovelli since I sent you logs:

Do you have energy reporting enabled? Out of curiosity if you set energy reporting to every 30 minutes I wonder if it would make a difference.

I'm just curious if a setting of like 30 minutes would prevent the switches from saying they are unavailable. Obviously only a Band-Aid but I'm just wondering.

I think there was one person that said he saw the issue on firmware 1.2. The engineers think it might require an SDK update (on the firmware) which will require a pretty hefty overhaul. So we have decide when we will fit it in with our other projects.

Seems to me that it is a possible SDK bug that is exposed by how the hub communicates to the device. So it can be avoided at a hub level, but fixed on the device firmware.

prisma cliff
lusty granite
#

When they mention "how the hub communicates," that might be relevant, because they also said it's only happening with Z-Wave JS,

prisma cliff
#

From this you can see that the stick tried to reach Node 24 29 times over 11.5 seconds:

2023-09-06T19:10:46.151Z DRIVER « [REQ] [SendDataBridge]
                                    callback id:            249
                                    transmit status:        NoAck, took 11460 ms
                                    routing attempts:       29
                                    protocol & route speed: Z-Wave, 40 kbit/s
                                    routing scheme:         Explorer Frame
                                    TX channel no.:         1
                                    route failed here:      28 -> 24
#

All 29 attempts failed, it resorted to explorer frames (which effectively floods the network) in an attempt to reach it somehow

prisma cliff
lusty granite
#

It's not far from the hub, normally a direct connection with 100 kb/s.

lusty granite
prisma cliff
#

Yeah that one should be live in an hour or so

lusty granite
#

Nice, as production, or pre-release?

#

I just checked, and Node 19 appears to be configured to do periodic updates every 2 minutes (vs 1 minute), but humidity reports are every 5 minutes.

prisma cliff
#

stable

prisma cliff
#

Wakeup -> Wakeup interval

#

It's not a configuration option

#

... well technically that is configuration but not Configuration CC

lusty granite
#

Yeah, that's 1 minute. Why should it need to wake up at all if it's going to report every 2 minutes? Where does that default come from?

prisma cliff
#

No clue. The only thing that enables is that your queued commands are handled every minute

#

But that kills the batteries

lusty granite
#

The questions are because I'm leery of changing much with them since they are communicating with the thermostat in some proprietary way.

prisma cliff
#

Wakeup is independent of other reports

lusty granite
#

I mean there could be a Trane reason it needs to wake up that often (or maybe not). The thermostat isn't Z-Wave, but it has a Z-Wave bridge, and I have that set up as a secondary controller, so that's the only way they're on this network, but the thermostat itself shows them as remote sensors based on their serial numbers.

prisma cliff
#

I mean you could try increasing the wakeup interval and see if things still work. The only thing is that changes to the wakeup interval require the device to wake up to be applied. So if you put it on 3 hours or so, you might have to wake it up manually to go back if needed

lusty granite
#

So even if it's reporting temperature every 2 minutes, that wouldn't count as waking up?

prisma cliff
#

nope

#

waking up means the device is actively listening for commands

lusty granite
#

Good to know. Probably worth trying after I finish my battery experiment.

prisma cliff
#

reporting temperature is just: go out of deep sleep, send command, go back

lusty granite
#

Alright, I'm going to try to change the energy reporting threshold to 18,000 for now (vs the 1,800 I set it to earlier today) and monitor. I'll definitely be interested in trying the wakeup setting soon because I'm going through 6 AAA batteries a week, just don't want to change that while I'm trying different brands to see what's most cost effective.

lusty granite
#

I've got a dead switch again with the power reporting enabled, but I'm guessing it could be the same problem if I had home assistant restarting or rebooting when the report tried to come through. Anything specific I could search for in the log myself?

#

Also, thanks for your help on this before, and it turns out the default sleep interval on those nodes you asked about is 7 hours, so maybe I did something goofy really early in and forgot about it.

lusty granite
#

Also, I just looked at the network graph and another node is showing a route through the dead node, but it's able to communicate and updating the network graph after it communicates doesn't change the route shown...

prisma cliff