Forgot to add, my stat is an MHK1 (Honeywell > Mitsubishi) which is wireless but is passing data from my Mitsubishi units > Redlink gateway > TCC. Here’s a screen shot of my options via TCC. And also a shot from the Smart Things IDE for this specific device. I’ll take a look at the code and see if I can insert a luup.log and dump the decoded payload.
I upgraded both of my VeraLite to UI7 so I don’t have a UI5 machine. However, I have been reading about the json between UI5 and UI7 and see it is different. You likely aready have this info. I was trying to figure out how to get the thermo icon to change based on ModeState… no luck in figuring this out yet.
http://wiki.micasaverde.com/index.php/Luup_plugin_icons
http://wiki.micasaverde.com/index.php/Luup_plugins:_Static_JSON_file
The attached updated lua file tweaks should fix CudaNet’s issue with the fanState variable, and it also updates the ModeState variable to indicate active heating or cooling…not that the UI reflects it…but you should be able to see the ModeState variable in the advanced tab after uploading this file, relaoding luup, refreshing your boweser…
Just looked at another thermo on permanent hold and StatusHeat=2. This makes sense since the values for changing the setpoint seem to be 0=cancel, 1=set until next program (or use *NextPeriod) and 2=permanent. If you are checking for ~= 0 you should be all set. Otherwise seems 1 or 2 would indicate heat/cool calling.
Yeah, ‘permanent hold’ is my friend 8)
I truly hate the stat’s programming interface which is why this projects is so awesome ! Once it has a fully functioning service I can set my temps via Google Calendar.
Thanks…I can confirm that when my stat is set to permanent hold, that “StatusHeat” is a value of 2. My last update a couple posts prior was only looking for a status of 1…
All is well…
06 01/12/15 17:07:49.896 Device_Variable::m_szValue_set device: 235 service: urn:joeyd-com:serviceId:HoneywellTCC1 variable: cookieRefreshTime was: Mon, Jan 12, 05:07:14 PM now: Mon, Jan 12, 05:07:49 PM #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2fb63680>
06 01/12/15 17:07:49.921 Device_Variable::m_szValue_set device: 235 service: urn:joeyd-com:serviceId:HoneywellTCC1 variable: cookieRefreshTimeSuccess was: Mon, Jan 12, 05:07:14 PM now: Mon, Jan 12, 05:07:49 PM #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2fb63680>
06 01/12/15 17:07:49.921 Device_Variable::m_szValue_set device: 235 service: urn:joeyd-com:serviceId:HoneywellTCC1 variable: credAuthorized was: now: Successful #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2fb63680>
06 01/12/15 17:07:50.672 Device_Variable::m_szValue_set device: 235 service: urn:joeyd-com:serviceId:HoneywellTCC1 variable: t.1.refreshStatus was: Successful Refresh: Mon, Jan 12, 05:07:15 PM now: #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2fb63680>
06 01/12/15 17:07:50.673 Device_Variable::m_szValue_set device: 235 service: urn:joeyd-com:serviceId:HoneywellTCC1 variable: statusRefreshTime was: Mon, Jan 12, 05:07:15 PM now: Mon, Jan 12, 05:07:50 PM #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2fb63680>
06 01/12/15 17:07:50.674 Device_Variable::m_szValue_set device: 235 service: urn:joeyd-com:serviceId:HoneywellTCC1 variable: statusRefreshTimeSuccess was: Mon, Jan 12, 05:07:15 PM now: Mon, Jan 12, 05:07:50 PM #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2fb63680>
06 01/12/15 17:07:50.674 Device_Variable::m_szValue_set device: 235 service: urn:joeyd-com:serviceId:HoneywellTCC1 variable: getStatus was: Successful now: Successful #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x2fb63680>
06 01/12/15 17:07:50.674 Device_Variable::m_szValue_set device: 235 service: urn:joeyd-com:serviceId:HoneywellTCC1 variable: t.1.refreshStatus was: now: Successful Refresh: Mon, Jan 12, 05:07:50 PM #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x2fb63680>
06 01/12/15 17:07:50.676 Device_Variable::m_szValue_set device: 236 service: urn:upnp-org:serviceId:HVAC_UserOperatingMode1 variable: ModeStatus was: HeatOn now: HeatOn #hooks: 0 upnp: 0 v:0xf0f1c8/NONE duplicate:1 <0x2fb63680>
06 01/12/15 17:07:50.676 Device_Variable::m_szValue_set device: 236 service: urn:upnp-org:serviceId:TemperatureSetpoint1 variable: CurrentSetpoint was: 62 now: 62 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x2fb63680>
06 01/12/15 17:07:50.687 Device_Variable::m_szValue_set device: 236 service: urn:upnp-org:serviceId:HVAC_FanOperatingMode1 variable: Mode was: 0 now: 0 #hooks: 0 upnp: 0 v:0xf03420/NONE duplicate:1 <0x2fb63680>
06 01/12/15 17:07:50.688 Device_Variable::m_szValue_set device: 236 service: urn:micasaverde-com:serviceId:HVAC_OperatingState1 variable: ModeState was: Idle now: Idle #hooks: 0 upnp: 0 v:0xf0f1a8/NONE duplicate:1 <0x2fb63680>
06 01/12/15 17:07:50.689 Device_Variable::m_szValue_set device: 236 service: urn:upnp-org:serviceId:TemperatureSensor1 variable: CurrentTemperature was: 65 now: 64 #hooks: 0 upnp: 0 v:0xf190f8/NONE duplicate:0 <0x2fb63680>
50 01/12/15 17:07:50.690 luup_log:235: HNYWL TCC: task Clearing... <ModeState doesn’t appear to update on UI.5 for me.
Thanks, ServiceXP. I will look into ModeSate…I noticed from the simplethings code that setting ModeState properly might actually depend on inspection of two different variables.
I was able to code in the bulk of what is needed to post the commands to the api / thermostats. I decided to implement this with a type of queue.
Basically, I don’t want to be sending a given thermostat a command any more often than once every 5 seconds. This has the biggest impact with the UI and setting temperatures using the “up/down (+/-)” buttons. In other words, if you want to increase the temp 5 degrees, I don’t want to send the thermostats 5 individual “setpoint” commands in rapid succession. The mytotalcomfortconnect.com web site forces you to press a “submit” button after you make changes. Even the physical wall unit has a “done” button when changing temp or fan settings. There is no “submit” button on our UI, so we must handle this differently.
To describe how the plugin command queue works, I’ll give an example. Suppose your thermostat is currenty set at 65 degrees, and no commands have been issued in the last 5 seconds. Now you press press the “up” button 5 times in rapid succession taking it to 70 degrees.
-
The first command gets sent immediately, so your thermostat is sent a “set setpoint to 66”.
-
Once this command is sent, the plug-in will continue to “queue” all subsequent requests until no buttons are clicked for a period of 5 seconds. So the plugin “queues” up the following commands:
– Set setpoint to 67
– Set setpoint to 68
– Set setpoint to 69
– Set setpoint to 70 -
Once 5 seconds have elapsed from the time you clicked the last button taking it to 70 degrees (and you haven’t pressed anything else), the plugin “flushes” the queue for that thermostat.
– It determines that the only command it actually needs to send is “set setpoint to 70”, so it then issues that single command.
So in practice this is what happens:
- Press up button rapidly taking to from 65 to 70.
- Your thermostat is sent a “set setpoint to 66” immediately after the first button is pressed
- 5 seconds after your take it to 70, your thermostat is sent a “set setpoint to 70”.
The queue works on ALL commands. So if you go button happy and press set-points, fan controls, operating modes in rapid succession, the queue will ultimately determine what final single command needs to be sent…and then sends it 5 seconds after the last button was pushed.
I have more testing to do with this before I feel comfortable publishing it for public testing. I also want to add a default setting to the UI, allowing the user to select the default behavior of changing set-points with the UI…either make it a permanent hold, or a temporary hold.
I get the error: Unsuccessful. Error Code 3 for the getStatus This has happened yesterday morning and this morning and until I re-enter my credentials it never recovers through out the day.
So what is a Error Code 3 ?
My latest code has the refreshing tweaked a bit so hopefully it will recover when this happens. The code 3 indicates that the server returned an “unauthorized request”, which will happen if the security cookie is incorrect or expires (at least that’s my assumption.)
Unfortunately, I found this to not be the case.
StatusHeat / Cool only tells you “what kind of hold” you have on your set-points. It does not indicate if you actively heating or cooling.
In other words, It can be 80 degrees inside temperature, and I could set a “permanent” heat set-point at 75 degress. Obviously, heat will not be active.
However, the value of StatusHeat will still be 2, because you have made the heat set-point permanent.
Value = 0: just following the programmed schedule
Value = 1: Temporary set point. (Could be either until the next schedule change, or until a certain time.)
Value = 2: Permanent set-point.
I do not see anything in the data packet we get from honeywell to indicate if the system is in fact actively heating or cooling.
I think the best we can do is set the value of ModeState based on the ambient temperature, and the switch position. In other words, if you are in heating mode and the temp is lower than the set point, assume you are actively heating and so assign ModeState to “Heating”.
This has issues though…such as
- What to do when the temp = set point…assume on or off?
- Some thermostats (mine include) give the user the ability to “automatically switch” between heating and cooling modes, which would further complicate (or maybe make it impossible) how to “guess” if you are heating or cooling.
Thoughts?
@joeyd
My system has the following settings / options
fan:
On
Auto
System:
Heat
Cool
Auto
Off
Emergency Heat
Home screen:
Heat set point
Cool Set point
Can you 1) read the already set states?
i.e can you read that the system is set to auto?
2) can you then read the already existing heat and cool set points?
If you can read those settings and can read the current temp, then based on that you should be able to know if it’s heating or cooling.
if your set point for cooling is 73 and it’s 74 in the house, you know it’s in cooling mod.
if your set point is 69 and it’s 68 in the house it’s in heat mode.
when i set a specific mode to heat or cool i obviously only get the 1 set point.
but i always leave mine on auto.
but you could say if Currentemp < Hsetpoint then mode = heating
or something to that effect.
Yes, that’s exactly what I was getting at…but it has the pitfalls that I mentioned.
We don’t really know if the system is heating or cooling, but we can assume if it should be or not.
Again, the “some of grey areas are”… (And for simplicity I’ll be talking about heat points only…)
-
If temp is the same as the set point, you might actually heating, or you might be off. Units don’t turn off at the same time the temperature reaches the set-point. They may have algorithms to run a bit longer, etc. (Helps prevent the system from cycling on / off too much)
-
You unit also may not turn on immediately when the temperature goes below the set-point. (Again, there may be some delay based on an internal algorithm.)
I think I’ll go with our assumption (for heating) though of
- “temperature at or above the set-point…then indicate not heating.”
- “temperature below the set-point: indicate heating.”
As long as it’s understood that it’s really to support a quick visual reference (for apps that support the ModeState and change the UI). It must be understood that it does not represent whether or not your unit is actually on…only that it is more or less likely to be the case.
Edit: The same goes for the FanStatus variable. This is intended to indicate whether or not the Fan is actually on or off. For now, I will simply “assume” that if your unit is actively heating or cooling (which is itself an assumption), or if your fan is set to “continuously on”, then I will report that your fan is on.
I looked at the logs I collected last night and verified your findings that StatusHeat is not indicating heat on/off.
You posted these values:
Value = 0: just following the programmed schedule
Value = 1: Temporary set point. (Could be either until the next schedule change, or until a certain time.)
Value = 3: Permanent set-point.
Is the Value = 3 a typo or did you see that value ? I get a 2 from mine.
I agree with the approach of the queue. I don’t like the setpoint up/down interface as sometimes it takes a long time for the zwave thermos to respond. I don’t know if it is a coincidence but it seems to respond better when using the buttons from the Control panel rather than the dashboard tile. I don’t get the 16 second “circle of impatience” 
Nice work!
Typo! Fixed.
I agree with the approach of the queue. I don't like the setpoint up/down interface as sometimes it takes a long time for the zwave thermos to respond. I don't know if it is a coincidence but it seems to respond better when using the buttons from the Control panel rather than the dashboard tile. I don't get the 16 second "circle of impatience" :)
Same observations here. “Circle of impatience” indeed when using the dashboard. For what it’s worth, the delay is much shorter when using vera’s mobile app. Only on the web interface is it really unbearable.
for your queuing, you indicate that after the first button is pressed, you then will queue the next 4, before sending
out of curiosity, why not just queue the whole thing from the start. instead of after the 1st click?
so say i want to turn up the temp from 65 to 70
wait 5-10 seconds after the last button press before sending setpoint.
vs. sending, waiting and then sending again.
again this is just out of curiosity
Someone might want to confirm in test as I took this from the Java.Groovy. If you didn’t need this then my bad ! I’m bouncing around on different projects here at work.
“StatusCool” == 1 and “SystemSwitchPosition” == 3 then the operating state is currently cooling
“StatusHeat” == 1 and “SystemSwitchPosition” == 1 then the operating state is currently heating.
Once could assume if it’s neither of those then the operating state is idle.
“fanMode” == 0 then “fanMode” == “Auto”
“fanMode” == 1 then “fanMode” == “On”
“fanMode” == 2 then “fanMode” == “Recirculate”
And some data on SwitchPosition
“SystemSwitchPosition” == 1 then “SystemSwitchPosition” = “Heat”
“SystemSwitchPosition” == 2 then"SystemSwitchPosition" = “Off”
“SystemSwitchPosition” == 3 then “SystemSwitchPosition” = “Cool”
“SystemSwitchPosition” ==4 then “SystemSwitchPosition” = “Auto”
And for those extracting the data themselves for analysis…
[size=8pt]Current ambient = latestData.uiData.DispTemperature
Fan mode = latestData.fanData.fanMode
Thermostat switch position = latestData.uiData.SystemSwitchPosition
Cooling SetPoint = latestData.uiData.CoolSetpoint
Heating SetPoint = latestData.uiData.HeatSetpoint
Cooling Status = latestData.uiData.StatusCool
Heating Status = latestData.uiData.StatusHeat[/size]
Just a follow up on my Error 3 and Now Error 200. So I think I follow what is happening.
- The plug-in only works for a period of time (not sure how many hours but it’s not more than 10) and I start getting Error 3.
- Once that starts, the plug-in will not recover. If I go and hit the update button, I then get an error 200, even though the log-in information is correct.
- If I then make any changes to the Username or Password, save and refresh. I then find the fields populated with “undefined” with error 200 persisting,
- If I re-enter the log-in information again, save and refresh everything works for the next un-derterminded amount of time until the entire cycle is repeated…
Hope this helps…
[quote=“mvader, post:57, topic:185223”]for your queuing, you indicate that after the first button is pressed, you then will queue the next 4, before sending
out of curiosity, why not just queue the whole thing from the start. instead of after the 1st click?[/quote]
In most cases I figure that changes will just be a random click. (turning on or off, etc.). So in the case that just a single button is pressed, I wanted that change to go immediately. I considered just queuing everything, but I wanted the more instant gratification of “press once, immediate change.” No other technical reason for it. 