Ecobee - controlling fan "On or Auto" setting

I can’t seem to find the variable to control the fan On or Auto mode of the thermostat.

There is this:
String runtime_desiredFanMode “desiredFanMode [%s]” (gRuntime) { ecobee="<[123456789012#runtime.desiredFanMode]" }

But it is only a String only. It does show the status “on or auto”. I just realized that maybe I can try to change that items file and see if I can change the value.

I’d also like to know if the system is running or not. I can see the mode it’s in but it would be nice if I could find out if the thermostat was calling for heat or cooling at the current time.

Ok so I tried this:

items file:
String settings_FanMode “fanMode [%s]” (gSettings) { ecobee="=[314xxxxxx9838#settings.desiredFanMode]" }

sitemap:
Switch item=settings_FanMode label=“Fan Mode” mappings=[auto=Auto, on=On]

Here is the error:
2015-09-10 13:06:06.987 DEBUG o.o.b.e.internal.EcobeeBinding[:510]- About to set property ‘settings.desiredFanMode’ to ‘on’
2015-09-10 13:08:18.236 DEBUG o.o.b.e.internal.EcobeeBinding[:510]- About to set property ‘settings.desiredFanMode’ to ‘auto’
2015-09-10 13:08:45.803 DEBUG o.o.b.e.internal.EcobeeBinding[:510]- About to set property ‘settings.desiredFanMode’ to ‘on’

java.lang.NoSuchMethodException: Unknown property ‘desiredFanMode’ on class ‘class org.openhab.binding.ecobee.internal.messages.Thermostat$Settings’
at org.apache.commons.beanutils.PropertyUtilsBean.getSimpleProperty(PropertyUtilsBean.java:1322)
at org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(PropertyUtilsBean.java:770)
at org.apache.commons.beanutils.PropertyUtilsBean.getProperty(PropertyUtilsBean.java:846)
at org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:426)
at org.openhab.binding.ecobee.internal.messages.Thermostat.getProperty(Thermostat.java:114)
at org.openhab.binding.ecobee.internal.EcobeeBinding.getState(EcobeeBinding.java:381)
2015-09-10 13:09:01.167 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘settings_FanMode’ with newState ‘Uninitialized’
2015-09-10 13:09:01.167 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘settings_vent’ with newState ‘off’
2015-09-10 13:09:01.167 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘runtime_desiredFanMode’ with newState ‘auto’

The wiki page shows which properties are read-only or read-write in the examples section where you have either “<” or “=” in the binding config string. All the runtime.* properties are read-only. The source information is the API documentation. This is why

=[314xxxxxx9838#runtime.desiredFanMode]

didn’t work – it’s only for reporting what the desired fan mode currently is.

Here is a recent discussion on setting the fan mode at the API level, and there are binding-level equivalents, since the binding is just “translating” the API for use in openHAB.

To summarize what this would look like in openHAB, you want to use the fanMinOnTime to toggle between On and Auto modes.

your.items:

Number settings_fanMinOnTime "fanMinOnTime [%d]" { ecobee="=[123456789012#settings.fanMinOnTime]" }

your.sitemap:

Switch item=settings_fanMinOnTime label="Fan Mode [%s]" mappings=[60=on,0=auto]

This assumes that the current program or hold has fan mode set to Auto. I’ve not tested the above example but it should work.

It’s not working. First off I did have to change the mappings to mappings=[60=on,0=auto], no big deal I figured that out right away. Anyway I also added in the Switch settings_fanControlRequired item to see if that helped.

Here are some log entries for you to look at:

2015-09-10 14:30:11.301 DEBUG o.o.b.e.internal.EcobeeBinding[:510]- About to set property ‘settings.fanMinOnTime’ to ‘0’
2015-09-10 14:30:15.813 DEBUG o.o.b.e.internal.EcobeeBinding[:510]- About to set property ‘settings.fanMinOnTime’ to ‘60’
2015-09-10 14:30:23.805 DEBUG o.o.b.e.internal.EcobeeBinding[:510]- About to set property ‘settings.fanControlRequired’ to ‘OFF’
2015-09-10 14:30:27.605 DEBUG o.o.b.e.internal.EcobeeBinding[:510]- About to set property ‘settings.fanControlRequired’ to ‘ON’
2015-09-10 14:33:01.970 DEBUG o.o.b.e.internal.EcobeeBinding[:250]- Requesting summaries for Selection[selectionType=thermostats,selectionMatch=314704909838,includeRuntime=true,includeExtendedRuntime=,includeElectricity=,includeSettings=true,includeLocation=,includeProgram=,includeEvents=,includeDevice=,includeTechnician=,includeUtility=,includeManagement=,includeAlerts=,includeWeather=,includeHouseDetails=,includeOemCfg=,includeEquipmentStatus=,includeNotificationSettings=,includePrivacy=,includeVersion=,includeSensors=true]
2015-09-10 14:33:02.207 DEBUG o.o.b.e.internal.EcobeeBinding[:268]- Retrieved summaries for 1 thermostat(s).
2015-09-10 14:33:02.207 DEBUG o.o.b.e.internal.EcobeeBinding[:316]- Requesting full retrieval for 1 thermostat(s).
2015-09-10 14:33:02.358 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘settings_fanMinOnTime’ with newState ‘60’
2015-09-10 14:33:02.358 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘LivingRoom_Humidity’ with newState ‘40’
2015-09-10 14:33:02.358 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘thermostatTime’ with newState ‘2015-09-10T14:33:02’
2015-09-10 14:33:02.358 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘settings_hvacMode’ with newState ‘off’
2015-09-10 14:33:02.358 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘GuestBedroomTemp’ with newState ‘74.1’
2015-09-10 14:33:02.359 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘MasterBedroomTemp’ with newState ‘74.1’
2015-09-10 14:33:02.359 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘Ecobee_Name’ with newState ‘21 Copley’
2015-09-10 14:33:02.359 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘settings_fanControlRequired’ with newState ‘ON’
2015-09-10 14:33:02.359 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘settings_vent’ with newState ‘off’
2015-09-10 14:33:02.359 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘runtime_desiredFanMode’ with newState ‘auto’
2015-09-10 14:33:02.365 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘FrontRoomTemp’ with newState ‘76.1’
2015-09-10 14:33:02.366 DEBUG o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName ‘Ecobee_Temperature’ with newState ‘74.4’
2015-09-10 14:36:02.367 DEBUG o.o.b.e.internal.EcobeeBinding[:250]- Requesting summaries for Selection

The fan mode in your current program or hold is auto, correct? Your log shows that your setting fanMinOnTime succeeded over the API. From the Ecobee discussion link above:

Not sure what else to suggest at the moment.

Yes the fan mode has been set to Auto throughout my testing. I’m actually in the basement so I can hear the system from where I’m typing. I just looked at the physical thermostat and interestingly enough it shows that the fan is set to run 60min/hr so the call to the API did work and make it to the thermostat.

Another point is the selections that are allowed when programming from the thermostat are 0 through 55 min at 5 min increments. You can’t set it at 60 min at the thermostat but it does show 60 as the setting if I do it through openhab via the ecobee API. I did tweak the openhab sitemap to change it from 60 to 55 just in case that was the problem. Bottom line it looks like it may be an issue at the ecobee end, as the fan is not running for 55 min out of the hour as far as I can tell.

I see this in the log:

o.o.b.e.internal.EcobeeBinding[:346]- readEcobee: Updating itemName 'settings_hvacMode' with newState 'off'

which means no equipment will run. The hvacMode should be in a different state, depending on your system.

I thought I had tried it in all possible configurations. That said it now appears to be working the way I would expect it to. The fan does come on when I set the settings_fanMinOnTime to 60 and off again when I set it to 0. It may have had something to do with the thermostat being is some sort of hold state. Just before it started working I noticed the on hold message, just under the temperature display. I cancelled it, and a message appeared about resuming program. Maybe the fanMinOnTime only applies when it isn’t on hold of some kind. Thanks for the help, I’ll keep you posted if anything else crops up. I do note as you pointed out that this does not change the Fan ON/AUTO setting. It just kind of forces the fan on by using the fanMinOnTime and setting it to 60min during a given hours time, which in a practical sense keeps the fan running. Hopefully as the ecobee guys said it will be addressed in a future API release.

P.S. I would like to see if there is a way to determine if the thermostat is calling for heat or cool, I’ll work on that and if I can’t come up with a solution I’ll start a separate topic about it.

Search for equipmentStatus and read the API doc for its possible values.

Just for your info. Setting the fanMinOnTime to 60 does turn on the fan even if the hvacMode is OFF. Then setting it back to zero turns it back off.

Ah, good to know! I had misread the information on the support site.

I’m trying to achieve the same thing as the OP wanted to do, and while using fanMinTime does change the setting (visible in the portal), as far as I could see it doesn’t change the fan to “on” auto, and in hvacMode Off the fan never came on (maybe I didn’t wait long enough). The UI (auto/on) certainly didn’t change when using fanMinOnTime (and in OH, the DesiredFanMode did not reflect a change from auto to on or visa versa).

Either way, I’m not looking to change the min fan setting, but rather turn the fan from Auto/On immediately. Looking at the ecobee API this is possible via setHold, illustrated with the following example:

https://www.ecobee.com/home/developer/api/examples/ex5.shtml

{ “selection”: { “selectionType”:“registered”, “selectionMatch”:"" }, “functions”: [ { “type”:“setHold”, “params”:{ “holdType”:“nextTransition”, “heatHoldTemp”:707, “coolHoldTemp”:717, “fan”: “on” } } ]}

I’ve confirmed that this works (turns the fan on immediately, and back to auto when program is resumed) outside of OH using curl.

Does the action binding function ecoebeeSetHold() support this (as far as I can tell from the code it doesn’t) and/or are there any plans to add support for the “fan” param for turning the fan from auto/on rather than using minFanOnTime?

Thanks.

I believe that since your HVAC mode was Off, that the fanMinOnTime value did not make a difference. If your HVAC mode were some other setting than Off, perhaps with setpoint(s) that won’t cause the heating or cooling equipment to turn on, then the fan should go on and off immediately by setting the fanMinOnTime to 60/0, respectively. In my opinion, this is better control than having to set a hold that may conflict with other holds you would want to use.

Please investigate this, as you are correct that the ecobeeSetHold action does not currently allow those additional JSON fields from the Event object. I was hoping to avoid exposing this class at the action method interface, so if my suggestion above returns the number of real-world use cases back to a list of zero length, then we can avoid exposing that class in action calls (or worse, adding lots of optional parameters for each possible additional field).

Please let me know if my suggestion works.

Actually, I misspoke when I about the fan not turning on - quite possibly I was using a smaller value than 60 as “on” last night. Trying again, it does actually turn on the fan immediately when setting the value to 60, and stops when setting it back to 0 - even when the HVAC system is off.

What I reported about the fan mode (Desired Fan Mode in OH, and the “Fan Auto/Off” on the portal and unit) remains true - it does not change via this method of turning the fan on (which is probably obvious since that’s not being modified).

I’ve largely developed my ecobee items, rules & sitemap to mirror (as closely as possible) the UI of the portal/unit, hence why I was looking into doing this via ecobeeSetHold() (as when using the hold method and HVAC is off, the unit shows “fan on and holding”, where as using fanMinOnTime doesn’t show much of an explanation on the unit of why the fan is on).

But with your explanation I can understand why you’d prefer to keep the interface to ecobeeSetHold() simple - I wasn’t sure if it was an oversight, or a design decision (clearly it was the latter). The minFanOnTime does actually give me a way to turn the fan on and off, and if I want to literally change it like on the unit, I think I can write an external script to do so and surface that from OH.

Thanks for the response!

Thanks Mark for your thorough reply.

Well, to me this means that the action bundle ought to support your use case, so an additional ecobeeSetHold method signature ought to be added that allows all possible event fields in the setHold function. I don’t want users to have to rely on external scripts to work around missing functionality!

I will figure out a sensible way to allow all possible fields for the Ecobee setHold function and provide a replacement action bundle. Would you be willing to test it?

Sounds great, and yes I’d absolutely be up for testing the bundle changes.

OK! Here is a set of files to download:

The binding and action JARs have to be installed together and other versions of the JAR removed from the addons folder.

The example items, rules and sitemap files at the link show the changes, but to summarize I added a new method signature:

    @ActionDoc(text = "The set hold function sets the thermostat into a hold with the specified event parameters.")
    public static boolean ecobeeSetHold(
            @ParamDoc(name = "selection", text = "The thermostat selection to set hold.") String selection,
            @ParamDoc(name = "params", text = "The map of hold parameters.") Map<String, Object> params,
            @ParamDoc(name = "holdType", text = "(opt) The hold duration type. Valid values: dateTime, nextTransition, indefinite, holdHours.") String holdType,
            @ParamDoc(name = "holdHours", text = "(opt) The number of hours to hold for, used and required if holdType='holdHours'.") Number holdHours,
            @ParamDoc(name = "startDateTime", text = "(opt) The start date in thermostat time.") Date startDateTime,
            @ParamDoc(name = "endDateTime", text = "(opt) The end date in thermostat time.") Date endDateTime) {

The params parameter can be any of the fields of the SetHold function, or possibly settable Event object fields:

isOccupied
isCoolOff
isHeatOff
coolHoldTemp
heatHoldTemp
fan
vent
ventilatorMinOnTime
isOptional
isTemperatureRelative
coolRelativeTemp
heatRelativeTemp
isTemperatureAbsolute
fanMinOnTime
holdClimateRef

For example, this rule will set an indefinite fan hold:

rule FanHold
when
  Item desiredFan received command
then
  logInfo("FanHold", "Setting fan hold to " + receivedCommand.toString)
  val params = newLinkedHashMap(
    'isTemperatureAbsolute'-> false,
    'isTemperatureRelative' -> false,
    'isCoolOff' -> true,
    'isHeatOff' -> true,
    'coolHoldTemp' -> 90,
    'heatHoldTemp' -> 50,
    'fan' -> receivedCommand.toString)
  ecobeeSetHold("987654321098", params, null, null, null, null)
end

This is great, thanks!

I can confirm parameter for the fan via ecobeeSetHold(), works great, and it seems that my other rules for setting holds are still working as intended also (once changing the function arguments in my rules appropriately).

I’ll do some more thorough testing on the weekend and will report back if I find any problems, but thus far this looks like it’s working great.

Thanks again!

1 Like

Glad it works, Mark! Here is the pull request, for reference.