Added runningEvent properties to Ecobee binding

One omission from the currently released Ecobee binding is an easy way to see what the currently running event is. The existing binding lets you reference the list of events that are currently known, indexing into the list of events. To see the values for the first event in the list, if any:

String firstEvent_type "First event type [%s]" { ecobee="<[123456789012#events[0].type]" }
String firstEvent_name "First event name [%s]" { ecobee="<[123456789012#events[0].name]" }
String firstEvent_climate "First event climate [%s]" { ecobee="<[123456789012#events[0].holdClimateRef]" }

The problem is that events[0] may not be the currently running event. You are probably more interested in the currently running event, as this overrides the regular weekly program. With runningEvent.* properties, the binding finds the currently running event, if any, and uses it as runningEvent.

String runningEvent_type "Running event type [%s]" { ecobee="<[123456789012#runningEvent.type]" }
String runningEvent_name "Running event name [%s]"  { ecobee="<[]" }
String runningEvent_climate "Running event climate [%s]"  { ecobee="<[123456789012#runningEvent.holdClimateRef]" }

The whole range of values under runningEvent and events[X] can be found here.

So if you or someone has set a hold that deviates from the regular program, the above items will tell you the type, name and holdClimateRef (if any), for the currently running event. With automation, you could trigger a rule based on these values changing, and issue the action call ecobeeResumeProgram to clear the hold (as in the case where an unauthorized person changed your thermostat settings).

The runningEvent.* choices will appear in the next CloudBees build and openHAB 1.8.

Please post feedback here!

I can’t seem to get any of the event working
I am running OH 1.8


String runningEvent_name “Running event name [%s]” (gEvents) { ecobee="<[]" }

Error log:

2016-12-26 17:54:06.320 TRACE o.o.b.e.internal.EcobeeBinding[:265]- Querying Ecobee API for instance DEFAULT_USER
2016-12-26 17:54:06.321 DEBUG o.o.b.e.internal.EcobeeBinding[:304]- Requesting summaries for Selection[selectionType=thermostats,selectionMatch=Xx_MyEcobeeID_xX,includeRuntime=true,includeExtendedRuntime=,includeElectricity=,includeSettings=,includeLocation=,includeProgram=true,includeEvents=true,includeDevice=,includeTechnician=,includeUtility=,includeManagement=,includeAlerts=,includeWeather=,includeHouseDetails=,includeOemCfg=,includeEquipmentStatus=true,includeNotificationSettings=,includePrivacy=,includeVersion=,includeSensors=true]
2016-12-26 17:54:06.527 DEBUG o.o.b.e.internal.EcobeeBinding[:323]- Retrieved summaries for 1 thermostat(s).
2016-12-26 17:54:06.528 DEBUG o.o.b.e.internal.EcobeeBinding[:369]- Requesting full retrieval for 1 thermostat(s).
2016-12-26 17:54:06.592 DEBUG o.o.b.e.internal.EcobeeBinding[:437]- Unable to get state from thermostat
org.apache.commons.beanutils.NestedNullException: Null property value for ‘’ on bean class 'class org.openhab.binding.ecobee.messages.Thermostat’
at org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(
at org.apache.commons.beanutils.PropertyUtilsBean.getProperty(
at org.apache.commons.beanutils.PropertyUtils.getProperty(
at org.openhab.binding.ecobee.messages.Thermostat.getProperty(
at org.openhab.binding.ecobee.internal.EcobeeBinding.getState(
at org.openhab.binding.ecobee.internal.EcobeeBinding.readEcobee(
2016-12-26 17:54:06.592 DEBUG o.o.b.e.internal.EcobeeBinding[:399]- readEcobee: Updating itemName ‘runningEvent_name’ with newState ‘Uninitialized’

When I try firstEvent_name I get index out of bounds.

Any idea what I’m doing wrong?

I don’t see any problem in that log excerpt. You are getting the stack trace because the logging is set to DEBUG or TRACE. I suspect your thermostat wasn’t running an event (a hold event for example) at that point. If you override the program with a temperature hold, does the item get a state update after the next poll?

Your right, i thought i should always have an event but was wrong.
setting a hold event populates properly. thanks

1 Like