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.
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?)
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.
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.
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.
I updated my HE to 2.3.3.121, 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?
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?
You don't download any of the built in code...you 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.
