You'll have to register for the old one.
https://mytotalconnectcomfort.com/WebApi/Help/LogIn?ReturnUrl=%2FWebApi%2FHelp
MyTotalConnectComfort API rate limits at 15 minutes I think. Through SmartThings it's much faster. I haven't found it block any so far and that's multiple changes per minute.
I saw that. It looks for an Application ID but doesn't indicate how to get one. It seems they are going out of their way to include additional confusion into their web interface.
1 Like
Seems that way let me see if my corporate account will let me in.
1 Like
I’m running homeassistant and its integration with TCC (UK) and then MQTT to push to hubitat. It’s working reliably and homeassistant is useful for those oddball integrations that hubitat might not be able to cater for. I’ve used it for this but also some very cheap wifi energy monitoring plugs and a neato vacuum cleaner.
Yea, the problem with that method is still the rate limiting.
1 Like
Even the new api has rate limiting to us mortals 5 mins with up to 20 devices which is better but doesn't support some older devices and still not as fast as the preferred partner integrations. But I get it that they pay for those faster rates.
1 Like
Has anyone else noticed with this driver that when system enters Fan Only mode, the thermostat device in HE reports that its in a cooling or heating operational mode? Normally that wouldn't bother me but in trying to use it with Keenect Lite it doesn't control my vents properly in Fan only mode because the app is being told the system in an operating mode that its not.
I looked at the driver code for the getStatus call and enabled debugging which it dumps a parsed version of the json response. I noticed that EquipmentOutputStatus is pulled from the response but isn't factored into the actual operating status but instead the operating status is based on the fanIsRunning and a mode value that I don't even see set . I am going to try to make some mods on my side and if I get it working I will do a PR on the driver for others to use.
2 Likes
@womackj Have you tried installing the latest version (1.3.7). I came across a few bugs recently while trying to set it up and submitted some pull request which the author helped integrate (and he found a few more bugs in that process), so the latest version takes care of a number of issues. Also added is a new enhancement whereby the outdoor thermostat also appears as a child-device so it can be used as a Thermostat in Rule Machine. Outdoor humidity will also be added as a child device so it can also be used in Rule machine, but I am holding off until after the HE firmware 2.2.4 release (my own HE is on 2.2.2 since I had many problems with 2.2.3, and I think the upgraded HE firmware is necessary to get the Humidity child component device to work). Also added is that the code now checks the permitted heating / cooling ranges as reported by TCC and doesn't allow you to set outside the ranges (TCC itself enforced that, but now the driver also does so HE will "obey" the TCC ranges -- now, if you set outside the range the HE driver will now set at the maximum or minimum, as the case may be, and no longer violates the TCC ranges).
@csteele Latest 1.37 version gives this error constantly.
[warn] description logging is: false
Not sure why it needs to fill the logs with errors for NOT logging?
That message exists once in the code... within the Update() method... which means it should only occur with each click of the Save Preferences button on the Device Info page.
That doesn't jibe with "gives this error constantly".
I'm good with 'demoting the message" to "info" vs "warn" and even to make it optional via "Enable descriptionText logging" BUT the concern for me is the word "Constantly"... as that would be a much greater problem.
At the time I posted, I was running 1.3.5 as that what was available with Package Manager and I saw that there was a pending PR in the repo. I will do an upgrade to 1.3.8 now (recently published and look through the code regarding the operating status).
It did this for a few minutes and then it stopped. Currently, it is OK. I will update you if it happens again.
Howdy - switching over from IFTTT to the driver. Really nice job by the developers on this! One thing I noticed was my 'thermostatOperatingState' staying at 'idle' despite the heat running. Taking a 2 minute look at the code, it looks like 'fanOperatingState' may be a dependency, and for some reason my thermostat isnt reporting back a fan state. Anything I should try?
ld = [ScheduleCapable:true, OutdoorTemperatureSensorNotFault:true, SystemSwitchPosition:1, SetpointChangeAllowed:true, OutdoorHumiditySensorNotFault:true, DispTemperatureStatus:0, HoldUntilCapable:true, HeatNextPeriod:67, HeatLowerSetptLimit:40, SwitchCoolAllowed:true, IsInVacationHoldMode:false, IndoorHumidStatus:128, OutdoorTemperature:128, ScheduleHeatSp:50, TemporaryHoldUntilTime:1005, OutdoorTempStatus:128, IndoorHumiditySensorAvailable:false, CoolUpperSetptLimit:99, OutdoorTemperatureAvailable:false, SwitchEmergencyHeatAllowed:false, Deadband:0, EquipmentOutputStatus:null, SwitchOffAllowed:true, VacationHoldCancelable:false, SwitchAutoAllowed:false, DeviceID:1548221, VacationHold:0, StatusCool:0, IndoorHumidity:128, DisplayUnits:F, HeatSetpoint:70, Commercial:false, CoolSetpoint:50, HeatUpperSetptLimit:90, CurrentSetpointStatus:1, DualSetpointStatus:true, ScheduleCoolSp:50, VacationHoldUntilTime:0, StatusHeat:1, DispTemperatureAvailable:true, OutdoorHumidityAvailable:false, DispTemperature:68, OutdoorHumidity:128, SwitchHeatAllowed:true, IndoorHumiditySensorNotFault:true, CoolNextPeriod:66, CoolLowerSetptLimit:50, OutdoorHumidStatus:128]
It's fully possible that Honeywell has tweeked their end of this undocumented API.
You could change lines 461 ++ to be:
if (fanIsRunning == true) { fanState = "on"; } if (equipmentStatus == "1") { operatingState = "heating" } else if (equipmentStatus == "2") { operatingState = "cooling" }
(basically: move line 468 to be line 463)
Let us know if that works better for you.
Thanks, tried this but not having any luck. I'm seeing "EquipmentOutputStatus:null" in the response, which I'm guessing is part of (or all of) my problem. It could be my testing though; of course I'm trying to figure this out on the warmest day we've had in a while and trying to currently avoid heating the house up any further.
Finally cold again and ran the heat a bit.
EquipmentOutputStatus:null seems to always be returned from the API, even with the heat on.
A null would certainly cause the symptoms...
Mine returns correctly:
EquipmentOutputStatus:0,
So somewhere in that pile of status values is the one that matters for you. I'd be happy to look through what gets returned to you, if you wish. Turn on debug logging and click Poll. In the logs will be a message that begins:
dev:330 2020-10-25 09:34:08.757 am debug ld = [ScheduleCapable:true, OutdoorTemperatureSensorNotFault:true,
Grab that whole message and PM it to me. (sanitize it: remove the DeviceID result.)
Mine returns 48 status values.
2 Likes
Thanks, will PM you.
