Closed kpine closed 4 years ago
Follow up question, is it intentional that commands without parameters require a payload? I'm no MQTT expert, but from my understanding payloads are not required. I was assuming that commands with no data did not need a payload. For example, this won't work:
OpenZWave/1/command/removenode/
But these work equally well:
OpenZWave/1/command/removenode/
""
OpenZWave/1/command/removenode/
"asdfasdf"
OpenZWave/1/command/removenode/
"{}"
Basically, as long as a command has any payload, it will be accepted by ozwdaemon. I produced the crash above because I sent the wrong data to a command that expected a JSON object instead. If a payload was required, would it make more sense to force it to be something consistent like an empty JSON object, or is it fine the way it is?
BTW, the HA code is sending the empty string ""
, which is how I was able to determine this. I was trying to issue the removenode command manually via MQTT and it was not working, then noticed HA sends all commands with payload ""
when no parameters are set.
Fixed the crash - All Commands will need a "Payload" at least to pass - which brings me to:
is it intentional that commands without parameters require a payload?
I'm also not a MQTT export - but based upon the API used to talk to MQTT - The way we "remove" retained topics is to send a empty payload - So I'm assuming we should send something (a empty JSON object now for example).
Secondly - The crash was actually happening in the logic that checks if we have a valid parameters for each command. There are a few commands (cancelcontrollercommand for example) that don't accept any parameters - This change means we only accept a empty JSON object "{ }" now, not a empty string. (otherwise the logic around that becomes a lot more complex!)
@marcelveldt For your info - ozwdaemon will error out if your sending empty strings as @kpine pointed out now.
No arguments from me, I'll just add a few notes.
I'm also not a MQTT export - but based upon the API used to talk to MQTT - The way we "remove" retained topics is to send a empty payload - So I'm assuming we should send something (a empty JSON object now for example).
That sounds about right... I think. The spec says:
It is valid for a PUBLISH Packet to contain a zero length payload.
For messages with the retain flag an empty payload has special meaning:
PUBLISH Packet with a RETAIN flag set to 1 and a payload containing zero bytes will be processed as normal by the Server and sent to Clients with a subscription matching the topic name. Additionally any existing retained message with the same topic name MUST be removed and any future subscribers for the topic will not receive a retained message [MQTT-3.3.1-10]. “As normal” means that the RETAIN flag is not set in the message received by existing Clients. A zero byte retained message MUST NOT be stored as a retained message on the Server [MQTT-3.3.1-11].
Whereas if the retain flag is false:
If the RETAIN flag is 0, in a PUBLISH Packet sent by a Client to a Server, the Server MUST NOT store the message and MUST NOT remove or replace any existing retained message [MQTT-3.3.1-12].
So, you would probably be fine allowing the commands to have no payload, but it makes sense to make the API uniform.
Thanks for the headsup. We'll adjust accordingly.
Hi @marcelveldt, do you have plans to address this one soon, or would you like an issue submitted somewhere?
I used payload data that was in an unexpected format and it crashed.