Has anyone managed to make a driver that integrates well for this already?
It looks like it'd be pretty straightforward from the API docs below, but hoping there's some prior art out there already.
Thanks
API/Examples: GitHub - brannondorsey/radio-thermostat: Radio Thermostat CT50 & CT80 REST API notes
I too have a CT 50 with WIFI.
I had it working with Smartthings, and I want to convert it to work here. Did you have any luck?
If anyone's still looking for this, I ported the SmartThings driver created by statusbits.
I haven't got my CT50 WiFi thermostat connected back to my heater yet (replaced heater, & installer put the default thermostat in), but I turned it on to test the driver and all the commands appear to work correctly - the changes appeared on the thermostat's screen.
Thanks very much for your work! I've added my two 3M-50 thermostats and set the polling interval to 1 min. Works great. A bit of confusion was that these needed to be added as virtual devices, not to be discovered.
Note that my 3M-50s have both, the Z-Wave and the WiFi USNAPs, so I have two sets of devices in the HE (Z-Wave 3M-50 and IP 3M-50). Both have some limitations though. As expected, the ported WiFi cannot control the Auxiliary/Emergency heat, as it is just not part of WiFi API, though there is a function button on the HE Device page. Yet, the WiFi mode has an ability to place thermostat in the HOLD mode. While the Z-Wave can switch Emergency heat of and off, but does not have a HOLD function/button. Bottom line I need both if I want to control Auxiliary/Emergency heat and place my heatpump in the HOLD mode while it is freezing. Another point is that 3M-50 Z-Wave Device reports only when temperature swings 0.5C, which may take several hours. Is there a way to make updates more regular or poll it once a minute?
Thanks again.
Great! Yes the driver needs to be added as a Virtual device, then the IP added into the device settings.
I'm not sure I follow - you already said above that you set it to 1 min?
If you meant for the Z Wave driver, you would have to ask the developer of that driver (or Hubitat support if it's a built in driver). I don't know anything about talking to Z Wave devices.
Apparently the CT50 doesn't update for daylight savings... I've just added a new command "Set Time To Current" so you can update the day & time just by pressing the command on the thermostat's Hubitat device page 
Getting an error in the log, and no ability to command a 3M-50 thermostat with the custom driver. The "Generic Z-Wave Thermostat" driver works, with its more limited functionality.
Here is the error:
020-11-01 04:57:41.418 am errorgroovy.lang.MissingMethodException: No signature of method: user_driver_statusbits_Radio_Thermostat_675.pollDevice() is applicable for argument types: () values: [] Possible solutions: collect() (pollDevice)
@cometfish I wanted to "update for daylight savings" as it is that time of year, found your comment above, changed to the custom driver, but I'm not sure what broke. Running the latest and greatest code on hub, and in drivers/apps.
When you changed driver, it kept the old driver's 'pollDevice()' call that is scheduled to run frequently. This driver doesn't have that, so Hubitat is confused. If you click Save Preferences on the device details page, it should unschedule that old call.
This driver is a WiFi driver, not a Z-Wave driver. Do you have the WiFi module installed in your 3M-50 thermostat too?
If so, have you confirmed you have an active WiFi connection on the thermostat, and also configured the IP address, etc, in the custom driver's preferences?
I'm sorry, I was not aware that the driver was for the WiFi link. Yes, I have the WiFi module, but i lack a "C Wire" (24-Vdc power) to the thermostat, so it refuses to allow configuration, as it seems to be a power hog.
@cometfish
Your driver has been working great, however, recently i noticed it is pretty chatty in the logs... Is there a way to turn them off?
dev:34932020-12-07 21:16:05.302 tracetstat data: [temp:72.00, tmode:2, fmode:0, override:0, hold:0, t_cool:72.00, tstate:0, fstate:0, time:[day:0, hour:21, minute:15], t_type_post:0]
dev:34942020-12-07 21:16:04.397 tracetstat data: [temp:68.50, tmode:2, fmode:0, override:1, hold:0, t_cool:69.00, tstate:0, fstate:0, time:[day:0, hour:21, minute:14], t_type_post:0]
dev:34932020-12-07 21:16:02.255 tracetstat data: [temp:72.00, tmode:2, fmode:0, override:0, hold:0, t_cool:72.00, tstate:0, fstate:0, time:[day:0, hour:21, minute:15], t_type_post:0]
@SuperDupe The excessive logs are from the original SmartThings driver code, I didn't change it, and no there doesn't seem to be an option to easily turn it off.
You could edit the driver code, just add // in front of any log.trace lines to disable them.
Ok, I commented out the trace entries... but I'm geting three different warnings. They don't seem to matter as the device appears to function fine... I couldn't find their origin in the code to eliminate them as easily as the trace entries...
2020-12-08 12:21:10.123 [warn]Read timed out
2020-12-08 12:19:10.079 [warn]connect timed out
2020-12-08 11:40:59.016 [warn]No connection!
I was also getting these in the logs
dev:4502020-12-08 12:35:48.024 pm tracetstat data: [temp:76.00, tmode:1, fmode:0, override:0, hold:1, t_heat:76.00, tstate:0, fstate:0, time:[day:1, hour:12, minute:35], t_type_post:0]
So after ""ometfish" recommended to comment out the log.trace lines. I commented out only one lot.trace and that got rid of the chatty log and did not get any [Warn] logged. See bellow for the log.trace I commented out.
log.trace "tstat data: ${tstat}"
@cometfish any ideas on why i'm getting these still? i have commented out the chatty log entires and not getting errors... but i'm getting these every 5 minutes which is what i have polling set to so i'm assuming it happens with each poll for some reason...
If you're getting them on every poll, sounds like the thermostat is unreachable (powered off/bad wifi conn/changed ip address).
Does accessing http://-yourthermostatIP-/tstat from your browser work?
Yes, going to the webpage works perfect... They are on DHCP with assigned addresses, but I'm going to set them to static to see if there is an issue when the lease expires or something else going on with the router maybe?
I feel like it is something that has only shown up in the last few major hub upgrades.... Before that, I never saw it...
And the driver/device in Hubitat works fine. Its controlling the thermostats, just throwing up these warnings...
Hi I found a weird thing, from the dashboard if you try to set the fan mode to "auto" it actually tries to set it to " auto" (with a space in front of the "a" in "auto", i.e. 5 characters not four, a leading space). I suppose it must be a bug with the dashboard? I don't know, I'm new to this whole thing.
Anyway, I added another case:
case " auto": return fanAuto()
case "auto": return fanAuto()
over on my fork, to get it working. But, surely the correct solution is to fix the dashboard code.
Might be best to start a new topic in the support area to get Hubitat to look at this, if it's coming directly from the dashboard.
i sent an email to support.
@comradskiy @cometfish I just moved to Hubitat from Wink. Thanks for the work everyone has done and the easy to follow documentation. I have my CT-50 up and working. I was wondering is there is a way to add a dashboard button to set the Hold on/off, as it is not included the thermostat template . I assume it has to be virtual switch of some type but for the life of me I can seem to figure out how to set it up.
Download the Hubitat app
