Hmmmmm, this gets interesting. First, I installed Honeywell home from HPM. Then I modified it with the files you gave me . I'd like to go on with HPM, so is there anything I need to do before I update with your version (by simply installing it)?
I'm not sure where you are at. First, you don't want to use the files that I gave you earlier this year. Those are now out of date. The changes that I made for you are now in the production code. So, installing from HPM would put you in a good state. Just make sure that you get the right package from HPM, the one designated as from me.
OK, I did. Now I have two installations of Honeywell Home, that means, two drivers and two apps. My room sensors show up at the old driver. How do I move them to the new driver (without having to redo all the apps they're used in)?
Okay, now I have a clearer idea of where you are. Here's my take of getting back to 1 app and the associated drivers:
-
Assuming your old driver is there, has the sensors and is associated with other apps, go into HPM and unmatch the new driver so that HPM forgets about it. That step is done by going into HPM and selecting Package Manager Settings. In that screen, near the bottom is a Remove a Matched Package button. Select the Honeywell Home package you installed and unmatch it. Now you are safe to delete the second driver and app code and you should do that. You should open the driver code and the newest code, which you just unmatched, will have a version of 1.06, near the top of the file: String appVersion() { return "1.0.6" }. You will see that in each file, the app, the thermostat driver, and the remote sensor driver.
-
Now you are back to square one and you can go into HPM and Match Up your existing app and drivers as I indicated above in this thread. Again, make sure that you select the right package, per my screenshot.
-
Now HPM is aware of your existing installation and you should be able to use HPM Repair to get the latest code into your installation. If you want to check and make sure that you have the right code, go into the Apps Code section and open the Honeywell Home app. Near the top you will see the change log and you should see this entry at line 19:
5/19/26 FTY Update base API URL -
If you've gotten this far, you should be good to go. As I said earlier, the changes that I made for you last year are now part of the production code. No need to overwrite with the old files and, if you do, you will break the app.
Let me know how it goes.
Good Morning, Tim,
When I tried to match up the existing (old) code in HPM, it found - nothing. But - after unmatching the old package as well, everything went fine.
Thank you again for your help. You rock!
Hey, Everybody,
the Honeywell Home drivers poll the thermostats every so often, let's say every 15 minutes. How can I find out when that polling happened?
This is my use case:
My tenants tend to fiddle around with the thermostat settings every once and a while, and sometimes they create unhealthy constellations (eg. too little spread between heat an cool setpoint). I want to run a check and correct these situations if necessary.
Any ideas?
If you go into the App, click on the little “i” button in the top-right corner. That displays the app details and settings. On that page, you will see a scheduled jobs section. That has a job for “RefreshAllDevices”. That will show you what time the next run is. For me, it is 12:30 pm today and I refresh every 30 min. so it runs on the half hour.
Anything I could use as a trigger in RM?
Well, if you know what time the job runs, you could set a trigger to run 5 minutes before the job is supposed to run.
WHY bother with that .. if you want a notification set a trigger to fire anytime an attribute is updated. specifiically at least with my version of the driver there is a lastupdated attribute as well.
Yes, @kahn-hubitat makes a good point. Since you are worried about the heating and cooling setpoints, you could trigger off of the changed trigger for those.
Thank you, @kahn-hubitat , for chiming in.
Tim, does your driver expose lastupdated as well? How can I access it? I tried to find it in the condition settings and in the Custom Attributes, no luck.
And on a side note, should the two packages be merged into one again? Just a thought…
No, that is a custom attribute, not a thermostat attribute. It’s just a date/time value for the last refresh, from what I can tell. I explained how to determine when a refresh happens, which will give you the same information. Did you try that or the other solution to trigger off of the heating and cooling setpoints.?
Hello, you awesome people,
Thank you for your replies. And yes, after experimenting around quite a bit, I decided to use the “trigger through Thermostat Variables” thing, and it works well, even when the values of the variables stay the same.
All in all, the results that come out of the interface calls are only about 95% consistent - most of the time the calls run smoothly (with a Response of 200), and do what you want, sometimes nothing happened at all, and every once and a while I get a variety of errors (like “Set Api Call failed -- status code: 400, reason phrase: User Input Error: [code:400, message:nextPeriodTime required]”, or code 401 “reason phrase: Bad Request: null”), so it seems to be a good idea to check for integrity after a call. All in all, it’s a work in progress.
Thank you again for all of this!
I started receiving messages in my log that say:
Thermosat API failed retrying... -- status code: 429, reason phrase: Too Many Requests: [code:429.02.001, message:rate limit has been exhausted]
I am receiving them at every poll time.
I originally set my polling to 1 minute because I keep track of my runtime. When I started getting these mesages I bumped it to 2 minutes, then 5 minutes and I’m still getting them.
Since my A/C sometimes only run a few minutes and my original polling was fine for the past 6+ months everything was fine until the last few days. Something is either changed, or something is wrong.
Any ideas??
I have my polling set to 30 minutes and have had it that way for probably the last 5 years. Originally the server was complaining when I had it set to 10 or 15 minutes. They may have relaxed the limit some, but 1 or 2 minutes is hitting the server pretty hard.
Another possibility is that the auth token you are using is the one that ships with the app and other users are using the same token. Everyone using the same token could cause the error. There are instructions near the top of this thread on how to generate a new token. Basically, you have to set-up a Honeywell Developer account.
I have a developer account and API set up. This seems to have happened in the past few days. I was polling every 1 minute for over 1 year with no issue.
I have also requested a higher polling rate from Honeywell, so I’ll see how that goes.
Interesting. I’ll try bumping up my polling rate to see what happens. Please let me know how it goes with the request to up your polling rate. Another user in a different thread recently tried to set-up a developer account and they said that they had to review the request. Back in the day, they approved it right away without any review.
Well, I ended up bumping my poll rate to 55 minutes and I was still receiving the message. I finally decided to create a new app on the Honeywell API site, and then reconfigured the new token in Hubitat. So far that seems to be working. I started at 15 minute polls, then 10, then 5, now I’m trying 2 minutes. I’ll let you know how it goes.