Has anyone else experienced polling failure?
My last poll was around @ 12:33am on Nov 10th. Initialize, refresh, etc. hasn't worked to restart it. I thought I would ask others before I go any further being Honeywell has made other recent changes.
I released an adjusted version to github and HPM yesterday. (No need to manually patch anymore.)
3 Likes
I did but with the lack of response to my question, it's obviously a "one off" on my end. It's a PIA with all the rules but I'll delete the devices and set them back up.
Thanks for replying!
This has been running great for me in that I can see and control the T-stats through Hubitat.
THANK YOU for developing this app. Truly appreciated and I'm grateful.
Now that I have been using this for awhile, I'm trying to figure out two additional functions, as noted below. My Tstats are Mitsubishi MRCH1's, connected to my ducted minis through the Redlink protocol. I pick up their data using a Honeywell Redlink Gateway, that sends info to TotalConnectComfort site, from which this Hubitat app grabs the info.
-
Does TotalConnectComfort collect only the data it shows on its user interface, or does it collect more? Specifically, does it collect fan status and/or schedule status? Neither show up on the Honeywell website so I presume that data does not make it there, so Hubitat can't get it. However, if it is really there and just not visible on their website, I'd love a way to show it in Hubitat.
The MRCH1's fan settings are Auto or Low, Medium, High. There is no off on the regular interface. In the installer setup screen, there is an option to program the system for the fan Auto setting to run continuously (which I have), or to run only when the minisplits are pushing conditioned air. However, on the Hubitat side, "FanOperatingState" = "Idle", 100% of the time. -
Could I use Hubitat for more granular control of my systems? The MRCH1's have only 2 daily setbacks. Those familiar with Minisplits know they operate most efficiently when the system calls for a constant temp. However, my household prefers the temp to drop overnight. Thus, I'd like to add about 4 commands in the morning, spaced 30 minutes apart, that slowly bring the temp up 1 degree at a time. Does anyone have experience or suggestions on the the best way to set this up so that Hubitat and the MRCH1's are not fighting each other?
1 Like
This driver communicates with the TCC API and then it falls to Honeywell to 'translate' those commands and get them delivered into the Thermostat itself.
Hubitat has two additional Apps that are built to help with environmental challenges. Thermostat Scheduler and Thermostat Controller. Together or individually they work via drivers to perform a few of the tasks that Thermostats also have. Schedule is a good example. Using Thermostat Scheduler you pretty much want your Thermostat itself to have what might be best called "emergency schedules," and leave the actual schedule to Hubitat.
Said another way.. your real Thermostat becomes abstracted to a one-size-fits-all thermostat by the driver. Then that abstraction gets further abstracted via Automations, such as Thermostat Scheduler and Thermostat Controller. I setup Rules long ago, before those Apps were available and I've even used Node-Red to alter the Thermostat. I like to think of it as taking a barely smart thermostat, making it practically dumb (keeping only the communications smarts) and then layering Smarts back on via Hubitat.
That "take a smart device, set it to be pretty dumb, then layer on smarts externally" is something I've also done with my sprinkler system.
Like a lot of people that can't count on water falling from the sky, everyone here uses a sprinkler system that often look like this:
Generally, a knob, some buttons and a LCD screen. They get mounted somewhere and then things get put in front so that touching that box is almost physically impossible. PLUS, there's no light where it is so the LCD can't be seen. I ripped that out and put in the best not-so-smart box I could find:
No knobs, no buttons, it's entirely dependent on something else being the smart layer. Fundamentally it gets a command for the day.. This valve On at this time, for this long. One for each of the 8 valves it supports. If it doesn't get the next day's set of commands, it re-runs what it has. It's got several external Smart Layer implementations that make it a delight to use and I've got a driver for it if I want to go down that path of making Hubitat be the smart layer. I've had it 10 years and haven't found a reason to invest the time.
I take the same approach to my Pool, where I've created a barely smart interface (aka relays driven by a Raspberry Pi 3A+) out by the pool equipment.
I am getting this in the HE log. I have two thermostats and the first one work completely. The second one will receive manually made changes on the device but if I use the dashboard to make a change I get this below in the log. Any ideas?
dev:182023-03-04 01:37:27.060 AMerrorjava.lang.NullPointerException: Cannot set property 'SystemSwitch' on null object on line 225 (method setThermostatMode)
dev:182023-03-04 01:37:27.050 AMdebugsetThermostatMode: off
dev:182023-03-04 01:34:53.869 AMerrorjava.lang.NullPointerException: Cannot set property 'FanMode' on null object on line 252 (method setThermostatFanMode)
dev:182023-03-04 01:34:53.860 AMdebugsetThermostatFanMode: auto
dev:182023-03-04 01:34:47.079 AMerrorjava.lang.NullPointerException: Cannot set property 'FanMode' on null object on line 252 (method setThermostatFanMode)
dev:182023-03-04 01:34:47.069 AMdebugsetThermostatFanMode: circulate
Here is some more log info:
dev:182023-03-04 01:34:07.602 AMerrorjava.lang.NullPointerException: Cannot set property 'SystemSwitch' on null object on line 225 (method setThermostatMode)
dev:182023-03-04 01:34:07.565 AMdebugsetThermostatMode: off
dev:182023-03-04 01:31:48.398 AMinfoGet Operating State: cooling - Fan to on
dev:182023-03-04 01:31:48.395 AMdebugsending temporary hold
dev:182023-03-04 01:31:48.394 AMdebuggot Emergency Heat = false
dev:182023-03-04 01:31:48.393 AMdebuggot scheduleCapable = true
dev:182023-03-04 01:31:48.392 AMdebuggot Vacation Hold = false
dev:182023-03-04 01:31:48.391 AMdebuggot holdTime = 540
dev:182023-03-04 01:31:48.383 AMdebugld = [fanModeOnAllowed:true, fanMode:0, fanIsRunning:true, fanModeAutoAllowed:true, fanModeCirculateAllowed:false, fanModeFollowScheduleAllowed:false]
dev:182023-03-04 01:31:48.372 AMdebugld = [ScheduleCapable:true, OutdoorTemperatureSensorNotFault:true, SystemSwitchPosition:3, SetpointChangeAllowed:true, OutdoorHumiditySensorNotFault:true, DispTemperatureStatus:0, HoldUntilCapable:true, HeatNextPeriod:36, HeatLowerSetptLimit:40.0000, SwitchCoolAllowed:true, IsInVacationHoldMode:false, IndoorHumidStatus:128, OutdoorTemperature:128.0000, ScheduleHeatSp:70.0000, TemporaryHoldUntilTime:540, OutdoorTempStatus:128, IndoorHumiditySensorAvailable:false, CoolUpperSetptLimit:99.0000, OutdoorTemperatureAvailable:false, SwitchEmergencyHeatAllowed:false, Deadband:0.0000, EquipmentOutputStatus:2, SwitchOffAllowed:true, VacationHoldCancelable:false, SwitchAutoAllowed:false, DeviceID:4701020, VacationHold:0, StatusCool:1, IndoorHumidity:128.0000, DisplayUnits:F, HeatSetpoint:70.0, Commercial:false, CoolSetpoint:62.0, HeatUpperSetptLimit:90.0000, CurrentSetpointStatus:1, DualSetpointStatus:false, ScheduleCoolSp:72.0000, VacationHoldUntilTime:0, StatusHeat:1, DispTemperatureAvailable:true, OutdoorHumidityAvailable:false, DispTemperature:70.0000, OutdoorHumidity:128.0000, SwitchHeatAllowed:true, IndoorHumiditySensorNotFault:true, CoolNextPeriod:36, CoolLowerSetptLimit:50.0000, OutdoorHumidStatus:128]
dev:182023-03-04 01:31:48.370 AMdebugRequest was successful, 200
Thanks so much for making this driver. I have been leaving Smarthings around just for my thermostats.
Does the number of Thermostats or Number of Parents have an effect on the "login attempts"?
I have 10 Thermostats across 2 houses that I would like visible. I had it set up with 2 Parents and the respective children in each house but I was basically locked out of the web interface saying to many login attempts.
Would moving to one parent reduce the polling or does it log in for each thermostat and the sheer volume of thermostat is the problem?
I use Node-RED to capture and store HE events in a database. That screenshot was from the Node-RED dashboard (https://nodered.org). Node-RED has functionality to create a dashboard - it's pretty much a blank canvas, so can be a bit intimidating.
1 Like
you need to disable it if not used in the app.. there is no actual message that the humidifier is on.. the only way it estimates this is if the fan is on but the heat is not.. so if not using it disable the option to say you have a humidifier.. if you do have one.. it will say the wrong thing part of the time at the end of a heat cycle when the heat is off but the fan is on.
also remember this is not instantaneous so it is what was happening when it last check which could be a while in the past depending on your refresh setting.
2 Likes
You are amazing, thank you so much!!
1 Like
Released Parent:
v2.0.15 Added a style to Username/pw parameter
Released Child:
v2.0.6 Added a hint for Device ID parameter
Ultra minor update, just offers a hint of where to find the Device ID.
Obviously this has no effect on a working TCC connection, it's cosmetic. Don't rush to update, in other words 
@csteele, thanks for the work on this! I’m a Hubitat noob and this is working well for me. However, something I noticed is that the API mode mapping (for my thermostats at least, VisionPro 8000) is different than provided in the driver.
I had to change lines 74 and 504 of the Parent driver to this mapping:
1: 'heat', 2: 'off', 3: 'cool', 4: 'auto', 0: 'emergency heat'
Otherwise Hubitat showed the thermostat mode as being in “emergency heat” when it was actually in “auto,” since 4 was mapped to that. I found this mapping list in one of the script files on the TCC portal, so I’m curious if it applies to all models, or just ones with emergency heat. There are actually 2 “auto” modes in the script file (4 for autoheat and 5 for autocool), which I believe dictate which temp setting is being altered on the thermostat screen when only 2 buttons are available, so it probably doesn’t directly apply to Hubitat but both return values may need to be displayed as “auto”.
I think this may explain some of the discrepancies experienced by a few other posters as well.
I have owned two Honeywell models and neither support Emergency Heat. I got the code / testing for that from another community member. I'm happy to follow the advice but I cannot test it. 
It may make sense to expose the mapping string as a defaulted parameter in the parent driver, in case there are other variations or changes in the future.
@csteele - I've been using this driver for quite a while and I would occasionally get error messages like the following:
Date/Time: 2023-11-07 11:47:01.063
Message: getStatus response invalid: groovy.json.JsonException: Lexing failed on line: 1, column: 1, while reading '<', no possible valid JSON value or punctuation could be recognized.
Date/Time: 2023-11-07 11:47:01.104
Message: java.lang.NullPointerException: Cannot get property 'deviceNetworkId' on null object on line 445 (method getStatusHandler)
Lately, I've been getting these much more frequently (3-4 times a day and they always come in pairs). I'm on the latest version of the driver ( v2.0.15 ) and also the HE firmware (2.3.6.146). Any idea what could be triggering this? I'm not doing anything special with commands - just reading current state. Poll interval is 5 minutes.
Thanks for your help!
It's hard for me to explain as simply as I'd like. It means that the data returned is not JSON. The JSON parse fails because, when I've seen this, it's html. html isn't json so trying to interpret it as json, fails. So the data being returned is a web page, when I saw it. It was a web page that basically said, please login.
They come in pairs, yes. It fails to parse, one error, and then the empty result is trying to find a value in the empty result, error two.
I have no idea why, because Honeywell is quite opaque on this API. It may just be the latest iteration of bandwidth limiting.
