Hi,
After upgrading to 4.02 i thought i have some cleanup, remove unnecessary items and calculations done in NodeRed, what i need is to pass a parameter to a transformation, this is a cut down item file
(function(d, f) {
var DIVIDE_BY = 10;
var MyData = parseFloat(d) + parseFloat(f);
var result parseFloat(MyData) / parseFloat(DIVIDE_BY);
return result.toString();
})(input, offs)
Cutting down the scrip and hardcopding the parameter, and removing the ?offs=9 it works fine, but i would like my script to have this parameter as its different on each item. And while im at it, and I know that there is so much knowledge out there, pls show mee how to pas multiple parameters…
Your item syntax seems correct. I have tested it and also tested the JS that I posted above. offs is simply a variable that’s been injected, with that name, into the scripting engine so you can access it. I’m not familiar with JS but my test script doesn’t reference it in the function definition like what you think it should.
It should work either way. input is injected the same as offs is in this case.
It’s on my list of things to explore but I don’t think the (function... stuff is required either. I’m sure it’s JS best practice but we are not coding stuff that runs in a webpage or has to live along side a bunch of other libraries. I think the following would work.
Quantity definitely does have a toString() so that call should be redundant. But add and divide requires either a String or a Quantity, not just a plain number. It doesn’t know what units the plain number should have. Another alternative is to pass the 9 with units.
Or strip the units and add them back.
var value = (Quantity(input).float + parseFloat(offs)) / 10;
return value + ' °C'
I’m not sure what happens if you pass what is already a float to parseFloat. At a minimum it’s redundant. Maybe that’s the error?
Doh! That’s right. But I wonder if it works the same as for UI script conditions without the return.
In that case it works the same as Rules DSL lambdas. What ever the last line of the script evaluates to is what gets returned.
That depends on the unit. The library can be smart. I don’t think °C^2 is a thing so it should either just fail outright or stick with °C. The library is smart enough to recognize that V*W = A (which was a surprise to me) .
But if it’s not smart in this case, the units need to be stripped off and the added back after the calculation. I show how to do that above.
I’m trying to put a few minutes together to test some things out.
Again, MyData is already a float at this point. I don’t know if parseFloat works if you try to parse something that’s already a float. And even if it can, it’s pointless to parse it. The same goes for DIVIDE_BY. They are already numbers. There’s nothing to parse.
Notice how the transformation you report works just fine doesn’t parseFloat div.
Ok, some strange behavior, I experience I need to remove, and the add the item each time to get the changes to stick.
Then i tried this, but with no luck.