I believe you. Had one instance of this running all year and had no issues, I installed another two instances recently and it seemed like it was bogging down the network although that seems to have cleared up.
Anyway, my instance is not mission critical, it is simply controlling a fan. Is there any way to have it only check every 5 minutes or so?
Also, similar apps to this on other platforms that I've used in the past, there was a way to set a specific device or 2 to override the thermostat. Example is the set a mode or contact open that would prevent the therm from operating. Have you ever thought of adding that?
@nclark Thank you for this app/driver! I have been using it for a few months and finally decommissioned my long-used homerolled set of rules and switches and your app/driver gives me so much more peace of mind.
can I request a preference to set the hysteresis?
I've added humidity into the app and device for sensors that have humidity. This allows me to have this virtual thermostat display humidity via Homebridge, just like the Nest does. Would you consider incorporating it? If so, push request or just a link to github repo?
I made a change to the temperature function to round it to one decimal place. I discovered the current code was an issue when using an Aqara device which sends nearly 10 decimal places. Seriously, they think they are that accurate?!?
Hysteresis setting is coming, having a setting for how many decimal numbers could be nice also, I'll place it on the todo list.
Give the the github repo so that I can see exactly what it is you are doing with humidity, if I understand it's just so that you can have temp and humidity on the same tile and no processing what so ever of the humidity value, right?
I guess if you’re feeling ambitious, you could use that humidity value to turn on a “dehumidify” mode. My smart AC has it, though I’ve never had a need to use it in northeast US. I’ve heard it’s useful in the south and southwest.
@nclark, when you look at my code, there is one thing (probably more!) that could definitely use improvement: subscribe to humidity only for devices that support it. I don't have any temperature devices without humidity to test what happens in those cases.
This is exactly why I wrote my own virtual thermostat driver and app. It controls the heating zone valves on the furnace directly using Zigbee relays. I wanted the most consistent temperature possible, as I found the Honeywell T6 thermostats to be very poor at maintaining a consistent temperature, no matter how many cycles per hour I change in the settings.
My driver anticipates turning on the furnace before heat is needed, and turns off before the residual heat left in the registers sends the temperature over setpoint. It does this with multiple offsets and timed cycles. Below the low offset, the heat ramps until it gets to that offset, then checks if heat is rising. If it is rising, it stops heating to not go over target. If temp starts falling while above the low offset but below target, it will run a timed cycle and turn off when the temp starts rising, or finish the cycle and then wait a few minutes to check if temps start rising. If temp is not rising after the wait period, another cycle is applied, and so on.
There is an offset just above setpoint where if the the temp is falling, it will cause a cycle to run before going below setpoint while waiting for the heat to come up. If the temps start rising during that cycle, the heat turns off. If not, it will wait for a rise, and then run another cycle if there is no rise. It will run cycles and waits until the temp stop falling just above setpoint. I generally stay within a .25 degree range from setpoint when the offsets are dialed in (so a range of about .5 degrees between high and low temps).
This has worked very well for me, and it also runs my AC units in the summer in the same way. Much different offsets are needed for AC vs Heat, but the AC/Heat offsets switch over when the mode changes. It also automatically changes modes (no "auto mode" but it automatically switches heat or cool mode).
You would think I would be running my furnace too much with this method, but it really doesn't. It tends to be about three main heating "cycles" or less per hour. Cycle lengths are dynamically changed based on outside temperature, for both heat and cool cycles. It may run two or three short cycles in a row within ten minutes to get the rise, then then not run again for 20 minutes. The furnace and the water are still hot after a wait of a few minutes, so I consider these small cycles to really be one main heating cycle, to change the temp from falling to rising.
Running three zones, the furnace never really totally cools down, as something is usually cycling to keep the furnace warm. If anything, this may be more efficient than long runs where the furnace can get cold between runs. My furnace is regulating, so if the water is already hot it regulates down to just maintain the needed water temperature.
Ah I see @nclark I was using Advanced vThermostat V2 which you deleted from your repo March 20th, 2025, 6 days after I asked this question about my fireplace sometimes being on (despite the app thinking it's off) and sometimes being off (despite the app thinking its on).
Coincidence?
Did you abandon "Advanced vThermostat V2" ? Should I try to switch my device over to the regular code?
Yes and no, I had been wanting to remove that code for some time, the V2.0 was to be able to use this driver with Homekit since the Homekit official guidelines don't allow custom drivers to be used, so the V2 version was using the built in virtual driver and controlling via the parent app. This did work but was a pain and many things did not work exactly as I wanted, so I abandoned the idea.
I will have some off time during the holidays and I'll be working on getting the a new update for the original code but using some of the better logic used in the V2 version.
While I don´t condone "working" during a holiday, I will look forward to a new version of your app. Been using the current one since November 2020
If there is one thing that I would like to be able to change, it is the panic mode. i.e. not have the thermostat stop if it does not get a temp reading, or the plugs be left in "on" state.
I unfortunately had an issue with this feature a few years back (of my own doing), but I have been secretly wondering if this change/option would have saved my bacon (and some strong words from my wife)
Good to hear from you. Is the regular code "compatible" with the old deleted V2 code? Specifically, could I copy-paste the regular code from your repo into Hubitat so my existing (v2) devices pick it up?
FYI as a temporary measure, in my repo I added a check during the safety check (every 15 minutes) to check the status of the switches, to make sure they are the same as the thermostat thinks they are. Commit d7efeaaac5cc1266b4586d093af800f2729cee94 in my fork GitHub - jeabraham/Hubitat_Advanced_VThermostat: Hubitat Advanced V Thermostat . I have a physical switch that people can use to trigger the relay to turn off and turn on the fireplace; it can be a problem if the relay becomes out-of-sync with the vThermostat's expectation. I haven't adequately tested it, I'm not exactly sure where I'm going with this, but I thought I'd let you know. (Looking through the diff, I definitely regret removing the "♪♫ Burning down the house, my house" comment. )
