For those that want to just start using the plugin, you can download it from the File Library. Some things that you should be aware of (all are limitations in the thermostat and it's WiFi adaptor so we can't change the behavior until the underlying problems are fixed):
- This thermostat works differently from the Venstar (if you're used to that one): the thermostat is always in program mode - so it will adjust according to the program that's active. We've provided a custom action that will allow you to specify the programs.
- AUTO mode is very unreliable. Temporarily changing setpoints by hitting the up/down button on the thermostat itself or in the controls in Indigo Touch and IWS will change the mode from AUTO to whatever the thermostat last was doing (cool or heat). We highly recommend just avoiding AUTO and setting the thermostat to HEAT and COOL as appropriate for the conditions.
- When you adjust the setpoints via the up/down buttons on the thermostat itself, we may not be able to see those changes.
- When you adjust the setpoints via the up/down buttons on the thermostat, in the UI, or by using the standard thermostat actions, that will change the temporary setpoints - in other words, the setpoints will only be active until the next program change boundary is crossed.
- The above rule is not true if you set the thermostat to HOLD - which you can do via custom actions. Bottom line - if you want to change the setpoints then make them stick forever, change them then turn on HOLD and they should stay that way until you turn off HOLD.
- Changes to the thermostat and status updates are relatively slow (about every 30 seconds). The WiFi adaptor in the thermostat is underpowered and it will lock up quite quickly if you try to ask it to do too much. So, if you do multiple changes to the thermostat in a short time, those commands will be spaced appropriately so that we won't lock up the adaptor. You'll periodically see timeout errors in the Event Log with multiple retries spaced further apart when it gets confused.
- RTCoA is releasing firmware updates - at some point in the future they may expose a way via the API to update firmware and we'll consider adding it to the plugin. For the time being, you will get new firmware pushed to your thermostat if you have it's cloud capabilities activated so we recommend that you do that even if you don't intend to use their web UI. Contact RTCoA for details.
Because of the problems we've experienced with this thermostat, we can't in good conscience recommend it over the Venstar. We really wanted to but it is just not completely reliable yet. And because of this we won't be offering the same level of support as we do for the built-in devices or the included plugins - thus the proof-of-concept moniker (vs Alpha or Beta). We'll try to help when there's an issue but because of the unreliable nature of the thermostat it will be really hard to put much more effort into it at the moment given all of our other priorities.
Perhaps some day it will be more reliable - if/when that happens we will consider including it with the standard Indigo install and offer the same level of support as we do with all the included plugins. We'll also look at supporting the other RTCoA thermostats at that time.
--------------------------
-- The long story --
--------------------------
After hearing about the 3M Filtrete WiFi thermostat (model 3M50) available for $100 at Home Depot - we got understandably excited. The prospect of a cheap thermostat that didn't require a separate interface to control would mean that Indigo is even more valuable to those who don't have existing HA technologies. So, we immediately began doing some research and found the API documents on their website. They looked quite complete and well documented. SCORE!
The company that actually makes the thermostats is Radio Thermostat Corporation of America (RTCoA) and they have some other models as well. Feeling pretty confident that we could kick out a plugin for this thermostat pretty quickly, and having just finished up the thermostat implementation in the API, we thought this would be the perfect plugin to work on immediately. I ran over to Home Depot and purchased one. I got it home and began experimenting with it using curl.
And that's where the problems began.
The first approach that we were going to take was to have the thermostat behave like the Venstar. It's what we're familiar with and seemed the right approach. Specifically: keep the thermostat in non-program mode (they call it absolute mode), where Indigo controls it directly. We could also add in program mode since the API supports editing programs, but since we don't do that on the Venstar we would probably leave that for later.
The first major problem we found was that the thermostat didn't actually support AUTO when in non-program mode. That is, you could have the mode of the thermostat set to HEAT or COOL - but when you set it to AUTO (where both heat and cool setpoints were active) it simply didn't work. Exacerbating the issue is that you can't actually get the setpoints from the thermostat unless the hvac system is actually running - so you can't get the heat setpoint unless the heater is running. Same for cool.
At this point, I was already a couple of weeks into it, so we discussed it and decided that the right approach with this thermostat would be to just mimic the physical UI behavior - so stay in program mode all the time. Any setpoint adjustments with the up/down arrows (in the Mac client, IWS, and Indigo Touch) would cause a temporary change - until the next program boundary was crossed the temporary setpoint would be in effect. After the program boundary was crossed it would be back on the program. We would add the ability to set the programs through a custom action that would make the setpoint changes permanent. And AUTO would work as expected. So, with the new direction, I began coding in earnest.
Unfortunately, there were more issues that I'd yet to run across. AUTO doesn't seem to work particularly reliably when in program mode either. It seems to want to cross a program boundary before it will change from heat to cool and vice versa (though going from cool to heat works less frequently). Also, the up/down button on the thermostat itself as well as setting the temporary setpoint via the API (which mimics the button presses) will switch the thermostat from AUTO into whichever mode was the last mode used. So, for instance, if your HVAC system was cooling (but then turned off) and you hit the UP button, it changes the thermostat to COOL and sets the temporary setpoint. So now you're in COOL instead of AUTO. I believe the fundamental problem here is with the thermostat itself (rather than the WiFi adaptor) - it doesn't appear to actually have 2 active setpoints - only 1. And for AUTO, they hacked in some way to switch between off/heat/cool. Not sure that will ever be able to be fixed via firmware patch.
Another problem is one I mentioned earlier - if the setpoint changes at the thermostat, you can only get the changed setpoint if the compressor or heater is actually running. Any other time you can't get the setpoint. I did in fact get an email from their support guy saying that a new version of the firmware would solve that issue. He sent it to me and I installed it but it doesn't appear to be fixed. It is nice to be able to upgrade the firmware for the WiFi adaptor. So, as a workaround we attempt to get the setpoints when they are initially empty (when you first add a thermostat) by reading the programs for the current day and getting what it should be (though if it's in override you can't tell).
However, this brings us to the last big problem: you can't actually communicate with the thermostat too often or you'll hang it up. Apparently the WiFi adaptor is pretty underpowered and just can't handle too many requests. They recommend at least 15 seconds between each communication - I found that 30 causes fewer issues.
There are other issues which are less major (the reboot command hangs the thermostat rather than rebooting), but the main point is that without actually having one to test with we would have never figured out what works and what doesn't. That's the reason why we're only supporting the 3M50 (aka CT-50) model thermostat - it's the only one we had to test with and by their own admission the firmware for the other thermostats is different.