Please make zwave logs persistent and more detailed

Background: There are people, like myself, who continue to suffer from Zwave issues. Whether it's a minority or a majority, I have no clue. What I know is I'm not alone. There are definitely at least a double digit number of users based on forum posts alone experiencing frequent zwave issues. The problem is, Hubitat gives us almost no tools to debug issues. Example - I woke up this morning to find that 6(!!) zwave devices that were part of an automation did not turn on. What went wrong? Ok I have logs that I can see the on() command was called for each device, so it's not my groovy code that is to blame. But what happened from there? Was a command actually sent to the devices? No way to know. I can't see what on() does and no logs exist to say "sending a zwave command" Did the devices fail to respond? No way to know as there is no information available about the Zwave messages sent/received. What occurred that prevented my switches (various devices by the way, some Jasco, some Enerwave) from turning on? I open up the Zwave logs, I tell the devices to turn on, and they work. So the logs show me nothing useful.

Proposal: Make zwave logs work just like regular logs. They should keep data for X hours or Y messages, not just be a realtime view. The current situation means the only way to find any data about a problem is to be watching the logs WHEN a problem occurs. It means I need to be sitting there, playing with things, and happen to spot a device that didn't respond and see what the logs say. If, as in my example, 6 different issues occur, and then after the fact I want to check the logs, there is no information about what went wrong:

  1. Did hubitat actually send the command?
  2. Did the device not respond?
  3. What happened?

Right now I have absolutely no clue why this automation didn't work and Hubitat gives us no tools to figure it out. Please consider enhancing these logs so that users like myself who are having issues actually have a way to troubleshoot those issues.

I have no ghost nodes, the devices in question have strong directly route to the hub so there's no repeaters in the way. None of the involved devices are using S0 or S2, all of the "try this" type of solutions have already been tried. What I need is information so I can see what's going on then from there, maybe, armed with information, the Hubitat team can find the root cause. I feel improved logging would go a long way to making that possible.

I also want to add there is no documentation on how to read the zwave logs:

seqNo: 207, routeChanged: false, transmissionTime: 1ms, repeaters: None, speed: 100 kbs, rssi: [-83 dBm, N/A, N/A, N/A, N/A], Ack channel: 0, Transmit channel: 0

Are those N/As a problem? Are they good? Is it a problem that channels are 0? How is one supposed to use this information? Why not either make it easier to read, or at least provide us with information on what it means so we can use it to inform decisions.

2 Likes

I strongly second this request. If its the one complaint I have about hubitat its the handling of zwave and the lack of information when having problems. I have a strong mesh, no ghosts, pretty much all zwave+ devices, and every once in a while, it will just stop or pause for a length of time, or I will try to do to much and once and overflow some kind of buffer.

Persistant better zwave logging would do a alot to even have a hope of solving those types of problems

2 Likes