Timestamps not rendering consistently in UI (3.0.2)

Add-ons UIs
1

Hi all,

I recently updated from 3.0.1 to 3.0.2, and am seeing some odd behavior for timestamps where they render inconsistently in the UI, and drop a formatting error in the log.

For context, I’m attempting to do health checks for my Z-Wave devices. In addition to the normal Items (motion, battery, etc), I also set up a virtual DateTime Item for each Thing called “[thing]_last_report” with a Link back to every Channel, using the “Timestamp on update” profile. The idea is that any activity on any Channel should update the DateTime in this Item, and I treat that as a sign that it’s alive.

Since updating to 3.0.2, some of the timestamp items are reporting “Err” on their detail page, but not on the main list. For example:

When I view the list of items, I see this:

openHAB 2021-05-04 16-56-20
openHAB 2021-05-04 16-56-20806×153 4.72 KB

When I create a script that echos the value of Kitchen_Door_last_report to the log like this, it works:
logInfo("testing",Kitchen_Door_last_report.state.toString)

events.log 2021-05-04 16-58-34
events.log 2021-05-04 16-58-34906×41 8.24 KB

But on the detail page, I get an err:

openHAB 2021-05-04 16-56-53
openHAB 2021-05-04 16-56-53859×403 16.1 KB

Here is the corresponding log message:
2021-05-04 17:12:45.086 [WARN ] [e.internal.SseItemStatesEventBuilder] - Exception while formatting value '2021-05-04T17:10:35.276127-0400' of item Kitchen_Door_last_report with format '%.0f %%': f != java.time.ZonedDateTime

However, the weird thing is that it doesn’t happen consistently. Some timestamps do render correctly on the detail page, for the same type of device and with the same config, and I can’t figure out the difference.

Has anybody else seen this? Happy to collect more detailed logging as well, if someone can suggest what would help.

Thank you!

2

I’m curious here, can you confirm that you have a single DateTime Item linked to several channels, each with a timestamp profile?
This used to be a recipe for disaster.
https://github.com/openhab/openhab-core/issues/1537#issuecomment-781684457

What pattern metadata does your Item have set?
(Although I suspect this format comes from the binding)

3

I genuinely chuckled at your comment about this being a recipe for disaster.

Yes, I can confirm that’s the case, it’s a single DateTime item linked to multiple channels. It seems to be working for some Things, and not for others. I’m not seeing the warring updates in the log in this case. However, I’m remembering that I tried this approach with some openweathermap items and ground my system to a complete halt. I removed the links and didn’t really look into it, but I suspect I hit what you did in that issue.

4

Sorry, I was editing while you were posting. Check your Item pattern metadata.

The zwave binding is capable of ‘suggesting’ a format over the channel, e.g. %.0f for a number. (Well, all bindings can but zwave is one of a few that does.)
Either that’s getting used for profile output, or it gets applied to your Item and overwrites your previous selection. Either way it doesn’t “fit” a datetime. We should be able to figure out which here.

5

Thanks, @rossko57.

In this case I don’t have any metadata configured for the DateTime item, or on any of the other linked Items. From the log message it looks like the timestamp is being generated correctly. I’m reasonably certain it was working properly in 3.0.1. Is it possible the problem is arising in how the UI is attempting to format it?

image
image719×711 33.2 KB

6

And that would be according to the ‘pattern’. Please check your Item’s JSON presentation using API Explorer.

7

Thanks for the pointer, I didn’t know about the API explorer.

Here’s what comes back:

{
  "link": "http://hub:8080/rest/items/Kitchen_Door_last_report",
  "state": "2021-05-04T17:10:35.276127-0400",
  "stateDescription": {
    "minimum": 0,
    "maximum": 100,
    "step": 1,
    "pattern": "%.0f %%",
    "readOnly": true,
    "options": []
  },
  "editable": true,
  "type": "DateTime",
  "name": "Kitchen_Door_last_report",
  "label": "Kitchen sliding door (last report)",
  "category": "",
  "tags": [],
  "groupNames": [
    "Last_reports_batteries"
  ]
}
8

I checked a few devices that are working, and none of them define pattern.

Here’s my working theory. I’m wondering if the UI is looking to the pattern in stateDescription in some places (like on the detail page where the error appears), but not universally? I’m guessing the UI isn’t attempting to format the DateTime when the data is displayed in the list of Items, hence it not returning a formatting error. It maybe makes sense to look at pattern when attempting to render the default channel data, but maybe not when the data is being replaced with a DateTime, as with “Timestamp on update” and “Timestamp on change”?

Does that make sense?

1 Like
9

Yes, that is exactly what the ‘pattern’ is for, “here is how I want you to present my Item in the user-facing UI”
"pattern": "%.0f %%" says “please show this as a number with 0 decimal places and a % symbol”. The UI chokes on trying to present a datetime in that way.

So, you didn’t do it, where’d that come from?
It was the zwave channel, it “knows” everyone will want to present a battery percent reading in that way and “helpfully” force-feeds the setting to the Item across the channel.
Framework is dumb enough to apply it inappropriately to your DateTime Item, ignoring that the whole point of the timestamp profile is to link number channels to DateTime Items.

What can you do?
Edit your Item metadata to change the ‘pattern’ to something more appropriate for a DateTime, %1$td/%1$tm %1$tR or similar.

The question then is how sticky is that - will the framework overwrite it at the next reboot? Or if you newly link some other zwave channel, via timestamp profile? Or does it only “help” if there is no existing pattern?

I’d like to find out, if you can explore, it’s good info for the github issue.

10

Great, this is really helpful. I appreciate you taking the time to explain it, and taking the time to recommend debugging steps. I think I narrowed it down! In summary, the battery channel sends pattern, which appears to override type in certain places.

So here are some findings:

Changing the format code for a device to %1$td/%1$tm %1$tR

  1. The metadata persisted over a reboot
  2. It’s correctly showing your format code on the Item detail page
  3. It’s also correctly showing your format code on the Channels tab on the Thing detail page
  4. The item list (/settings/items) does not show the new format code, but rather continues to show the timestamp.

1, 2, and 3 make sense. However, 4 surprises me a little and might be worth separate consideration from the original question. Would we expect the values in /settings/items to be formatted according to pattern? It appears to be ignoring both and only looking to type, and I’m not sure if this is expected behavior.

Next I tried adding a new channel

  1. When I linked a single Contact Item, the timestamp displayed correctly. Also, the API explorer indicates there’s no pattern being sent.
  2. When I linked a second Switch Item, the timestamp displayed correctly as well, and API explorer indicates there’s no pattern being sent.
  3. When I linked a battery item, it went back to the original problem, and API explorer indicates there’s now a pattern being sent. This happened any time battery was linked.

My guess here is that when a channel has pattern defined, pattern strictly overrides type, even if it will create a formatting mismatch. I can understand why, it would be impossible to account for all possible pattern choices because a user could set anything they want.

Next steps

I think there are two options here, and I’m not sure if either is better than what we have today. I’d be happy to open an issue on this to take the discussion to GitHub too, if that’s easier.

  1. Ignore the pattern when the type is a DateTime and always display the timestamp. This would always work out of the box, but could end up ignoring user-set metadata.
  2. Add pattern metadata by default when a user creates an Item that uses a “Timestamp” profile. This would start them from a known good default state, and could be overridden.

Thanks again for the help, do you have any thoughts?

1 Like
11

I would expect the Item list to show the “raw” unformatted state. MainUI is playing two roles here. the “system administrator” who needs to see raw data and Item names and such. And the “user-facing UI” where we get selected prettified data, nice labels, and most machinery is hidden.

Good work, that confirms it, thanks.

For the time being, you have a workaround - manually check/set the pattern any time you see an error display.

I will update the issue with your findings, and we await a developers interest.

We should never ignore ‘pattern’ in UI for any Item type (we should just get it right !).
It’s possible to make the profile force a default, but fairly harmless if just left alone - ‘pattern’ will either be empty or some manual choice already.
The problem is the “helpful” override.

1 Like
12

Separate business really, now that the display issue is worked around … you don’t have any problem with multiple-timestamped Items getting into a loop?

13

Thanks for all of this! It’s much appreciated.

On multiple-timestamped Items, I think that happened at one point when I linked some OpenWeatherMap Channels. It brought my system (RPi3) to its knees. I don’t have any logs left, but I do remember seeing message after message about timestamp updates to the same Item. It caused so many problems that I reverted it as soon as possible. The UI was nonresponsive, but I was able to recover by logging into Karaf to remove the links, and then rebooting.

My guess is that I hit the same thing you were describing in the issue, but I’ve only seen it with the OpenWeatherMap Thing. I have a lot of Z-Wave devices that are using multiple Links, and haven’t seen the problem with any of them.

1 Like