Item last update timestamp

[Alexander Meyer]

Hi,

is there any way I can find out the time an item was last updated? I
have quite a few battery powered sensors around the house and I'd like
openHAB to notify me if any of them has seized to send updates.

Regards,

Alexander

[Greg]

I have this on a few of my items.

add to items for each item:

DateTime sensor1ChangedTime   "Sensor 1 Changed at [%1$tA, %1$td.%1$tm.%1$tY %1$tT]"

then either add or create rule

rule "Sensor 1 Changed"

when

  Item sensor1 changed

then

  postUpdate(sensor1ChangedTime, new DateTimeType())

end

I then have a rule at a cron time that checks the time difference between now and the sensor1ChangedTime and if over a certain number of millis, then notify me.

[Alexander Meyer]

I think, I also found a way to do it:

var Timer balcony_timer

rule "Balcony Timer"
when
Item balcony_voltage_bat received update
then
if (balcony_timer) {
if(balcony_timer!=null) {
balcony_timer.cancel
balcony_timer = null
}
}
balcony_timer = createTimer(now.plusSeconds(120)) [|
logError("balcony_timer", "NO UPDATE FOR 2 MINUTES!")
sendXMPP("user@server", "NO UPDATE FOR 2 MINUTES!")
]
end

Cheers,

Alexander

> --
> You received this message because you are subscribed to the Google Groups
> "openhab" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openhab+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at http://groups.google.com/group/openhab.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Alexander Meyer, Team Lead System Administration

T +49 40 24828 711

Commerce Plus GmbH | SinnerSchrader Group
Schäferkampsallee 16, 20357 Hamburg, Germany

Amtsgericht Hamburg HRB-Nr. 109687
Geschäftsführer: Moritz Koch, Nicole Zarbock

Büros: Hamburg, Hannover, Berlin

http://www.commerce-plus.com

ACHTUNG Neuer Firmenname: Commerce Plus (ehemals spot-media)

[Ben Jones]

Greg - could you post the rule that checks the time difference (via the cron time trigger)?

[Greg]

Sure

rule "Check Sensors"

when

Time cron "0 0/5 * * * ?"  // check every 5 minutes

then

                // sensor 1 check

var DateTimeType sensor1DT = sensor1ChangedTime.state as DateTimeType

if ((new DateTimeType().calendar.timeInMillis - sensor1DT.calendar.timeInMillis) > 300000){  // 5 minutes

                     // notifyme somehow

               }

end

Just repeat for every sensor you want to check.  Just note, this will keep notifying you every 5 minutes if the device is down.  You may want to add a check so you only get notified once.

Greg

[Ben Jones]

Thanks Greg - I was struggling to get my head around how to handle DateTimeTypes with the joda now() stuff. It is now a bit clearer how to handle these DateTime state objects.

I guess using Alexanders method of setting timers to detect inactivity saves having to worry about the repeated alerts, so I might try that method for now.

[Greg]

Yes, I guess his is simpler that way.

I use the items because I have a few events that happen rarely and I like to see when they happen.  It also enables you to persist them so you can get historical timestamps for events.

[Ben Jones]

For sure - I can definitely see the merits in your method as well.

 

[Alexander Meyer]

I'd go with Greg's method, simply because there seems to be a problem with mine:

When I inhibit updates from the sensor an (read "one, and one only")
notification is sent out 2 minutes after the last update, so far so
good.

But when the sensor messages resume, I get a whole bunch of
notifications, roughly every minute, which is the frequency the sensor
updates its item.

I have no idea why it behaves this way, but Greg's method seems to
work fine (I don't mind getting a notification every fine minutes
while a sensor is down, I'll have to go and fix it, after all), and
has the added advantage of an item I can display or otherwise play
around with.

Cheers,

Alexander

[Greg]

Would it be worth requesting a timestamp method for items?

Greg

[Chris Jackson]

Yes - I think this should be part of openHAB. We have item.state, we should have item.lastupdate (or something similar).

 

Chris

[Alexander Meyer]

+1

[Ben Jones]

I think the concept of 'last updated' was designed to be handled by the persistence model. Perhaps that is another avenue to try for this?

[Chris Jackson]

I don't think it can easily be handled in the persistence model. The persistence model doesn't get called when there is an update - only when there's a change, hence the PersistenceExtensions class has a "last updated" method, but not a "last changed" method.

 

Personally, I'd like to put it in the persistence model since then it can be restored on startup, but I think it just doesn't work unless there's a significant change to the model.

 

Chris

[Ben Jones]

Interesting - I didn't realise the persistence model didn't handle 'update only'. I agree, it probably should, to be consistent with the rest of theitem framework.

[Chris Jackson]

I'm reasonably sure what I said is correct. Certainly the persistence services themselves are only called when there's an update - maybe something in the persistence core could be a bit smarter, but the basic problem then becomes that you have to do one of the following -:

1) Store ALL updates of the persisted item - this increases the database a LOT.

2) Separately store another table that holds the last update time. This could be done in the mysql store at least, but there would have to be another method to do this.

 

In the persistence models, you have the "all changes" strategy - if there was an "all updates", this might do #1, but I don't think it would be a recommended method...

 

Chris

 

[Ben Jones]

Yes I see your point. So perhaps, as you suggested, extending the State object to have a built in LastChanged and LastUpdated variable would be easiest and cleanest?

[Chris Jackson]

I think so - it could also (one day) be linked to the persistence system so that you get the last update time restored on startup, but I suspect that this is a bigger job....

 

[Ben Jones]

Yeah just looking at the core code - looks like a pretty simple change to the org.openhab.core.items.Item interface and the org.openhab.core.items.GenericItem abstract class to handle this. In the setState() method we just set the two updated/changed datetime variables and provide getters (via the Item interface).

[Chris Jackson]

Good man - well volunteered :)
 

 

[Greg]

+1

[Ben Jones]

Ok - I have created a pull request for this so we will wait and see what Kai/Thomas think.

https://github.com/openhab/openhab/pull/34

[Chris Jackson]

Great - thanks Ben.
 

 

[Kai Kreuzer]

Hi guys,

Sorry to jump into your discussion so late, but I have just returned from my holidays and this issue required a bit browsing through the code before adding my view on things :-)

To make it short: I do not really like the idea to add these additional properties. Let me try to explain why:

An item (including its state) is so far not bound in "time & space" and this is on purpose - it simply describes a situation without fixing it at a certain point in time. Technically, there is nothing that prevents you to have multiple GenericItem instances floating around (maybe even across different systems if you send them around using MQTT) and you couldn't tell, which one is actually the "right" one.

Everything related to certain points in time is done through the persistence services - there is actually an "everyUpdate" strategy and not only an "everyChange" - so it should be perfectly possible to persist every update even without value changes. If you use a db like rrd4j, persisting all updates wouldn't even mean growing databases. I was actually also thinking about a very simple persistence service, which always only stores the very lastest value, so that it can be used for restoreOnStartup (or to determine the last update :-)). So in the persistence framework, there is the HistoricItem interface, which has a timestamp. The problem for your use case might only be that historicState currently returns a State and not an HistoricItem - but this could be possibly changed.

Another possible solution without having to use persistence services might be to extend the ItemRegistry by a new method getLastUpdate(Item) - this could also be offered as an extension in rules, so that it could also be used as item.lastUpdate; the difference to your suggestion is that you really ask the registry and not the item itself.

Although both suggestions seem to be more complicated than your suggested change, I feel that they would impose less changes in the architecture and less unexpected consequences.

Best regards,

Kai

-- 

[Ben Jones]

Very valid and fair points Kai. I like the idea of the simplified 'last updated' persistence strategy, assuming we could get the time stamp as well. 

You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/3qCESoIBeEU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[Eugene Schava]

Sorry for bringing up old thread

I've created an action returning timestamp when item received update last time. I think it could be interesting for readers of this discussion

Method lastUpdated(item) returns time (in unix millis) when that item received update last time

Please note that on the first call it always returns 0 and only subscribes for update events for the item. So it's better to call it in Startup rule

Вівторок, 8 жовтня 2013 р. 19:15:38 UTC+3 користувач Greg написав:

[Pål Kristensen]

Thanks for sharing your custom action, it works perfectly. Will the action ever become part of the official OpenHAB repository, and nightly builds (snapshots)? Will you continue to post updates for new releases of OpenHAB, like the current 1.6.1 release?

Regards

[Eugene Schava]

Hope it should also work for 1.6.1 without any changes

I didn't propose it for adding to the main source tree. Instead just committed it to my clone of openhab 1.5.1 branch at https://github.com/eschava/openhab/tree/1.5.1

If you have any issues with this action you can write to this thread and I'll do my best to fix it

Понеділок, 8 грудня 2014 р. 22:21:14 UTC+2 користувач Pål Kristensen написав:

Thanks for sharing your custom action, it works perfectly. Will the action ever become part of the official OpenHAB repository, and nightly builds (snapshots)? Will you continue to post updates for new releases of OpenHAB, like the current 1.6.1 release?

Regards

kl. 17:28:54 UTC+2 fredag 26. september 2014 skrev Eugene Schava følgende:

[Pål Kristensen]

Thanks!

I tired the action on 1.6.1 and it works for approx 30 minutes, the it stops updating (same value returned on every run). There are no error messages in the log file.

Regards
Pål

[Eugene Schava]

It's pretty strange

Could you please prepare test configuration reproducing your issue?

Вівторок, 9 грудня 2014 р. 19:03:11 UTC+2 користувач Pål Kristensen написав: