Zwavejs2mqtt: [feat] Show message queue for nodes, potentially a log of messages

[LordMike]

Is your feature request related to a problem? Please describe.
When troubleshooting, operating, or working with my z-wave network, I find myself constantly wanting more technical information. Right now, when migrating from Z2M, I had a number of un-interviewed nodes (battery operated), which I went around and woke up.

Some of the devices became interviewed, but most did not. I do not know, at this point, if this is because zwave-js did not send the commands necessary to interview a node when it wakes up, or if the node had some failure or if I did something wrong. It would be useful here to have a list of messags, where one of them might be of a "give me info"-commandclass type.

Other times, lights or devices will be slow to respond. When troubleshooting this, I'd really like more information on if a message is pending to be delivered to a switch. Right now, I can only guess at what is going on. In these cases, it'd be really helpful with a list of messages queued for delivery, where one of the messages could be a "set light to 20%" command, alongside information like _when_ it was added and if it's being retried or maybe even why it's pending (node offline, retry, controller dead ..).

Describe the solution you'd like
A list of sorts, for each node, maybe the controller as a whole, that lists queued messages. It's my impression that z-wave libraries will queue messages to be sent, such as when the controller is ready to send a message (when there's traffic), and whenever a node wakes up from sleep.

An addition to this request, would be to keep the messages that were sent, alongside details like "when it was added" and "when it was sent" (time difference), "delivery attempts" - and if z-wave does this: "when it was ack'd". This log wouldn't need to be stored or anything.. Keeping the last hour/24hour/100 messages in memory is enough. You can probably build this log yourself from logs, but that'd take forever.. :)

Describe alternatives you've considered
I could go crazy in logs each time something happens, but I'd rather not..

Additional context
N/A

[LordMike]

For lights, information on when messages were queued and delivered would help immensely at identifying slow devices. If a device is noticeably slow, I'd like to know if I should fix something myself, or complain to the vendor to have them make it faster..

F.ex., if the command to turn on was received via MQTT at T+0ms, delivered and acked at T+60ms, but the lights first turn on at T+500ms (as measured by humans).. then I know the device is at fault. Alternatively, if a message was acked at T+500ms, I know the network is slow, congested or unstable.

[robertsLando]

@LordMike I think that this may be more related to zwave-js lib?

cc @AlCalzone

[LordMike]

I figured it might require some additional api's.. :)

[AlCalzone]

Depends on https://github.com/zwave-js/node-zwave-js/issues/985

[robertsLando]

@LordMike Closing this, follow updates there :)

[LordMike]

So when the API is created, recreate this issue to track the creation of UI elements? :)

[robertsLando]

Sorry thought this was just releated to logging, reopening this so for when this will be implemented on zwavejs side to make the UI elements :)