Open rkoshak opened 4 years ago
Regardless of how much I like this approach and because most of the work towards milestone 1.2 has been on your shoulders, I would suggest to push this for 1.3 unless it will make your life easier in the intermediate tasks.
That's what I'm inclined to do to. It does add a bit of extra work because, for example, adding the new min and max setpoint Items now means I have to add six new Items instead of just the two. But over all, it's a pretty big overhaul so I would rather add new features for now and put it off until later. But I did want to capture this as an issue so it doesn't get lost.
OH supports units of measurement. We can tag a Number Item with the type of measurement that Number represents (e.g.
Number:temperature
). When working with a UoM, you can do math with any other unit for the same measurement. For example, you can put25 °C
in TempSetpoint and in a rule doif(TempSetpoint.state > 70 | °F)
and OH will convert from °F to °C for you. The units shown in the Sitemap, when using the default units, will use the units based on a setting made in PaperUI.If we use UoM, we can standardize on °C for all the rules and Python scripts and everything and only convert to °F for display and publishing when we need to. This will eliminate most of the temperature proxies and the multiple copies of the python script and the rather disruptive switchover required when changing the temperature units.
Because this is going to be another rather disruptive change I don't know if I should tackle it now or if I should start adding in features that users can actually use first.