I have the TCC US integration working fine. I edited the configuration.yaml file, cut and pasted the code from the integration page. Filled in username and password and my thermostats showed up.
My problem is that I have access to 9 thermostats in 2 locations. 8 of those are not my house and I don’t want to see them in HA.
I see that the docs say there are location and thermostat variables that I can use to restrict what the integration sees. I’ve tried all combinations I can think of for those variables and whenever I put either (or both) of them in the .yaml file, I get no thermostats showing. I’ve tried the name of the thermostat and/or the name of the location. I’ve tried the numeric IDs that show in the URL on the portal. Nothing works except removing those variables and getting all the thermostats.
Can anyone please give me guidance as to what values should be in those variables to limit the thermostats that show in HA?
Here’s an example of what I tried that did not work. The location I want to see is called “Home” and the thermostat I want to see is called “THERMOSTAT”. Creative, I know.
Thanks for any help.
climate:
# Example configuration.yaml entry
- platform: honeywell
username: MY_USERNAME
password: MY_PASSWORD
location: Home
thermostat: THERMOSTAT
I don’t think I understand the question. Once you define the Honeywell platform, the individual thermostats become available as entities. The entity is called something like climate.thermostat (or whatever name you gave it on the Honeywell server.) You can see them all in Configuration / Entities.
You can choose to put all, none or one of these entities on a page in Lovelace.
I’m not entirely sure how to re-word the question so it’s clearer.
I want to only retrieve the stats of my home thermostat. The others are work related and have no business in my home installation but I can’t remove them from my Honeywell account for reasons. The integration docs lead me to believe that it’s possible to only retrieve the desired thermostat (or location) so that is my question. How to get that to work?
I recognize that I can choose to only place the one that I want on a page but, with the extra thermostats, I now have a crap-ton of entities that I will never use in my configuration. Plus, the integration is requesting data for all those thermostats and I’m a little concerned about TCC throttling me with all the requests for 9 thermostats. Others have reported being throttled for fewer. My packet sniffer leads me to believe that the data for the thermostats is being requested even when they don’t show on a page.
Simply, how do I make the feature shown in the documentation work?
Thanks. That’s what I’ve done as far as I can tell. My location in the TCC portal is called “Home”. If I put “location: Home” in the configuration file, I get no thermostats connected.
I just tested on my own configuration and I’m getting the same issue with either restriction. It appears from the kk7dx/somecomfort docs on GitHub that both location and thermostat ID should be numbers (eg: 117723). I’ll have to see if there’s some way to find the index numbers…
I can’t quite figure this out. I can find what look like location and thermostat indexes by examining the HTML on the TCC website when I look at my location and thermostat, but plugging them in still yields no thermostats
There are numbers that show on the url of the TCC portal when viewing a location or thermostat. Depending on the link, they look suspiciously like a location ID number and a thermostat ID number. I couldn’t get those to work either. Those are what I tried first when I set up the integration since ID implied number to me.
That gave me what look like thermostat and location IDs. I put those values in to the configuration.yaml and, still, no result. I tried with and without quotes and with both variables and with just one or the other.
Here’s what it looks like right now without results.
Sometimes, I get this error in the logs. It’s not coming up now on restart but I’m still not getting any results.
2020-12-02 19:11:19 ERROR (SyncWorker_1) [homeassistant.components.honeywell.climate] Failed to initialize the Honeywell client: Check your configuration (username, password), or maybe you have exceeded the API rate limit?
I don’t think I’m actually being rate limited because, if I take out the location and thermostat variables, I immediately get all 9 thermostats loaded.
I tried some of the other commands in that utility and they didn’t work as shown. I’m starting to wonder if something about the TCC API has changed enough that the location and thermostat variables don’t work like they used to.
I would love to know if anyone is using those variables in a current system.
I agree it would be nice to be able to just select one thermostat. Seems like the kind of thing which should be possible.
But I keep asking myself why.
What’s the harm in just using whichever fields you want, and ignoring the rest? I have lots of integrations which return more information than I care about. I don’t have to log any of it, and I certainly don’t have Lovelace display what I’m not interested in.
If the Honeywell API replies back with data on 9 thermostats, and I only want one, does it matter where in the hierarchy the data is dropped after it’s received?
I guess it would make a difference if the HA integration was doing 9 separate get requests for data. I haven’t dug deep enough to know, but the way it behaves makes it seem to me that the decision on what to return is made on the Honeywell side. If I’m wrong about that, obviously, you win the debate.
It seems to me that whatever the location and/or thermostat selectors are supposed to be doing, they don’t seem to be doing it correctly.
CaptTom: I can understand the desire to be selective. Every entity adds complexity to the system and uses resources, which in turn adds some amount of wear and tear on the storage media. In the case of SD cards, that can be quite significant. SSDs and magnetic media have a much longer lifespan, but it’s still limited and you don’t want to waste it on entities you have no interest in.
Mightrick: I don’t like this “solution”, but it may be the only way to do this. Could you, perhaps, set up another account on the Honeywell site and transfer the non-home Thermostats to that. It’s a bit of work, especially since it shouldn’t be required if the selectors just worked, but it would isolate those other stats.
CaptTom; In the end, this is probably not that big a deal and I will live with it as is.
But, there are a variety of reasons to at least do some minimal detective work.
The documentation says it’s possible and it’s a feature I desire. If it doesn’t work, then the documentation should be updated to reflect that. I think it’s useful to answer the question of the feature working or not rather than immediately questioning if I really need that feature.
There is a real concern about rate limiting from the Total Connect Service with that many thermostats in my list. I am not familiar with python at all but I am a programmer for a living and both the command-line module that I ran to get the device list and the code on Github for the integration appear to loop through each location and do a separate “GET” request for each thermostat that it finds.
I’m coming from the Smartthings world and I’m finding the extreme verbosity of the Home Assistant entities to be a real barrier to learning this new system. I set up a minimal installation of Home Assistant in a virtualbox machine. I had 1 (a single LIFX bulb) device in my system before adding the thermostats. A fresh install with 1 added bulb resulted into 29 entities! Now each thermostat has multiple entities and I have only tried to add 2 devices to my setup and I have over 100 entities. Putting aside the concerns of wear on the system, why should I be burdened with multiples of useless entities if I don’t have to? Hence trying to use the filtering feature of the documentation.
That said, I’m looking forward to the flexibility that HA gives me with all the added detail of each device (hence the move).
Quoheleth; Having multiple accounts is not a bad idea and one that I considered. I will probably just live with the extra entities while I save my money for a more open thermostat. For a variety of reasons, I currently have to monitor all of those thermostats multiple times during the day and I find it irritating to switch users in the TCC app.
To everyone; This is certainly not something to get worked up over. It was purely me seeing the documentation and trying to use the feature and then asking if anyone else had it working. Unless someone can show me a working configuration, I’m convinced that it’s broken. Being extremely new to HA, I have no idea if there’s process to submit a bug report to an integration. I am certainly grateful to whoever wrote this integration so that I have some control.
I agree that documented features should work. And that this feature seems like it would be helpful, and not hard to implement.
That said, if my suspicions are correct, then retrieving all of “my” devices from the Honeywell server probably counts as one hit for rate limiting. I can’t confirm this without digging into the code.
Finally, you can choose not to log any Honeywell information to the logger, which will avoid the problem of frequent writes to the SD card.
I’m only following this thread in hopes of learning more about the Honeywell integration. I’d also like to see all these questions answered, one way or the other. And I hope you come to a solution which works for you.
CaptTom; I appreciate the replies. It’s always good to have a different perspective.
Only “not hard to implement” if you know python which, unfortunately, I do not.
I don’t see how digging into the python code is going to tell you how Honeywell is calculating rates.
I did find this in their API documentation “Our limit is designed to allow you to poll device status every 5 minutes for up to 20 devices per hour, with a little cushion to make changes. If you need a higher rate limit, please contact us: [email protected]”
That still doesn’t tell me how they are calculating. Does that mean up to 20 thermostats is a single hit. How about fewer than 20 at a higher interval? I have no idea.
I actually did get rate limited last night when I was running the SomeComfort command line script. It ran about 10 times over 3-4 minutes and started returning empty values. It didn’t mean to run it that often. It was an unusual situation that involved a cat, a touchpad, and the fact that laptops make excellent cat butt-warmers. It took about 10 minutes from when I displaced the cat for the devices to start returning data again.
Is there a procedure to put in a bug/documentation request. I understand that this thing is community maintained. I’m happy to do my part within my skill set.
My guess was that each “get” would return all the devices associated with your account. But it’s just a guess. Would be nice to find out for sure. The Honeywell developers might even be able to give you some clues as to how their API can limit what’s returned to just one device. Just knowing there’s a way to do it would be a huge step forward. Sample code would be even better.
I can tell you from watching the traffic on my proxy, there is a GET request that returns the list of devices (with their ids) and there is a GET request for every device returned. In my situation, there were 12 transactions. An initial authentication transaction from my HA server, then the device list request, then a request for each thermostat.
Ahhh, thanks for doing the digging on that (and letting us know here.) That makes sense. Now the only question is whether all those get requests count individually toward the rate limiting or if it’s only by the session.
And it proves that your request to limit which devices HA pulls data for would add a lot of value.
