That's an Attribute in the Parent/Child version and has a value that is inherent to the changes made from the conversion. I have chosen to focus all development on the Parent/Child version. I have backported most benefits to the Single code.
I have both versions installed on a couple of hubs and use the disable feature to dictate which runs.
Well, now please if you can help and explain how to create this Parent and Child device, because the drive I'm using I don't know if it's the right one. Where can I find more information and download it correctly?
Can you turn on debug logs and then hit refresh, please? You should get a log line like this:
dev:2471 2024-07-08 03:48:59.682 PM debug received Refresh request from Honeywell Thermo Downstairs to Honeywell TCC 'refresh', unit: = °F, fromUnauth = false
The "unit" will display what the driver is getting from the Platform. That value is stored in "location.temperatureScale" and that is tested in about 20 places in the driver. In other words, the screen cap you provided is what it looks like in the GUI, and is read by apps and drivers as "location.temperatureScale" as just a single letter, either C or F
[Which is checking and if it's F then reduce the heat setpoint by 1 whole degree but if it's Not (because it's a C) then reduce the setpoint by half a degree.]
I think you are saying that ONE of the 20 or so places it's checking isn't right or that there should be one more check.
Problem has just been solved, I had to increase the time to 30 minutes, I finally got a connection, and then the temperature updated to C, and I can control the AC. Sorry for the inconvenience, but with such a long time I'm going to have to rethink some of the AC management rules.
Honeywell puts you in a condition where they 'deny' everything for some time period. Once you've backed off for long enough, you can go back to a more rapid polling. This hits me all the time during development. I'm testing something and clicking refresh at a rate that gets me "banned". I have to go get a drink, get rid of a previous drink, or something similar, then I can resume my testing.
I don't use Easy Dashboard BUT I did create one when it was introduced just so I'd know what people were talking about. Turns out I included my Honeywell Thermostat in that experiment, oh so many months ago
Ok, Well then parent/child structure is not the variable that is causing the issue.
One other idea: In Hubitat, my fan mode reports as Unknown because the TCC site does not pull that data from my T-stats, so that data is not available on the TCC site for Hubitat to get.
Could that be what is causing the issue for this tile in EZ dashboard?
It works fine in the original dashboard. Looks like this:
Usually EZ dash prompts you with the missing value.
That said, there was (are?) issues with EZ dash and missing things like fan, or heat/cool modes. I would have to go back and search to see if Victor ever added a workaround for these missing items like I remember he said he would at one point in time.
so here is my dilemma.. I have csteele's "Honeywell Thermo Parent and WIFI Thermo Compnent" installed as well as the "API C" version. API C allows easy dashboard, but the setting of fan mode give me this..
2024-10-23 11:13:33.545 AM[error]java.lang.NullPointerException: Cannot set property 'FanMode' on null object on line 253 (method setThermostatFanMode)
The Wifi version works but can't be used on EZ Dashboard.. when you try and set that one up I get the "Missing Attributes:
supportedThermostatFanModes, supportedThermostatModes" error.
Initially I thought it was a platform issue that crept in related to the NPE (NullPointerException) because it's complaining about something that has worked for 5-6 years. I downgraded my Hub to 2.3.8. and checked. No NPE. Upgraded back to 2.3.9.196 and no NPE. It was a quick test and I could have overlooked something but it was easy enough to find before
Returning to v2.3.9 and the EZ Dash I had before is gone, I had to recreate it. Not unexpected.