I have done energy management with Andover Controls since the 80’s. We have always used at least 2 decimal place to show rapid changes in temperature or humidity. I am also using a main openHAB server to graph the HesitaPI devices as a remote server which is working very well. It also a lows remove control of each unit. In my case I will have 4 units, 1 for the main temp in the house, 1 to run the backup heat system, 1 for the shop/barn and one for our storage building. I have a public weather station that I run and publish to the NOAA and can use that data to affect the info that can be sent to the HestiaPI devices.
I moved this to a new thread to keep the upgrade to Buster thread clean for now. When it gets committed @hestia_hacker script will pull it on the next run.
I understand now… this should not involve the UI then rather than the backend part for processing purposes. Then I see no problem if it does not affect the LCD, the web or the app UI but the values are only communicated with decimals via MQTT or so (and rounded when displayed within HestiaPi context).
Does your previous suggestion:
comply with the above?
For what it’s worth, I have wanted to get more precision on temperature on the LCD screen and went as far to attempt to implement it myself.
Other thermostats vary in whether they round to a full degree C, half a degree, or a tenth of a degree. In my opinion, a tenth of a degree is correct, a half degree is tolerable (but weird), and a full degree is a design decision that I do not agree with.
I’ve seen some the round to fifths of a degree, which is extra weird. Still, I find them more enjoyable to use than the more coarse grained information.
I only use °C, so I don’t really care what changes are made to the °F display, if any.
As for humidity, my HVAC system doesn’t control the humidity and so I don’t care about the display of that. In fact, use sensor that is a quarter the price and doesn’t have humidity sensing. Humidity shows up as zero instead of being hidden, but the code for the LCD UI looks like it was auto-generated and so I gave up with that enhancement because I don’t have the original source that I can modify and regenerate it.
As for jrtaylor71’s implementation, I believe that the explicit rounding operation in the script will avoid rounding issues that I ran into on the set point side. I have not tested that (yet).
there are 2 temperatures shown as you probably know:
- Current temperature - this is the only place a finer value would make sense IMHO
- Target temperature - this needs to follow the steps the + and - buttons apply. Currently in F this is 1’F step and in C it is 0.5’C
What is your suggestion for each?
For the values displayed in the UI…
Current temperature (Celcius): One decimal place showing, showing in tenths of a degree.
Current temperature (Fahrenheit): No opinion
Target temperature (Celcius): Leave as is. One decimal place, step in 0.5° C
Target temperature (Fahrenheit): Leave as is. Zero decimal places, step in 1° F
…as for data available to other systems (e.g. other OpenHAB servers): as much resolution as the sensor can provide (and let the other system decide how it is displayed in their environment).
Target temp should be at least 1 decimal too and it depends on the HVAC system being controlled.
1. A conventional forced air heating system would not it.
2. A system system that was hot water in floor heat yes would benefit.
3. A hybrid system that is forced air hot water would also benefit. These are becoming more popular as energy costs have gone up.
We should also talk about fan control some more. New thread???
That’s how it is now…
In a scenario where people don’t tend to change the target temp and they simply turn on and off the heating, that is fine.
In a scenario where people change the target temp, a 1 degree change would mean 10 presses on the LCD. For houses where they lower the temp when they are out a few degrees change would be very annoying and they will run to the app instead of the LCD.
Do you have in mind the target temp to be set from an external system instead of a person?
New thread would be best. I don’t have an opinion on this tbh.
Only for Celcius but not Fahrenheit.
Not really, if you only set the to .5 or .25 then its only 4 times at most for F and it’s 2 times right now for C.
Having a heating and cooling schedule would help a lot. This way you could have fallback temps.
But no it’s… checks thermostat… 
Well I sure do feel silly. Yeah, that’s exactly how it is now. 
Well, my opinions are the same, and already being met. I guess I was thinking of the wanting to set the temperature to arbitrary values using the web API and getting weird floating point issues on the display. My bad.
+1 on this one. It was a lack of a ready solution from the OH side and I believe OH3 does support that so once the upgrade to OH3 is completed it will be one the first new features
Here are patch files to add one decimal point to temperature and humidity. It also changes the temperature differential step from 1 to .25.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.