Use this temperature sensor if recently active, otherwise use that one

[asheville]

Here's the pseudologic that I'm trying to do

Device: Virtual Temperature

.. If Front Porch temp sensor has updated in the last 2 hours, use that value for Virtual Temperature
.. If Deck temp sensor has updated in the last 2 hours, use that value for Virtual Temperature
.. Otherwise - use the OpenWeatherMap data for temperature for Virtual Temperature

Basic idea -- I just discovered that my Porch/Deck temperature devices aren't working in this sub-10 degree weather (highly unusual)

BUT -- am also discovering that OpenWeatherMap is reporting, sometimes, highly inaccurate readings for my area (microclimate) -- like now, it says it's 21 degrees but it's really 9

At this moment -- none of my outdoor sensor have reported in the last 24 hours, and OpenWeatherMap data is inaccurate. I may have an ultimate fall-back to a window sensor that's usually about 30+/- degrees off in freezing weather (like indoors it's 66 degrees, the window contact sensor reads 40 -- it's right on a cold windowsill -- it's a hack, highly inaccurate, but better than anything else -- it could be the final-final-final fall-back)

Basically -- trying to have a rule that does "use the best you can with what you've got" temperature

What I can't find is how to "set a variable" to the "last update time" of a sensor -- I can put that info in a dashboard, but I can't find where to get that data out of the Rule Manager

Update: Found an acceptable "hack"

[brad5]

@asheville

What I can't find is how to "set a variable" to the "last update time" of a sensor -

I wonder if there's an alternate approach that used a couple of variables instead. The rule would trigger any time there was a change in temperature to either sensor and it would update a variable with the current time and the current temperature. That variable essentially becomes the last update time of the sensor and can then be used in comparisons.

[brad5]

Kind of like this...

[asheville]

@Brad5 -- hey, that's one way to do it. I'd have to create discrete rules -- one for each sensor as a specific trigger to track the time-of-change for that last sensor.

Now, technically, that's not "lastupdated" -- eg, same temp, reported back-to-back -- but it's close enough.

It's a hack -- but doable.

[brad5]

Yeah it isn't elegant but hey... it should work. You might be able to get away with one rule if you don't care which of your two sensors is used.

[asheville]

@brad5

Yeah it isn't elegant but hey... it should work. You might be able to get away with one rule if you don't care which of your two sensors is used.

Yea, I do care. One might have not updated in 5 days, says 75 degrees, but the one that has updated says 30. (other use-case is battery died, etc)

So more than one rule. Ugly. Gotta decide now whether I want another set of rules (in my ever growing list!)

[brad5]

There might be a more elegant way of doing it... maybe wait and see if someone else has a better idea?

[asheville]

@brad5

There might be a more elegant way of doing it... maybe wait and see if someone else has a better idea?

Yup -- got time to ponder on it. It is interesting that "LastUpdated" is exposed to Dashboards, but not - from what I can find - in RM5. Gotta be a technical reason.

[brad5]

Maybe it's a feature that one can request? @bravenel would know.

[asheville]

@brad5

Maybe it's a feature that one can request? @bravenel would know.

Did also find this thread / feature request

Please Expose %lastActivity% Device Property

But with respect to the OP's request, where a notification is going to be sent, that's going to happen in response to an event on this device, so that will be it's Last Activity, as @FriedCheese2006 points out. Both RM and Notifier only send notifications for the last triggering device, not any other device. So there will only be milliseconds of difference between %time% and %lastActivity%, and hence this as a feature makes no sense. In a custom app there are certainly situations where look…

[brad5]

Yeah though your use case is a bit different... I suspect maybe it's easy enough to do with variables?

[asheville]

@brad5

Yeah though your use case is a bit different... I suspect maybe it's easy enough to do with variables?

There's also the "Averaging Plus" app -- but I don't think it skips-over devices not reporting -- may play with that and/or ask the developer how it works. An "average" of just the functional devices may work.

Ish. Doesn't help with the OpenWeatherMap being wonky. LastUpdate for working sensors is a better solution.

[asheville]

@asheville

There's also the "Averaging Plus" app -- but I don't think it skips-over devices not reporting

HooHoo -- yes "Averaging Plus" will. So this may be closer. Not exactly my "use this first, use this second, use this third" -- but an average of only things that are alive, is closer

[asheville]

AhHa! -- one of my projects this weekend was to get Blink cameras integrated. Done.

The Blink driver also pulls in temperature from those cams that support it. I've got a couple of outside cameras, and a few are offline (need new batteries). That was a good use-case for this kind of a rule. And it WORKS!

Basically -- as every temperature report comes in -- (from any working outside device that can report temperature) -- update a variable with that latest reading. As long as ONE of the devices reports, I get a current temperature to use. A hack, heck yea. But closes the gap on getting an outside temperature from "sources that are alive"

Takes exploitation of %value% to set a variable