Whats the node red low code way to do basic maths on incoming data?


I have a stream of data coming out of @Steve-Mcl excellent Buffer-parser node. Some of this I grab and set as Global/FLow Variables for other nodes/flows to access.

I need to do some basic arithmetic - i get given amps and volts and need to multply them out to get an actual charge rate - obviously i can just do a function node to do this - but is there a more"Node Red" way to use - say - JSONATA in a change node to do the same thing and hence keep it low code ?


Craig. Have you tried setting the scaler in the buffer parser? Each row (depending on type) has a scaler. See built in help.

Yep i have been playing with that - but my inverters report Voltage and Current only - so then i need to multiply those out to perform the calculation of Watts - could not see anywhere to do that ?

I then feed the output of the buffer-parser to a change node that sets some Globals etc.

Would be nice if it could do the maths and then set that as another variable - just not sure how ugly the Jsonata would be and whether i am better off biting the bullet and just feeding it into a function node instead


It is a relatively palatable bullet.
msg.payload.watts = msg.payload.volts * msg.payload.amps

Yep thanks - thought one of the JSONATA gurus might jump in.

Thanks Again Colin


Hard to say what the JSONata would be without any data.
If just a two properties in payload it would be $$.payload.volts * $$.payload.amps
if you want to apply it to an object/array the please supply an example.

thanks mate,

Here is what it looks like after they are spit out of the Buffer parser node


Just playing with what you have given me in a change node now thanks


I got it after your hint thanks

$round($$.msg.values[0] * $$.msg.values[2], 2)


The msg is not needed $$ references the msg root.
$round($$.values[0] * $$.values[2], 2)
You can omit the $$ to, as you are already in message root. I reference $$ as habit, as when mapping or in a function you would need $$ to reference the root scope.

Aah - still a babe with JSONATA - thanks for the tip


Just because jsonata uses less code characters than the equivalent javascript code, it does not necessarily mean that it runs faster or more efficiently...
Also, when you revisit the flow a few months later, which is easier to follow; jsonata or properly commented javascript?

Just some things to consider Craig....


Hey Paul. I'm sure you know I share that sentiment but I stopped harping on about it at the risk of sounding like a broken record :wink:

However, as @craigcurtin appears to be very keen and eager to learn I thought I'd chime in.

I find the whole JSONata thing a bit odd. There are (according to the register q1 2021 there are 13.8 JavaScript Devs out there that can potentially provide help when you get stuck on a JavaScript problem. I can't find the stats for JSONata but I suspect it is far less than objective C (which is around 1.6m Devs).

On top of the obtuse syntax and lesser potential support, in many cases, JSONata is many many times slower than JavaScript. Look at the screenshot in this flow where JavaScript takes 4ms and JSONata takes 1222ms.

Anyhow, I would like to finish by saying, JSONata definitely has its benefits and does have a part to play, just be aware of the pitfalls before you invest a lot of time and energy into it.

1 Like

Hey Guys,

Thanks for chiming in (both of you) - very much appreciate the support and guidance.

I am usng this "dabbling" in JSONata as a bit of a learning exercise - but it is definitely a struggle - particularly when trying to translate JSONata resources into Node Red.

I spent more than an hour yesterday researching how to achieve the One Liner that @E1cid provided and kept going down the rabbit burrow !!

I will ultimately code it into a function node i think as it makes more sense but it was a worthwhile learning exercise.


Watts = Volts x Amps only works for DC applications.

For AC circuits it's.

Watts = Volts x Amps x Power Factor

1 Like

The example given is 50v so safe to assume it's DC since the field says battery. But you are correct, AC is orders of magnitude harder to calculate especially since most monitors outputting raw values rarely if ever give a power factor, at best you can assume inductive loads are between 0.5 and 0.7 whilst pure resistive loads should be 1.0.
It does get very messy, and it's the reason I'm personally avoiding having a smart meter since they all over charge where the PF is low (Which is pretty much everything in my house barring the kettle and toaster...)
... :smirk:

Is not the technology used to measure the power in a smart meter the same as in a dumb meter?

Yep thanks for that - was aware of that one - i use an IOTAWATT which accurately reports the power factor at play on my AC circuits.


No, It's to do with apparent power and actual power as measured in watts. Let me look to see if I can dig out a decent YT video on it. I think BigClive did something on this a while ago.

New smart meter are capable of measuring actual power and perceived power. In the UK they should be set to perceived power(for domestic dwellings), At some point the UK government will allow them to switch the to actual. At which point Electricians will have to add PF correction, as they do for industrial installations. Understand we are just cash cows.

Have you got a link explaining that?

References I have found suggest that smart meters do take power factor into account, as they work by multiplying instantaneous volts by instantaneous current and integrating the result. This is effectively the same way that an analogue one works.

However, I think also low power factor causes problems for the electricity supplier and so industrial users may be charged extra based on the power factor in order to encourage them to improve the PF of their loads.