Same subflow, different happening on different machines

Well the change node hasn't "worked" as the topic is not being set. Why you don't get the error message I don't know.

Sorry where are you seeing that?

In the image you posted, the last debug output (To Button) has not got a topic. The Change node in the subflow (#1) should set the topic.

In fact it isn't working even with the quotes.

Sorry, looking at the wrong output. You have got op1 and op2 upside down in the subflow

1 Like

to button doesn't need a topic.

It is going to the button.

the change node is the subflow sets the topic on the second output.

Or that's what I believe is happening.

When the button is pressed (going in - looped from the button's output) it needs the topic set (well, really it doesn't) only so the subflow can make sure it is from the right MQTT channel,

Just saw your reply.

All good.

Yeah, that is a bit of a bad thing.

I try to keep them going down with 1 at the top and 2 below...

Just wasn't ...... nice in the layout in this case.

again: good catch though.

For the sake of it though:

This is two screen shots on the machine that errors.

With and without the ' around the power in the #1 change node of the subflow.

The error given:

{"_msgid":"f88a6d283eb807c8","topic":"ERROR_REPORT/BedPi/RealWorldControl","_event":"node:411be8a70a813fe5","error":{"message":"Invalid JSONata expression: Cannot read properties of undefined (reading 'startsWith')","source":{"id":"c57d4af5faa4d2b6","type":"change","name":"#1","count":1}},"settings":{"input":"2024-02-02T22:10:54.075Z","input_format":"","input_tz":"Australia/Sydney","output_format":"YYYY-MM-DD HH:mm:ss","output_locale":"en_AU","output_tz":"Australia/Sydney"},"time":"2024-02-03 09:10:54","payload":{"message":"Invalid JSONata expression: Cannot read properties of undefined (reading 'startsWith')","source":{"id":"c57d4af5faa4d2b6","type":"change","name":"#1","count":1}}}

See the #1 as the name of the node that made the error.

This part of the error message throws me.
Cannot read properties of undefined (reading 'startsWith')

MAYBE because it is seeing an undefined variable name being used...
But shouldn't that give a different error?
(And.....)
why is it failing on one machine and not the other?
:shrug:

Disconnect the MQTT Out node and replace it with another Debug node and show me what you get when you click the Inject node Button (without the quotes).

Also do one further thing for me, double click the subflow (the one in the flow we are considering) and select Edit Subflow Template and check the the #1 node in there does not have the quotes. I just want to make quite sure you are looking at the correct subflow.

Got to go now, it is late, will have another look in the morning.

1 Like

I have been editing the subflow (via double clicking on it and opening subflow template)

The MQTT out node to the device is dead as the device is not connected.
Which is why I have the Online Offline buttons you can see.
On one machine the Offline button is not shown. (Anyway....)

I need to click the Online to get the subflow awake and accept any input.

Quick touch base with something that may (or not) be confusing you.

The Buttons are not quite as simple as you may think.

They have 4 (well 5) states.

1 - OFF/OFF
2 - ON/OFF
3 - ON/ON
4 - OFF/ON
(5 - offline)

OFF/OFF looks like this:

Screenshot from 2024-02-03 09-43-34

Note the background RED colour.

When the two states (the first and second part shown above) do NOT match, it is ORANGERED. NOT RED.
(font color = ) in the message.
So when I press the button it changes to what ever is needed and makes the background ORANGERED.
Then when the MQTT message is received and CONFIRMS the change, it is changed to RED.
Makes it more realistic - IMO.
So you may be getting confused with that part.

So, here's what happens - better walk through of the messages.

1 - I click the Online to enable the button and tell the subflow that the device is online.
I'm not sure if there are any more messages off the top of the screen. I was focusing on showing you the MQTT message - as requested.
2 - I press the button and you see the X going from the button back to the subflow
3 - You see the ON message being transmitted (MQTT) with the topic to the device and the output to the button node making it set the button to the ON state but with the ORANGERED background.

If you look at the last debug output on that image you will see that the change node has not, in fact, worked correctly. If you add the quotes it should give you the correct topic. Why it does not show the error message I don't know. Someone who knows more about how JSONata is implemented in node red might know. There must be some difference between the two systems that causes it.

1 Like

Thanks for all the time you put in that.

Appreciated.

Yeah, I hope someone who knows more about JSON can explain it more.

Yeah, the debug node isn't getting/showing the right message.

Just the error I got confused me as I don't see the mechanics of understanding what it said and equating that to missing ' around a variable's name.

I think you said the two systems are running on different hardware. Possibly the version of JSONata available for the two systems is slightly different.

Maybe.

But that's above my pay grade. (I think is the saying.)

:wink:

So the $env(...) function is not part of the JSONata language -- that and the context functions are available only inside the node-red runtime implementation... just fyi...

I am seeing the same error message when trying to access an env var using the bare word power:

topic & '/cmnd/power' & $env(power)

image

An odd message to be sure... must have something to do with the implementation of the $env function.

If you don't quote the word power then JSONata tries to resolve that as a value, which is 'undefined'. It then passes an undefined argument to the $env() function, which fails.

But when you quote it like $env('power') you are passing a string to the $env() function, which returns undefined if the env variable does not exist. And trying to concatenate the string cmnd/power & undefined returns a value of undefined.

So the only thing to conclude is that your two systems have different environment variables defined. The one that does NOT throw the error MUST have an env variable named "power" defined, and the other does not.

It might be safer to do something like this in your change node:

The node is inside a subflow, the power env var is one of the subflow properties. So the var is defined and has a value in both cases. I see the same symptom as @Trying_to_learn, with the quotes it works as expected, without the quotes I see the error message. On the system that appears to be working $env(power) appears to return nothing. The rest of the JSONata expression works as expected.

Ah, right, subflows operate differently. If the intention is to look up an env variable named "power", then he will definitely need some quotes -- otherwise the evaluator will pass an undefined to the $env function, which will never work.

Unless I misunderstood, and the intention is to pass in a msg.power property, containing the name of the env var to actually look up? For example, if the incoming msg has {"power": "total"}, then the JSONata expression would end up being $env("total")?

As for the odd error messages, I've looked at the evaluateJsonataExpression() utility function and can see no reason for the error string being returned. Node-red runtime just echos whatever error string was returned from the JSONata library. I guess that's the next place to look.

Interesting -- it looks like this same issue came up in May of '21

Nick and Steve added some code to ensure that context keys are valid strings before doing a lookup, but I suspect calling $env(undefined) from within a jsonata expression is somehow bypassing those checks.

Not quite.

In the change node I set up msg.power in an attempt to get around the problem before I knew what it was.

I made a whole lot of mistakes with the subflow.

Starting with env$( ) instead of $env( ).

Then I forgot the ' around the name.

Luckily it is now working.

I hope I can put what I have been told/shown to good use.

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