Honeywell Thermostat Handler

smartapp
honeywell

(Tund3r) #1

Hi,

I installed the thermostat RTH9580WF with the native Handler and I have a couple of questions:

  1. After a certain amount of time (I not sure how much) if I click “resume program” it returns an error: Error resumeProgram() check parent.setFollowSchedule()

If I click reload and then I try again it doesn’t change anything but if I change the temperature and then I call “resume Program” it works fine. I guess it gets somehow logged out and the “resume Program” function does not check the state of the log in or something similar.

  1. I’m logging the state of the AC on a google sheet and I’m trying to calculate how much time the AC actually works but the app shows the AC in Idle as soon as the thermostat hits the temperature even if the AC still working. I live in florida and the AC (even hitting the temperature) never stops trying to maintain it. The official totalconnect app shows if the compressor is on or off so I’m wondering why the handler does not use that and instead uses the temperature to determine if the AC is on or off.

Please let me know how can I help to solve this issues, I can code if necessary :wink:

Thank you
Andrea


(might be my fake name?) #2

Resume program isn’t working. supposedly they are working on it.

@slagle any word on this?


(Tund3r) #3

I find out that it works only after calling “lowerSetpoint()”.
The problem with calling lowerSetpoint before the ResumeSchedule is that the handler is asyncronous, and for some reason it execute only lowersetpoint, But if I call the lowersetpoint from the console and then I run the app it works (the resumeschedule in the console works too)


(Chris) #4

ST only seems to get thermostatOperatingState updates from the thermostat when ST initiates the change (for me, that’s when I get home and ST changes my cooling setpoint from 82 to 78 - ST is updated at this point). If the thermostat turns itself on and off with no direction from ST the thermostatOperatingState attribute is never updated I’ve been emailing back and forth with support for a couple weeks and they don’t seem to understand what the problem is.

I’ve even tried manually refreshing the thermostat while the a/c is running and it still doesn’t update.


(Tund3r) #5

To me it updates constantly but it says idle if the AC is working but the cooling temp is the room temp.

Ex room temp is 73, cooling point is 73 and the Compressor is on, the app says idle. if I lower the temperature on the termostat (doesn’t matter if on the thermostat, on the official app or smartthings) when I refresh it shows “Cooling”


(Chris) #6

But if you don’t change the set point and the thermostat turns itself on just because the temp inside rose, no update, right?


(Tund3r) #7

It does but I think with a 5 minutes delay, I think it’s the time between probes from the app, I don’t think there is anything from honeywell that tells smartthings something has happened so smartthings will know only when it refreshes the state.


(Chris) #8

Interesting. I had a WebCoRE piston set up to refresh the thermostat every minute and still didn’t see updates come through.


(might be my fake name?) #9

Resume schedule only works for me if I raise the setpoint first then push resume schedule. Resume schedule will not work by itself.

So as a workaround, for my core pistons, I added raise set point First and then resume schedule.


(Tund3r) #10

Hi Erix, thank you for the answer, I found the same workaround, except that when I execute raisesetpoint and after the resume it looks like the raise is asyncronous and it get executed after and the resume schedule get ignored (it doesn’t go on error) if after the raisesetpoint I wait that the setpoint get executed then the resume works. Did you find the same issue, how did you worked it out?

This is what happens to me:

a5bc1e7c-b5ab-4c6f-8f55-5bb354c36674  14:22:41: debug generateStatusEvent: mode:cool, temperature:78, heatingSetpoint:62, coolingSetpoint:80
a5bc1e7c-b5ab-4c6f-8f55-5bb354c36674  14:22:41: debug alterSetpoint in mode cool succeed change setpoint to= 80
a5bc1e7c-b5ab-4c6f-8f55-5bb354c36674  14:22:41: debug alterSetpoint >> in mode cool trying to change heatingSetpoint to 62 coolingSetpoint to 80, deviceScale:F, localScale:F
a5bc1e7c-b5ab-4c6f-8f55-5bb354c36674  14:22:37: debug resumeProgram() is done
a5bc1e7c-b5ab-4c6f-8f55-5bb354c36674  14:22:37: debug resumeProgram() is called
a5bc1e7c-b5ab-4c6f-8f55-5bb354c36674  14:22:37: info In mode cool raiseSetpoint() to 80

and actually the resume program doesn’t go in error but it is not executed since the temperature for the program is set to 78 and it went to 80 (the hold was at 79)


(might be my fake name?) #11

That’s. Weird. I don’t know. Resume schedule will only work for me if I first raise Setpoint. See below.

Resume schedule by itself won’t work.


(Tund3r) #12

You have a wait 5 seconds in between, I’m actually coding the app so I’m not sure it behave differently. I don’t like too much the wait option because what if the thermostat is lagged? what if smatthings is slow? it might or might not work, I would really like to have a solution where i’m sure it works


(might be my fake name?) #13

Yes. The real solution would be for Smartthings to fix the resumeprogram command. @slagle, any word on a fix for this yet?


(Charles) #14

Thanks for the suggestion to use raiseSetpoint. The following worked for me. I put in the delays because my observation looking at the thermostat was that it took about 20 seconds for ST changes to be reflected and the resume is not time-critical.

But a real fix would be nice, @slagle


(might be my fake name?) #15

Glad it worked. I’m waiting for web core to get just a little bit more developed-- A little bit more “beta” if you will . I have a lot of Pistons that use LIFX integration that’s what I’m waiting for. So for that reason, I still use core. @ady624


(Tund3r) #16

@cal the delay of 5 seconds should be fine since is the time it takes to smartthings to communicate the changes to totalcomfort cloud, than totalcomfort takes extra time and the thermostat probably needs some to reflect the changes.

I prefer it short since if with the raise temperature you stop the compressor and calling the resume the compressor needs to be on it will take 5 minutes to start again, with the short time hopefully the thermostat does not makes the changes on time (but the cloud did wich is what we need).

@eric do you know if there is any way to help? this is a open community and there are a lot of programmers (actually the integration has been taken from a contributor) It’s annoying we need to live with this bugs for months! Or does anyone has documentation from the honeywell that can share so I can fix the total comfort api that is open.


(might be my fake name?) #17

I don’t know if there’s anyway you can help or not. When I installed the thermostat, I just used the stock total connect app with ST. That’s all I know. Then resume program stop working about a month ago. I’m not a programmer, I wouldn’t know where to start.


( I hate Mondays) #18

there will most likely be no LIFX integration :smiley:


(Ed) #19

Have you heard anything from ST regarding the thermostatOperatingState? I was trying to create a webCoRE piston using the thermostatOperatingState and I noticed that mine always says Idle and never changes to cooling or heating either even though the A/C is currently running. Refresh didn’t seem to work either.


(Chris) #20

Nope. Nate from support was emailing me about once a week telling me they were looking into it. Here’s the last thing I got from him, back on June 3. I added an acceleration sensor to my A/C unit so they can see when it’s actually running vs when ST/Honeywell says it’s running. No feedback as to whether or not it’s helping or where they are with this. The nice thing is that the acceleration sensor gave me a workaround for what I was trying to do with the official integration, which is be able to turn my ceiling fans down one speed when the A/C was running. Works great, just cost me an extra $35 for the sensor.

[quote]
Hey Chris,

Thank you so much for your patience, I apologize that our replies have been scarce. Rest assured we have definitely been looking into this, but progress has been a bit slow.

At this point I’ve brought it to the attention of some engineers and we’re submitting a ticket to have this looked into a bit deeper. If it’s alright with you, I’ll get back to you as soon as we have some word on this. In the meantime feel free to let me know if you notice any other issues on your end.[/quote]