EDIT: I had it backwards. Multiplying by 1000 give parts per trillion, not parts per million.
Well, if all you care about is how it appears on the sitemap you can use a transformation. The Item will remain the value given to it by the binding but you’ll see it modified in the UI.
But if you want to use this value elsewhere then you need to change the value before it gets to the Item. And there we have choices for approaches based on other details like which binding it comes from and the Item’s type.
If you only use this value in a Rule for other calculations then you don’t need to change anything at all but just multiply it in the rule. However, the units of the value come into play here too.
OK so it’s a Number:Dimensionless using “parts per billion” (ppb) as the units. Are you sure the value is wrong? Maybe what you really want is “parts per million trillion” (ppt). That’s the whole point of units of measurement. You don’t need to do anything really to convert between compatible units. You just need to specify which units you want to use.
So assuming you want ppt you can just specify that in the State Description metadata pattern. The field you want to set is Pattern and the docs for what goes there is Items | openHAB.
In this case all you really need to do is tell it to use ppt as the units.
%d ppt
That will change its display to ppt instead of ppt everywhere in MainUI.
However, the charting will still use ppb. There is no way around that for now.
Because it’s not a simple operation. In your mind you are just wanting to multiply a number by 1000. But as you can see it’s way more complicated than that. For one it’s not just a simple number.
Don’t be fooled by all the wonderful work the developers have done to make openHAB as easy to use as it is. Home automation is hard. It’s unbelievably complicated. Almost nothing you do in home automation is going to be as easy as you think it should be. Unfortunately that’s just the state of the world right now in home automation.
That’s not to say that it’s unachievable, even by people who don’t consider themselves to be technically skilled. But you will have many hurdles like this to overcome going forward. When you encounter something that seems like it should be simple but it’s not, that probably means its not so simple as it seems. So before you spin your wheels for hours, ask for help. Be sure to provide as many details as possible and always state your end goal (not how you hope to achieve it, this is called the XY Problem). There are many ways to do things in OH and the best one depends on what your ultimate goal is. Sometimes it may be a radically different approach.
And just for illustration, here’s another way that may work to force the Item to use ppt. But it’s going to involve the JavaScript Transformation and a Profile.
First we need to write the code that will transform the value to ppt. Put the following into a toppt.js file in the $OH_CONF/transform folder (e.g. /etc/openhab/transformation).
(function(i) {
var num = Number.parseFloat(i);
num *= 1000;
return num+" ppt";
})(input)
NOTE: I just typed that in, there may be errors.
All transforms work on the string representation of an Item’s state. So we need to parse that string into a number we can do math with. Thankfully JavaScript’s Number.parseFloat() function will stop as soon as it hits a character that doesn’t belong in a number instead of throwing an error. This is important because this is a Units of Measurement Number so the state is actually “0.5 ppb”. That " ppt" is part of the state.
Then we multiply it by 1000 and return the new value with the new units appended: “500 ppt”.
That should force OH to use “ppt” as the default units for that Item from now on which will cause it to chart the ppt instead of ppb too.
Yet another way involves using proxy Items and a Rule. See Design Pattern: Proxy Item. Trigger a rule for when VOC-Sensor changes. The Script Action in Rules DSL would be something like
VOC-Sensor-Proxy.postUpdate((VOC-Sensor.state as QuantityType).toUnit("ppt"))
That will update the proxy Item with the value converted to ppm similarly to how the transformation worked. Only in a rule we have more options to manipulate the units.
To summarize:
- This is really an XP Problem. You don’t want to multiple by 1000, you want to use the right units by default.
- Modifying the value returned by a binding really isn’t something that is nor can it be simple.
- I presented three different ways to deal with this problem. The State Description Pattern is the simplest, most straight forward, and is going to address your immediate needs.
- The second approach would be best used in cases where the sensor needs to be adjusted and it’s not using Units of Measurement or the adjustment is more involved than a simple change in units.
- The third approach would be best used in cases where the Items involved are not using units of measurement or the calculation for the new state depends on the states of other Items. It’s also the best approach if the sensor’s readings are not reliable as it gives you the chance to ignore the unreasonable values.
So hopefully you can see now how your end goals can radically change what our answers might be.