[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 :)

[LordMike]

I just had a thought that led me back to this - an indication on each node value that a queued message is pending, would be helpful :)

Right now, it's very "fire and forget", especially for sleeping devices. You put in a value, click send and then ... nothing.. If the device wakes while you're there, you get a toast saying "Some api call succeeded" (which could be for any device).

I was setting up wake intervals today, and I think I sent the same intervals a few times to sleeping devices, partly because it seemed like they didn't respond (when I woke them).. Having a small flag on value fields saying "there is a queued message for this field" would help :)

As an example, the "send" button could be a new color if a message is queued, like .. blue. E.g. Grey - default, green - feedback on "send" and blue - pending.

Bonus if you show what is pending.. :)

[robertsLando]

I already have a flag on ui to mark values that are waiting for a response, this is the reason why after the message 'Some api call succeeded' you should also get 'Value updated'. Wondering if it would be better waiting to receive a value update or just wait for the api to return?

@AlCalzone

[LordMike]

(where's this flag? :))

[robertsLando]

@LordMike Not shown at all, it's a property I set on the valueId object, but I don't store it on backend ATM, it's just on frontend side. Like I said I would like to know @AlCalzone opinion on this

[AlCalzone]

AFAIK you can actually wait for the API call to resolve or reject. That should tell you all you need to know.

[LordMike]

How would that work for really long calls?

My use case is setting the wake up time. I’d originally set it to a week, which gives insane battery lifetime, but I’m trying to bring it down. After a few days, I wanted to see how many devices had updated to the new value, but couldn’t tell if they were still pending.

And that’s not even to mention the queue might not persist so a reboot at random (snap deploy) would stop the project :p

[robertsLando]

How would that work for really long calls?

On my side i store that UI flag on valueId object on backend too so as long as project runs it will wait... For sure if you restart it I will loose this info, I'm even not sure zwave-js could restore it as I dunno if the result of a write could be received after a reboot of the driver and parsed correctly