Charting a LastUpdate DateTime value

  • Platform information:
    • Hardware: lepotato
    • openHAB version: 4.0.3
  • Issue of the topic:

Hi everyone, I have finally managed to create a rule that will update an item called “DFCtrl_last” which is a DateTime value.

label: DFCtrl Last Update
type: DateTime
category: time
  - DFCtrl
groupType: None
function: null
  - Status
  - Timestamp

Now that all works good, but I wanted to have a quick look at a chart that would show me a short horizontal movement instead of a diagonal linear one.

So I simply created a graph, added a time series and added the _last item. The chart is empty in run mode.

So I am assuming the chart doesnt know how to plot a DateTime value type. So I am trying to look for modifying the chart to not display the datetime but rather a calculated expression that returns “seconds from now”, like:

value: =now()-value

For the life of me I cannot find any post that has dealt with something similar.

Am I completely off track here or what am I supposed to do?

Again to reiterate: I just wanted to make something (a chart) that showed me the “outages” of lastupdate not being updated due to connectivity etc.

Many thanks in advance!

As far as I understand, you can’t chat a date time. I’m not even sure what that would look like. what’s the y-axis supposed to be?

Create a rule or use Threshold Alert from the marketplace to update a Switch Item to OFF when it’s offline. Chart the Switch Item.


thanks for your answer! Before diving into your reply I think I need to expand a little here:

When I started using openhab a couple months ago, I started with tracking some wireless temperature sensing devices. In my naive thinking as an absolute newbie to the project I simply assumed the following would occur when there was a communication problem with the device (poor signal, no battery, MQTT down, etc…):

(chart 1)

but instead what happened was this:

(chart 2)

So I was a little surprised, as OK this zig zagging on a multi-hour basis can be spotted but this did not appear like the expected way of handling this in my view.

So then I started googling and found about an expire binding, that seemed to do what I initially had in mind: If I know the device usually pings me in 10 secs intervals, put a 1 min expiration timer that nulls the values after that time signifiying that there seems to be a problem.

But this seems to have 2 problems:
a) in the charting this does not appear to make any difference. In my experience the chart above would look exactly the same as chart 2, as the null values are simply skipped and the last 2 known values are “glued” together by simply drawing a linear connection between the two.
b) the expire binding seems to have been deprecated because I cannot find it in OH4 documentation. Instead the only things I can find is to clone every item with a +“_last” sibling and record the last Update into this item whenever there is an update and then additionally create a rule that checks if the +“_last” value is too old and then setting the original item to NULL.

So here I am wondering two things:
a) Am I totally misunderstanding OH4 and I just need to put a checkbox somewhere and everything works as I would assume it works?
b) If not, I really wonder why that decision to leave out a handling of an “offline/expired” state was made? Shouldn’t that appeal to a large audience?

OK so now with this questions out and maybe someone is kind enough to help me get on track, I still would like to answer @rlkoshak:

Yea charting a datetime doesn’t really make sense, that’s why I suggested graphing an expression like “now().TotalSeconds-value.TotalSeconds” instead. This should like this:

(chart 3)

and in the case of outages would look like this:

(chart 4)

(sorry for my crude drawing)

and lastly, one could probably overlay my first chart with @rlkoshak’s solution with just another on/off item with a markArea like this:

(chart 5)

to show the offline parts.

So I am really curious to the replies to this! Many thanks in advance!

EDIT: bleh sorry it seems like I can only upload one picture. So all charts combined here:

NULL and UNDEF Item states do not get saved to persistence. If you want to use Expire you need to set the Expire state to what ever value you want to chart (zero?).

Or, if the built in charting in OH doesn’t have the features you need, look to use something like Grafana for charting instead.

It’s not deprecated. I’m not sure it ever was fully documented well.

The Threshold Alert rule template let’s you set a condition (e.g. hasn’t changed in a given amount of time) and if the Item meets it will call a rule you write where you you can take some action.

No, charting in OH is relatively basic. OH is a home automation platform, but a data analysis platform. Charting doesn’t have the full set of features you might be used to.

Expire is and always be supported by OH unless and until something objectively better comes along. However, pay attention to above. Expire defaults to expiring to NULL and NULL doesn’t get saved to the database and won’t get charted.

Sorry was on the road.

Right, OK!

Hrm, alright. Only thing I can find is this: Expire - Bindings | openHAB
Has anything changed from this to OH4? Or is there a more recent version (v2+?) of the binding? How are bindings assigned to items?

Thanks for any pointers.

OK, I understood it more as a architectural decision, as there currently doesn’t seem to be a “device is offline/not reporting” handling neither in logic, nor in persistance nor in charting out of the box. I mean I don’t want to complain, just want to understand that this is currently by design not because of my lack of knowledge/experience.

Alright, one final question:

I currently have a Thing that is an arduino which reports a JSON packed state of multiple things it monitors. This thing has all the data dissected via channels and linked to items.

If the arduino itself is offline, I assumed that all the items derived from the channel/links would be marked as offline as well, etc.

As discussed in this thread, this is not the case. But is there something that helps here in the connection of the thing to the items?

Or should I go ahead with my approeach outlined above for the chart and simply overlay a red 50% opaque red area when the device is offline?

Again my thanks for the help so far!

As of OH 3, Expire is not a binding. It’s a built in function.

And bindings are not ever assigned to Items. Items support metadata (the stuff between { }) in a .items file. That metadata can be used to link an Item to a Channel, or it can be used to configure the Item’s behavior (Autoupdate, Expire) or MainUI (State Description, Default X Widgets), 3rd party service integration (Google Assistant, Alexa integration), and you can put your own stuff into Item metadata.

As for Expire, it follows the same format for the Item metadata as was used in 2.5 to configure the binding. In OH 3 a number of new features were added:

  • change whether Expire updates or commands the Item
  • option to ignore state updates that do not result in a change
  • option to ignore commands

I don’t see it documented anywhere in the docs. It probably should be a section in Items. It’s not been a big deal until now I think because it’s self documenting in the UI.

One thing you can do to learn the text file syntax of a Thing or Item Metadata in a text file is to configure an example in the UI, click on the Code tab, and translate the YAML you find there to the custom XText syntax used in .items or .things files.

For example, for metadata, the overall syntax is (see Items | openHAB):

<namespace>="<value>"[<config1>="<value>", <config2>="<value>", ...]

So given:

the metadata would be

expire="1h2m3s,command=ON"[ignoreStateUpdates="true", ignoreCommands="true"]

The extent to which a Binding is assigned to an Item, it’s done through a Channel Link.

It’s hard to make something out-of-the-box because what constitutes “offline/not reporting” can vary widely from technology to technology and from device to device.

But there are two rule templates on the marketplace that handle these use cases.

There is no such thing as an Item being OFFLINE.

You can set the Item to some value that indicates it’s offline (not UNDEF or NULL as those don’t get saved, or use periodic persistence strategy to repeat the last state every minute in the database. That will make the chart look more like a stair step than saw toothed. Or you can use Grafana which has more features on how to handle this case built in.


sorry for the delay.

thanks again for your replies!

That really helped clear up the confusion around the Expiration Timer and how it is supposed to work. This should really go to some documentation! I was completely clueless how this works and I couldnt find info! So thanks!

Also thanks for mentioning the Threshold Group Alert. Does this also work for a single item without descendants? I tried making it work but exactly which parts to be configured where still puzzle me a bit. It seems like the general config goes into the YAML configuration part of the Trigger part in the a rule, but the “group” itself has to be configured in the actual UI part of the config. Deviations from the config go to metadata of the items. At least this seems to be my understanding.

I keep wondering if everyone else is an expert in this and it’s just me finding it hard to get into this or if the documentation is severely lacking behind the progress of the project? (again not wanting to offend, i’m just trying to get into this project!)

Lastly. I followed the suggestions and made a rule that triggers on an update to an item (RSSI) [I couldn’t bring myself to use the trigger on all children, because that triggered multiple times on a single json update encompassing all items…]:

it does a postUpdate() and sends the timestamp to a _last item and also sends a ON to the an _online item. This in combination with the Auto-Expire setting to OFF after a minute works and I can finally integrate that into a graph as shown some posts up.

Then I found another thing that is configure vs. programming: there seems to be a channel link that has a update-timestamp profile and I thought I could remove the script (at least for the _last item). But again I seem to be lacking the knowledge how to do this.

I tried to do it on the RSSI channel but I cannot pick my TimeStamp Item (_last), it is not shown. Probably because of different units (number vs datetime).

Then I tried selecting “create new item”, this works, I can finally select the update-timestamp profile, but the resulting item is shown with “dBm” suffix from the RSSI channel config…

So either I am again understanding it wrong or it is not supposed to work like that.

Thanks again!

No, it needs a Group to work with. You can modify the rule to work with a single Item but it’s far less work noe and in the long run to just create a Group and add the Item to the Group. The added bonus is if you need this same behavior for another Item later on all you have to do is add the Item to the Group instead of creating a whole new instance of the Rule to work with the new Item.

The config gets saved to the Rule YAML but once the rule is instantiated that config section of the YAML is just informational. When the rule gets instantiated all the parameters get inserted into the rule and from that point the instantiated rule is a rule like any other. If you want to change it you either need to delete and recreated it from the template using different properties, or go and edit the actual source code manually.

When you look at the actual code for the rule template you’ll see stuff like {{group}}. That string gets replaced with the value of the property group when the rule is created. It’s literally a “find-and-replace” type operation. Once the rule is created, it’s static and for all intents and purposes separated from the template. It becomes a rule like any other.

I made this rule template flexible. When you create the rule you can set some default properties. However, sometimes you want to have a custom property for different Items. In my home for example, I want to get an alert when a door is left open for too long, but have a different amount of time before the alert for different doors. The garage door I want an alert after just a few minutes but the back door can be open most of the day before I want an alert.

Therefore, one can define metadata on each individual Item with the custom properties for that one Item.

That lets the one rule work for all my doors instead of needing to instantiate a separate rule for each door with a different alerting time.

But to change the way the rule is triggered you must edit the rule itself.

As in any project, open source or not, the documentation is uneven.

That’s how I detect when a sensor has gone offline and stopped reporting in my config. I choose an Item that changes frequently from among the many sensors of the device and alert when that one doesn’t change for a long time. There is no need to use all the Items from a single device.

I think that’s fixed in 4.1. But you can cheat. Create a Number Item, link it to the Channel with the timestamp profile applied. Then go back to the Item and change it back to a DateTime Item. That should work around the problem.