Help with trick for message parsing true/false -> set/clear

General
1

I know this is Baby coding for people in the know.

Alas I'm not one of those.

Problem/scenario:

let uv = msg.payload.underVoltage

That is a true/false message. :frowning:
Downstream, it needs to be human readable.

So what's that trick:

uv = (msg.payload == false "clear") || "set"

Ok, update:
something like this:

msg.payload = msg.payload === true ? "set" : "clear"

Where it does the check, and if it is correct, it sets to one value and if false sets it to the second.

I worded that carefully to not reuse true and false.
Ok, I maybe should have used a better original scenario.

But it is what it is.

Someone - please?

2

If you are certain that the message will be a Boolean true or false then its as simple as this.

uv = msg.payload ? "set" : "clear"

If it could be undefined, null or other values then you would need additional checks, something like this should be quite bullet proof :wink:

msg.payload = msg.payload != null && 
              (msg.payload === true || 
               (typeof msg.payload === 'string' && msg.payload.toLowerCase() === "true") || 
               msg.payload === 1) ? "set" : "clear";
return msg;
2 Likes
3

I don't think uv = (msg.payload == false "clear") || "set" is valid in JavaScript

It looks like you're trying to use a conditional or ternary-like expression with this syntax..
uv = (msg.payload == false) ? "clear" : "set";

The construct you're referring to is called the ternary operator (or conditional operator). It's a shorthand way of writing an if...else statement in many programming languages like JavaScript, C, and Python (with a different syntax).

It is equivalent to...

if (msg.payload) {
    uv = "set";
} else {
    uv = "clear";
}

The syntax is...
condition ? value_if_true : value_if_false;

You can also use the same 'trick' with other data-types. For example integer values.

So in a Function Node you could use...

msg.uv = (msg.payload >= 47) ? "clear" : "set";
return msg;

Or this if you want the result written back into msg.payload...

msg.payload = (msg.payload >= 47) ? "clear" : "set";
return msg;
1 Like
4

This is one of the few places that I would use JSONata. In a Change node:
payload ? "set" : "clear"

2 Likes
5

Thanks folks.

I've documented the structure for future reference.

Now I'm left with WHO to say is the solution. :wink:

6

Yeah, thanks

I got carried away with that.

Yes, the ( ) should be around the test.

7

At the end of the day you need to use whatever 'format' you will be comfortable with. These 'tricks' (as you call them) are all well and good, but you need to consider... "will I be able to remember them in 6-months time?" This is especially true for people who dip in and out of programming at irregular times. So it might be easier to use a good old "if then else" construct.

1 Like
8

You are correct.

I am hoping that if I note it down somewhere and can remember where... :wink:

I can build on it.

1 Like
9

The parentheses around the condition (msg.payload >= 47) are not strictly required, but they improve readability and help avoid confusion, especially when more complex expressions are involved.

So both of these should work the same:

msg.payload = msg.payload >= 47 ? "clear" : "set";
msg.payload = (msg.payload >= 47) ? "clear" : "set";
2 Likes
10

Apologies for muddying the water but these different code snippets are only equivalent if the only possible values of msg.payload are boolean true or false.

IMHO, when handling boolean datatypes it's best to use the === true operator because that make it clear that you are expecting a boolean. The alternatives == and if (msg.payload) behave differently if fed a numeric or string value.

So for me this is the clearest and most compact code:

uv = (msg.payload === true) ? "set" : "clear"

ie if (msg.payload is boolean and it's value is true) ....

1 Like
11

I agree. I think it helps brake things up into sections.

12

I agree with you.
@Sean-McG mentioned that fact at the start of the thread.

13

Yes he did.

His example code is not only bulletproof but a bit impenetrable. :winking_face_with_tongue:

1 Like
14

Yeah, and sorry as I said, I was torn to who's is THE solution.

No offence to anyone.

15

Andrew's premise was that the payload is true or false. If that is the case then there is no need to check for exact equality with true. If the value is actually something else, "x" or 7 for example then just using if (msg.payload) would result in "set", whereas if (msg.payload === true) would result in "clear". Which one of those is what Andrew would actually want should determine which syntax to use. If he is confident that it will always be a boolean, or does not care, then the simpler and more efficient if (msg.payload) can be used. If a non-boolean input should result in an error or other output then it is necessary to test for === true, and if it is not then test for === false and otherwise take appropriate other action.

16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.