Should work just fine. When using file-based rules, for example JSRule, consider putting them into a dedicated context (see JavaScript Scripting - Automation | openHAB), this way second-by-second updates perform the calculation in a dedicated thread and not the per-file-thread.
Not really. Technically it should be possible to write a transformation that does this, but it is better suited to be a rule.
This also isn’t support AFAIK. I think this is the case because whilst a SUM is quite straightforward, for a subtraction you would need to define from what to substract what.
Another idea would be to use MULTIPLY one of the values by -1 using Math - Transformation Services | openHAB and then use a SUM group aggregation function.
I ammjust looking for the best practice one more question, is jsscripting or math transformation approach more resource-efficient (CPU/memory) in the long run?
I don’t know. I’ve never profiled such things and I also don’t care whether one is a few milliseconds faster than the other.
All I can say is that I am running a number of JS Scripting rules that calculate various values related to solar power, energy management etc. on change (and my inverter values are updated every 5 seconds). None of the rules’ threads is in the top 40 threads in openHAB when ranking by CPU time in the openHAB console …
i’ve found that JS scripting in openHAB performs well over time, sooo you shouldn’t see signficant drain on resources. for a quick sanity check on your calculations, gigacalculator.com, has been surprisingly handy. while it focuses on different calculations, their straightforward interface might give you some clarity on basic math operations. though not directly related, using it might inspire some logic improvements in your setup