What is the correct MQTT command to call refresh values on a device?

[Mastiffen]

My problem is that one device (a lock) very often comes up as dead after a restart of the Pi. I have of course tried to remove and add again, fix and rebuild routes (the lock is one wall and two meters from the controller), but nothing helps. Well, almost nothing. Because going into the GUI, clicking the device (named ID Lock 150, so the topic for it in MQTT is zwave/ID_Lock_150/#), "Advanced" and "Refresh values", which is noted as "Update all CC values and metadata. Use only when many values seems stale" will wake it up from the dead every time. Home Assistant does have a service called zwave_js.invoke_cc_api, but that fails when the node is dead in the GUI for Z-WAVE JS UI, so I guess I will need to invoke it with an MQTT message. But I don't know the correct command to do that, and I have searched and searched. Can somebody please help me?

[robertsLando]

https://zwave-js.github.io/zwave-js-ui/#/guide/mqtt?id=refreshccvalues

[Mastiffen]

That's version v2. Or I guess it can be version 3, depending on the device.

Edit: Yes, I found at least one device in my house where it is version v3. But it's still CC 134.

[AlCalzone]

So that explains it.
Version CC does not have a method to refresh values, so the call doesn't actually do anything.
Configuration CC (112) does, but causes potentially a shitload of traffic.

Your problem seems to be slightly more nuanced:
The device has bad enough connectivity that most (every?) communication attempt requires multiple retries.
Pinging does not attempt multiple routes and only tries the last working one. If that route has failed in the meantime, the ping will fail, so Z-Wave JS does not consider the device to be alive. Querying information from a device will try different routes and even if one query fails, another one may go through and mark the device as alive again.

All of that is just a terrible band-aid though. You should really look into why the device can regularly not be reached. Oftentimes this isn't actually a problem with the specific device, but rather a bad placement of the controller, or too much traffic caused by other devices:
https://zwave-js.github.io/zwave-js/#/troubleshooting/first-steps

I can also look at a driver log (loglevel debug) of the startup and successive communication with the lock to see if I spot anything.

[Mastiffen]

Thank you for answering! The 112 does cause bit of traffic, but not a shitload here, there is a flurry for about ten seconds and then it's done.

Actually the connectivity is not bad as long as it's not marked as dead, the controller (HomeSeer G800) and lock are within two meters and one wall from each other in one location, the identical lock and controller I have in another location is within four meters and one floor. When they are marked as dead, it takes extra time to open the lock, and my wife is not very patient with automation stuff, after some bad experiences when I first started playing with this about 30 years ago, those have stuck with her. 😂🤣 When the refresh is sent, there are no such problems until the next restart of Z-Wave JS, the lock is open within 3-4 seconds. And there is not too much traffic on the network either. So you don't have to waste time on this, but thank you very much for the offer!

There are a few other nodes that very infrequently come up as dead, but they are all fixed with either a ping or that refresh. I have now (with help from the Home Assistant community) pinging in an automation that runs every minute and pings the nodes that are marked as dead and another automation that runs every ten minutes and one minute after startup, check for dead nodes and do a refresh of CC 112 on them. That combination seems to work 100 %, as far as I can see.

[AlCalzone]

I have now (with help from the Home Assistant community) pinging in an automation that runs every minute and pings the nodes that are marked as dead and another automation that runs every ten minutes and one minute after startup, check for dead nodes and do a refresh of CC 112 on them. That combination seems to work 100 %, as far as I can see.

If you don't want to look into this, that's fine - but what you describe here are not the signs of a healthy mesh.

[Mastiffen]

I can see that, yes. The problem is that there is really no reason for that. Both locations where set up from the ground up this summer with the G800 stick. I agree there is something wonky about those locks, and it's strange that other devices infrequently drops off, and the symptoms are identical at the two locations. I keep everything updated, and there are 50 devices in one location and 60 in the other. A good mix of powered devices which should do range extension and battery powered devices that don't. The mesh was built by adding the controller and then building outwards from that, and nothing on the map view shows more than three hops. I have done rebuild routes on device by device several times.

I can only conclude that there is something with the combination I have of stick, software and a few devices (the lock and some cheap Nexa inwall relays are the main culprits, and which one that is out after a reboot, if any, is sort of like starting up an old VW Passat and looking at the warning lights on the dash - totally random) that does not like a restart of the system. But if the bandaid works as well as it seems so far I do not want to spend the time and money (including electrician - changing relays in a wall is not legal to do in Norway unless you are an electrician, and they cost a lot in Norway) to replace the relays. And the Norwegian constructed ID Locks works perfectly in all other respects.

But what I did get by moving to the G800 stick (or maybe by setting it all up again after 7-8 years on different software connected to the Aeotec Gen 5 - who knows?) was a MUCH more snappy system. Now the lights turn on the second movement is detected, and everything else comes alive when it should, not five seconds later. Which is very important for the WAF.