@fblackburn There seems to be something amiss on 0.0.25. I don't know if it is new for 0.0.25, or if it happened in 0.0.24 as I didn't install 0.0.24. Worked fine in 0.0.23, though.
If I specify certain msg.command on an incoming msg to a command node (specifically commands that require an argument), it will fail (it doesn't send the specified arguments to Maker API).
On the Hubitat side I also see the error, and it is pretty clear that the argument never got passed?
No, the payload is 34f26d (a hex value for Hue, Saturation, and Level)
I want to split this into three values: 34, f2, 6d. I think I'm about there using node-red-contrib-string.
Another cool thing about that Pushover node is that you can send messages only to specific devices by specifying the device name in msg.device in the incoming message to the node.
I have many devices in pushover, so that is a crucial feature to me.
@fblackburn, I have 0.0.24 installed with the same issue.
I edited the code as follows to correct from that version:
msg.commandArgs does not appear to exist so it always be null. This breaks in the scenario that @JasonJoel described above (ie command override exists but argument override does not)
Also including line 24 as an else if breaks in the reverse scenario. Converting that to a separate if allows all the scenarios I tested to work.
Edit: please note that my edits apply to 0.0.24..I have not looked at 0.0.25 so hopefully this still applies.
This behavior is to fix another issue you wanted fixed (hard to link it, I'm not on a computer). When you override command with input message, you don't want to that node send the argument predefined in the node.
Ex: default node send SetLevel 50. If you input message override command to Off, then we don't want send 'Off' with argument 50
To fix this behavior, when you override the command, you MUST send argument in the message if needed. IMO is totally acceptable since when you override the command, then the argument predefined in the node make no sense
Anyways, they are another alternative (with more work), to fetch ALL device commands available on node start and on each new message determine if the command need to have an argument, then takes the argument from the message or node, if not, then remove the argument from the node
OK, I should have explained it differently. Even if I specify msg.command and msg.arguments it does not work - it omits the msg.arguments specified. Any time you specify a command that requires arguments in the incoming msg, it drops the arguments specified (in the msg.arguments or the node arguments entered).
I agree completely. If we can get that part working, it would be fine with me. I agree you should discard the node arguments if you over ride the command - for the reasons you already mentioned.
That said, if it is too messy to fix I would also be fine with it going back to 0.0.23 behavior, and just leave it up to the end user to not specify arguments when there should be any. Even more polling on node init to work around this in a more elaborate fashion seems like a bad idea.
Thanks, and no hurry on my side. I worked around it already, so am OK. I bet there are others that have broken flows, though, and don't realize it/understand why.
@fblackburn, this is occurring because of line 22 of comands.js.
I believe what you meant to have here was commandArgs = msg.arguments
instead of commandArgs = msg.commandArgs
msg.commandArgs, and therefore commandArgs, will always be null so "setLevel" will always end up being sent with no arguments and cause HE to spit out an error.
Yes you 're right. Since it's the second time I break the input logic with a refactor I will try to add some tests with the Node-RED test framework before releasing the fix (probably today or tomorrow). In the meantime, if you cannot wait, you can install nodes from github repository (fix is on master)
I can wait for your release..I only use it for testing right now. Very impressed with what you built here and your willingness to update based on feature requests/feedback.
