How to make real thermostat manual changes affect thermostat controller

Am I right that if I use the Thermostat Controller, then I can't change the thermostat set point using the buttons on the actual thermostat itself, because the Thermostat Controller doesn't act on set point updates from the actual thermostat and will quickly over-ride and undo any manual changes I make using the actual thermostat buttons? (In other words, if I want to be able to change the set point using the buttons on the actual thermostat, I have to disable the Thermostat Controller.)

If this is so, then can I write some Rule to watch the thermostat set point changes and send those changes to the Thermostat Controller to keep it in sync?

I'm expecting the answer, for the general user-base, will be dependant on the driver used for the Thermostat device. At least I hope so. The driver I have written for Mitsubishi units provides periodic updates to the HE device based on the (currently) cloud status of the Thermostat. That would pick up, eventually, manual changes like you describe, eventually.

The question, I expect, will be whether the controller app can respond to changes to the Thermostat device state changes outside of the controller App, regardless of the circumstances.

Hope this helps in some way....

This is correct, unless Thermostat Controller is put into Free mode, not controlling the thermostat. Thermostat Controller basically renders the real thermostat into a totally controlled device.

In theory you could write a rule that triggered on changes from the controlled thermostat in order to set the controller thermostat. But this would introduce circular logic and cause huge problems. There is no way for such a rule to distinguish between the manual changes to the setpoints you would make at the thermostat itself, and the changes to the setpoints caused by Thermostat Controller. This is not at all something you should attempt.

I've been programming computers since 1974. (That was FORTRAN-IV on punch cards!)
Depending on how powerful your Rule system is (can it calculate the time between two events and act or not act on that time difference?), I can program to distinguish an event coming from the thermostat that was done manually from one sent by the controller and then immediately echoed back.

Or, perhaps simpler, make the Rule smart enough not to forward to the controller an event coming from the thermostat that doesn't change the set point temperature already set in the controller, to avoid the loop caused by the echo. The Rule would have to be able to save state between calls, or be able to query the controller to find the current temperature. It would also need to know about time, so that it didn't act on every button press immediately but waited until things were stable.

I don't know how powerful your Rule system is yet.

Or, maybe I can use the device event log from MakerAPI and issue commands from my Linux system to HE that way. But the Thermostat Controller events are missing. The MakerAPI app logs events from my thermostat, energy meter, and temperature sensor, but even though I've selected the controller I get nothing in the MakerAPI log. I suppose I can work around that by explicitly querying the controller via MakerAPI, since that seems to work. I'll have to read up on what's possible. (Why don't I see Thermostat Controller events logged with MakerAPI?)

Or, maybe I should look into getting my Nortek USB Controller working under Linux. If I can see events through that, I know I can write a program to do what I want. (But maybe Z-Wave devices can only be seen/managed from one place, so that if the device is "attached" to the HE, it won't be visible to the Nortek?)

This is all new to me. What fun!


All of this is achievable, but would be rather a mess using RM.

Can you code in Groovy? Doing something like this in a custom app would be easier.

I don't know Groovy yet. I'll look into it. How hard can it be? :slight_smile:

Why don't I see Thermostat Controller events logged with MakerAPI? (Or, where should I post this question?)

1 Like

Not being able to control temp settings from the actual thermostat is why I haven't been able to use thermostat controller...wife will not give up option to walk up to the regular thermostat on the wall and make changes. If you come up w/an app to manage this issue I (and likely others) would be intersted/thankful. :slight_smile:

1 Like

Maker API deals with device events. It would see both the Controller thermostat and Controlled thermostat events, assuming both are selected.

In my opinion a much better/cleaner solution would be to get a 2nd physical thermostat and not actually connect it to your HVAC. Then simply use that as your manual input device which could then relay to your thermostat controller.

1 Like

Both are selected and I see no Thermostat Controller events. Under "Event Subscriptions" there is no mention of the controller.

There won't be any "Thermostat Controller" events. There are events for the controller thermostat, which is in your devices. Look for a device named "thermController-xxx', where xxx is the name of the controlled thermostat

Under the MakerAPI "Event Subscriptions" there is no mention of the controller, and there are no events logged with the letters "controller" anywhere in them (which is to be expected if MakerAPI can't create subscriptions to those controller events). I've removed the controller from MakerAPI and added it back. No change; no events.

First, you have to select the controller device, and the thermostat device:

Notice that the second in that list is the Controller thermostat. There also has to be the URL to send the events to.

Then, after hitting Done in Maker API, there will be lots of Event Subscriptions.

Then, when I control the Controller thermostat, it throws events:

1 Like

I updated my HE to, updated Thermostat Controller, re-added it to MakerAPI, and still it wasn't listed in the Event Subscriptions. I wandered around looking at things, came back to MakerAPI and used the Done button again and now thermController is listed under Event Subscriptions and when I generate events they are logged by MakerAPI. So that's fixed, though why I had to say "Done" twice I'm not sure.

My Dashboard tile connected to the old Thermostat Controller was, of course, broken by the removal of the old Thermostat Controller. I opened up the Edit menu for the broken tile and the thermController is not listed as one of the Devices. When I try to use the Dashboard "+" to add a new tile, my new thermController is also not listed as one of the Devices. I only have five devices in total (including thermController), and the Dashboard only shows four of them. Why can't I create a Dashboard tile for the new version of the Thermostat Controller?

You have to open the Dashboard app, and select the device there. Dashboards only have access to devices selected in the app.

Screen Shot 2022-09-22 at 8.44.01 PM

D'oh! I dimly remember seeing that. Perhaps the Dashboard could say "Pick a device (4 of 5 devices available)" and I would remember that I have to go back to the App and add the fifth device?

1 Like

The best place to do this is inside Thermostat Controller. Where can I download the code?

You don't download any of the built in write it yourself. Either being a device driver or an app. Plenty of documentation and examples are found on how to do this...assuming you know your way around programming you should get a simple app/device driver up and running in a few hours.


Why would I waste my time re-inventing and duplicating the existing program from scratch, rather than enhancing something that mostly works and making it better?

The app you need to do this is fairly simple. Check out the example apps in the public repo to get the basic structure of an app.

Hubitat is not an open source platform, and the source for Thermostat Controller is not available. Doing this in the context of that app would be much more complex than meets the eye, as it has no existing mechanism that resembles what you want to do. So doing it there, as opposed to creating a small app to do it, would be a significant undertaking.