Ecobee3 control from VeraEdge UI7

[tbrock47]

Somewhat new to lua scripting, but I've accomplished quite a bit with my dimmers.
However, when I query ecobee motion sensor variables, I get multiple values back.

For Example:

Code: [Select]

print( luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1","Tripped",64) )
1 1517733365
So its returning '1' as expected stating that the sensor is tripped, however it also includes the LastTrip time as well.

If I query LastTrip, I actually get two times back. The last two trips I assume...

Code: [Select]

print( luup.variable_get("urn:micasaverde-com:serviceId:SecuritySensor1","LastTrip",64) )
1517733119 1517733365

Can anyone explain this behavior and explain how to extract each of those variables independently?

On a side note, the last trip times are unreliable. They don't appear to update unless the device is changing from a not tripped state to a tripped state (still testing this). It doesn't update the time stamp if the device is currently tripped. It only appears to maintain the tripped state as long as it sees motion and keeps the timestamp of when tripped last flipped from 0 to 1.

The only way to get more a more current status is by querying both tripped and LastUpdate and use them together. However, last update has the same problem of maintaining two values in one variable. I need to be able to separate the two.

Thanks in advance.

[watou]

The source code to the plugin here:

https://github.com/watou/vera-ecobee/blob/master/src/I_Ecobee1.xml#L809

shows that the LastTrip time is only coming from what is observed from using the API.  The API does not give a trigger time itself, only the current state.  I recall seeing Z-Wave PIR motion sensors do something similar, where they don't repeatedly report being tripped until their pre-set time of no motion has ended.  This is particularly good for battery-powered sensors.

In order to implement urn:micasaverde-com:serviceId:SecuritySensor1 for ecobee remote sensors, these device variables had to be provided with the closest possible values.  Ecobee's remote sensors don't have an API to report when the last motion occurred.

https://www.ecobee.com/home/developer/api/documentation/v1/objects/RemoteSensorCapability.shtml

For the openHAB plugin I wrote,  I gave an example of tracking last occupancy using ecobee remote sensors:

https://docs.openhab.org/addons/bindings/ecobee1/readme.html#tracking-last-occupancy

I hope this helps.

[tbrock47]

Thanks. I'll look over your links likely tomorrow and see if that helps my understanding.
I did figure out how to assign both results from the query to their own variable after some quick googling. (Embarrassingly simple)

I do have a question about the result order. Using lastupdate as an example, it provides the older of the two times in the first position. Can those be reordered in the plug-in or is that just how the API provides it? I say that because if someone only assigns that output to a single variable, they end up with the older of the two times rather than the more valid data of the two.

Sent from my LG-H918 using Tapatalk

[watou]

Using lastupdate as an example, it provides the older of the two times in the first position. Can those be reordered in the plug-in or is that just how the API provides it? I say that because if someone only assigns that output to a single variable, they end up with the older of the two times rather than the more valid data of the two.

The code is setting LastUpdate this way:

Code: [Select]

       ["LastUpdate"] = function(t) return tostring(toSeconds(t.runtime.lastModified)) end,

According to the ecobee API documentation, lastModified should be set in the format YYYY-MM-DD HH:MM:SS.  The toSeconds function takes that format and turns it into seconds:

Code: [Select]

    -- convert "2013-02-20 23:23:44" to number of seconds since 1/1/1970
    local function toSeconds(dateString, useLocal)
      useLocal = useLocal or false
      local year, month, day, hour, min, sec = string.match(dateString, "(%d+)%-(%d+)%-(%d+) (%d+):(%d+):(%d+)")
      local offset = useLocal and 0 or (os.time() - os.time(os.date("!*t")))
      return os.time{year=year, month=month, day=day, hour=hour, min=min, sec=sec} + offset
    end

If there is an error in the toSeconds function that is producing this result of two long numbers instead of the correct result, I can't see it (but maybe keener eyes can).

[cybrmage]

I do have a question about the result order. Using lastupdate as an example, it provides the older of the two times in the first

You need to (re)read the function documentation for the variable_get function...

The variable_get function returns two values... The first value is the content of the variable, the second value is the timestamp of the last modification of the variable...

It is a coincidence that the variable you are reading is itself a timestamp value, so the function IS returning two timestamp values, but the first timestamp value is the valid value you want... The second value is the timestamp for when the variable was updated...

IE: The ecobee API reads the status of the thermostat at 1517955300... That becomes the "lastupdate" value... The plugin polls the ecobee API at 1517955588 and stores the processed data... You then call the variable_get function... The first return value,  "1517955300", is the variable value - The second return value, "1517955588" is the time that the variable was last set.

[tbrock47]

Hmm... Interesting. I guess that is the first time I've noticed variable_get return more than one value.
Still have not had a chance to look over all of this yet. Maybe this weekend.

[fullmoonguru]

I had this problem and found a solution thanks to understanding that the cause is a bug in UI7. You can create a scene that works in AltUI like this:

Open AltUI

Create Scene

Header = Ecobee Heat On

Trigger = Outside Temp Goes Below 65

Action = SetModeTarget (under HVAC_UserOperatingMode1)

   NewModeTarget = HeatOn