Zwavejs2mqtt: [feat] Add some kind of transaction id to API responses

[LordMike]

Is your feature request related to a problem? Please describe.
When issuing getNodes or similar over MQTT, it can take a long time to get a response. Likewise, when issuing many commands over MQTT, like setValue or getAssociations, it can be tricky to seperate requests from responses, since the responses all look alike. At least for those with arguments, one can compare the arguments to verify it's what we wanted..

Describe the solution you'd like
Add another value to requests, which is optional, and merely echoed back on responses. Like transaction, id or token.

Sent:

zwavejs2mqtt/_CLIENTS/ZWAVE_GATEWAY-HomeMQTT/api/getAssociations/set
{"args":[10,20],"token":"abc"}

Response:

zwavejs2mqtt/_CLIENTS/ZWAVE_GATEWAY-HomeMQTT/api/getAssociations
{"args":[10,20],"token":"abc","data":{..some data..}}

This way a client can create their own identifier and match up responses.

Describe alternatives you've considered
I'm currently comparing arguments, but comparing json objects is cumbersome, at least in .NET.

Additional context
N/A

[robertsLando]

Absolutely! Nice idea :)

[robertsLando]

@LordMike Ready :rocket:

[LordMike]

Wouldn't this still require me to compare json objects? :)

[robertsLando]

@LordMike If you add an id to the request message, you will find the same id in the response payload origin.id

[LordMike]

Oh.. You're right.

👍

[LordMike]

That means args are duplicated :D ... origin.args & args

[robertsLando]

Yep was to keep back compatibility but I could remove it

[LordMike]

Yep was to keep back compatibility but I could remove it

Entirely up to you. I'm satisfied :)