I have not been able to test fan control since I don’t have a system that uses it. I may be able to help if I can get logs of attempts to control fans with debugging enabled. PM me if you’d like to try (I don’t monitor the forum very often any longer).
[quote=“Isablend, post:594, topic:185402”]To your points the other day about ‘Quick Actions’; which apply at a parent level. So for instance I have the plug in defined at ?house? level with thermostats documented in individual rooms. They would then require switching at that top level, where it would filter down to the impacted child thermostats.
The quick actions available are;
Economy - turn all thermostat setpoint’s down by 3 degrees
Away ? sets all zones setpoint’s to a default of 15 degree Celsius (which is adjustable) ? I?ve never been sure about this as 15 degrees seems too high to me to have apply when there is no-one around, but there you go, just my 2 cents worth?
Day-off ? all zones to follow the day off schedule (Saturday?s by default)
Custom - only the number of zones as selected in the evohome’s settings will follow the custom schedule.
Heating Off ? all zones set to the ‘heating off’ temperature which is 5 degrees by default.
Once again top job. If you want anything specific tested let me know and in the mean time I’ll keep monitoring over the next couple of days.[/quote]
Following on from Isablend’s comments above, is there any way to control the Quick Actions available at a parent level in TCC? If we had access to these we could use presumably Vera’s Geolocation to set quick actions, rather than the current convoluted Life360 + IFTT method.
Mikee - I’d like to thank you for all your hard work on this plugin, it is working flawlessly for me and an excellent addition to Vera.
@manchild - the change for fan control is being ignored. It looks like this is due to an incorrect variable name. Here is the updated lua file to correct it. Let me know if this fixes the problem.
Is there any way to control the Quick Actions available at a parent level in TCC? If we had access to these we could use presumably Vera’s Geolocation to set quick actions, rather than the current convoluted Life360 + IFTT method?
Technically yes, there is an API for evoTouchSystems to set the quick action Auto, Custom, AutoWithEco, Away, DayOff or HeatingOff and a time, I assume this is the action time (It is called QuickActionNextTime so I assume this is what it does, if not set I assume indefinite hold). The question is how would it work ? Would I just add an API to let you call it with one of these arguments ? It would obviously only work with EMEA backends since no other protocol has this capability (that I am aware of).
Currently I use IFTT and Life360 to report location and change settings accordingly. This is very hit and miss as the Life360 accuracy on location is awful.
Using fine tuned settings on iPhone locator plugin I’ve been able to set up very accurate location handling for both me and my wife. If I could use this info within Vera to simply change Honeywell Evohome to Away when we are both away or revert to schedule (Auto) when one of us is home that would be great.
All the other modes IMO are pretty irrelevant as they would generally only be selected if in the house (in which case we’d use the Honeywell interface).
So
Vera away = Honeywell Away
Vera home = Honeywell Auto
Obviously I can set up the simple rules but need the API option to change mode?
Hmmm, after a bunch of digging it looks like the options for the two interfaces (webui and emea) work differently (of course). emea uses temperatureControlSystem and mode number to implement the quick actions. webui uses evoTouchSystem and action name. Each action maps to a mode setting. The emea API is the same API used by this plugin to turn the heat on and off currently, i.e. heat on is quick action ‘Normal’ and off is quick action ‘HeatingOff’. So this could be mapped to UPNP HVAC_UserOperatingModel1/SetTargetMode is we can define ‘Away’ as a vendor specific mode. I think we are probably safe if we map all of the quick actions to TargetMode. The currently used modes are Off, HeatOn, CoolOn and AutoChangeOver. If the evohome modes were added HeatingOff->Off (already exists), Normal->HeatOn (already exists), Custom, Eco, Away and DayOff it should be able to set all the quick action modes. You would need to arrange to invoke this API and specify the mode as an argument in your mapping logic. Does this sound like it will solve your issue ?
Probably time to as a group move on and buy and Amazon Echo, Dot, Tap. The Honeywell Total Connect Skill works like a charm. "Alexa set the thermostat to 72 degrees. “Alexa raise the thermostat by 2 degrees”. Perfect.
I’m having this exact problem (inability to cancel hold) with my US (TCC) stats. In altid I see TCC_(7 digits) – I’ve tried every form of the ID I can think of, quoted and unquoted. What bothers me is that I can’t figure out how to even tell whether the Lua method is being called. I put obvious syntax errors in it like removing a parenthesis and nothing happens – if I invoke it as extra Luup code from a scene, I can’t find an error anywhere and the scene reports success if I invoke it manually; if I try pasting it into the “develop apps” lua box, same same.
Here’s exactly what I tried last time, with just the numeric part of the ID obscured:
local lul_arguments = {}
lul_arguments[“ThermostatID”] = “7 digit number”
luup.call_action(“urn:joeyd-com:serviceId:HoneywellTCC1”,“CancelSetpointHold”,lul_arguments,10)
I figured out how to download the Lua files from the Vera just to check that I did in fact want “urn:joeyd-com” rather than the “urn-schemas-joeyd-com” I see in some of the device properties. I’d log into the device and look at the logs but the instructions I can find for turning on the root account for SSH seem broken – I go to settings->network and there is no “advanced” tab to set a root password. So now despite some knowledge of Lua and a willingness to debug in depth, I am stuck.
I find it very suspicious that if I produce an obvious syntax error in the Lua code nothing changes in any way that is visible to me. Help?
OK, I plumbed “Eco” and “Away” thru to the EMEA backend to set the mode (I did not add DayOff or Custom). The issue here is that when the backend reports the status as Eco or Away it must be converted to something vera expects. It will be shown as “HeatOn” so there will be no indication from vera what mode it actually is in (but you should be able to read what was set in the TCC ModeTarget variable). Part of the problem is vera uses two setpoints, one for heat and one for cool. You need to know which mode you are in in order to know which setpoint is valid. Anyway, if you set the mode to “Eco” or “Away” using the HVAC_UserOperatingMode1/SetModeTarget action it should send the mode thru. I have attached the 3 files needed. I can not test this code at all, sorry.
Hi guys just bought into the Honeywell system, I have searched through the forum but not found an answer to if there is any way to track when the boiler is set on. Just trying to track how often the boiler is switched on through the day.
Mike, thanks very much for looking into this. I’ve been away on vacation so just catching up on this thread but really please there could be a way forward with this.
I’m afraid to say that I’m very much a newbie with Vera and don’t how to implement a change in SetModeTarget from a scene. Could you please give me (and anyone else who may be in my position) a few steps in the right direction?
is there a way to set the mode to “emergency heat”? I see Auto/Cool/Heat but no emergency heat. I have my boiler hooked up on that setting and us it all the time in the winter vs. “heat” which is my heat pump.
Thanks again.