DateTime format with OH3 items not working

Setup, Configuration and Use Items & Sitemaps
17

It’s a brand new UI with way more features and way more capability than any UI for OH that has ever existed. To expect it to be as simple as sitemaps is unreasonable. That’s why BasicUI is still around and will likely remain around. Heck, thats why MainUI even has the ability to create sitemaps.

MainUI is not intended to be a replacement for BasicUI that everyone must migrate to. It’s there if you want to use it. If it’s too hard or complicated to use right now, don’t use it. There is nothing wrong with using BasicUI.

Yes, it should be. In my experience it actually is. So I need from you lot and lots more detail to figure out where it’s going wrong. Have you uncovered a bug? Is there a misunderstanding that can be addressed in the docs? Is there something special about DateTimes? :man_shrugging: I don’t have the information I need to tell at this point. I don’t even know enough to. try to reproduce what you are seeing on my system.

So yes, it’s more complicated. You must fiddle with some YAML so I can see what you have done. Or you must use BasicUI because I can’t help you.

In MainUI yes, that’s my experience. The State Description is unfortunately use in a lot of different ways so it has influence in a number of other areas. But in MainUI, the State Description is only used in a widget.

Just as you posted it. No square brackets, no quotes.

However, the screenshot of your widget code is cut off exactly where I need to see it. Please post the full YAML in code fences and not screen shots which are hard to work with.

You can find the full syntax Formatter (Java SE 11 & JDK 11 )

To get the month spelled out replace the %1$tm with %1$tB for the full month name or %1$tb for the abbreviated month. Your locale’s names for the months are used.

With the information I’ve gathered so far, what you’ve done is not different from what Andrew and Denis have done which is why I need more information. What they’ve described should have worked. It really is that simple and we need more information to understand why it’s not working.

Show your Default Standalone Widget. If you don’t have one, what happens if you create one like what Bob posted?

Look. It should work. It should be that simple. I need that YAML to see what’s going on. Day-to-day you don’t need to ever look at or mess with YAML.

It’s no different than requesting logs and the rules code from someone who is trying to make a rule work. If you don’t want to post some YAML and gather additional information for me so I can help, then please, give up. I can’t help you. No one can. Continue to use BasicUI.

Again, the YAML is for me. I’m the expert on this thread (which is unfortunate since I’m far from an expert on this stuff). I need this information. Nowhere have I ever said that you will have to deal with YAML to make this work. Help me help you!

18

Rich- Great reference ! thanks. I can now do more than one date-time format :smiley:

FWIW- I get the display state on the UI page for the item, but as you noted, not on the summary item page.

Also don’t know if this will help troubleshooting, but I just started adding DateTime metadata to channels about three months ago on 3.1 stable. I’m currently on 3.2M5, but also used 3.2M4 along the way.

Thanks

Bob

19

Comment: a lot of confusion stems from MainUI being dual-purpose. Both Admin and User functions. In OH2 terms, PaperUI and BasicUI rolled together.

In Admin areas, we would want to see raw states.

In user’facing areas, we would want to see prettified states.

By design, you could see either depending where you look in MainUI.

20

Hi Rich,
As shown in the screen shot below from a card display that I sent you last night, I didn’t go creating any new standalone widgets on a separate Pages setup. All I did was fiddle about randomly creating another item and adding a Metadata widget to it and messing with linking and unlinking… is this what you meant by adding Oh-stanalone widgets etc last night? Somehow mysteriously it worked (see screen shot) but I took it apart and haven’t been able to reproduce the temporary success since :grimacing: so there would’t be any YAML code available to me would there? Well I don’t see any option to view the code when I’m dealing with a Metadata pre-made widget. I only see the option to view YAML code when I experiment with Widgets in Pages layout rather than the normal UI location/equipment/properties cards. If one can do this, I don’t know how, sorry. So I’m not trying to be uncooperative and I can see you’re genuinely trying to help but we all seem to be stuck in a web of frustration…
Pattern stuff DOES normally work for the cards but there seems to an issue here where the Profile of Timestamp on the channel is stubbornly overriding & ignoring what the user really wants to see from having inserted a Pattern to present the raw data in the desired way. This is the nub of the problem.
Have you tried to reproduce what I did? My screenshots are clear enough. Do you have a simple door contact & use the magnet or some wires to close/open it and add a timestamp channel? I think if you actually try it you’ll better understand what we’re experiencing and what should appear be in those codes areas. Thanks again for you patience, I’m sure we’re driving you mad too … :upside_down_face:

Bizarre

21

Rich, some progress/insight on the issue but not solved.
I added a Metadata ‘Default List item widget’ of flavour ‘Default-oh-label-item’, there was no progress until I UNLINKED the entire ‘Raining_since’ item from the channel and suddenly the properly formatted time appeared!
However, it stays frozen like that despite further changes because it’s unlinked.

So the Pattern managed to do its function on the item display as soon as the item was unlinked. It’s useless like this of course, but it might shed some light on why the properly formatted time is ‘hidden’/‘overridden’ by the channel profile until the moment the link is gone. It somehow caches and converts the last instantaneous value.
Screen shots below.
Notice:
Pic 1, channel is now unlinked from item. Correct format evident on top of item header viewed from Model perspective.
Pics 2 &3, correctly formatted time appears on both the metadata widget AND the UI Card.

Progress-1

Progress-2
Progress-2858×157 13.3 KB

Progress-3

22

The channel linking process has a feature (in my view poorly designed) where the binding can ‘suggest’ - in practice, silently force - a suitable pattern into metadata.
That should happen only once, at linking time.
You should be able to hand-edit a more suitable pattern after that one-time action.

Clearly that can lead to an issue where a switch type channel is linked to a DateTime Item, and a ‘switch’ suitable pattern is forced on the DateTime.
Open issue -

Unrelated to that -
The timestamp profile itself had a weird bug where it kept forcing Item update if something else changed it - such as you might get when linking two timestamps to same Item.
That one at least has been fixed recently -

but I wonder if an unnoticed effect of that was also re-forcing target Item pattern.

EDIT - ah I was just reminded of a nasty consequence of the ‘link forcing a pattern’ strategy. A binding may also suggest ‘state option’ metadata. e.g. a motion sensor switch sets [ON = motion, OFF=idle]. That is really going to screw up when used with a DateTime. You might check your misbehaving Item(s) for that metadata, too.

23

And that metadata widget has a code tab. Clicking on the code tab shows some YAML. I need that. Especially if it’s not working. Looking at one that is working for you and one that is not would also be informative if you still have one that works.

If you have the metadata still on the Item, then yes, the YAML will still be there. If you deleted that metadata then yes, there will not be any.

  1. Navigate to the Item
  2. Click on “Add Metadata”
  3. Click on “Default Stand Alone Widget” or “Default List Item Widget”
  4. You now see a form where you can customize the widget that get’s shown in that context (stand alone on Pages and at the top of the Item’s page, list item is how it appears in the cards on the location page, for example). There will also be a “Code” tab in the upper right. Clicking on that will show the YAML for widget. A nice and concise version of what you did through the form on the “Design” tab.

Screen shots are not all that useful but the YAML is very informative.

If you don’t have a custom widget assigned to the Item, then that is likely one of the differences between the one that worked and the one that is not working.

This is an interesting statement. I know that Bindings can provide their own formatting for how Items are displayed, maybe the Profiles can too.

That could be a source of difference and perhaps even point to a bug in the Timestamp Profile. Though it works as expected for me.

Yes but there really isn’t enough detail or precision in the detail provided for me to do it. Everything I’ve tried works for me. That’s why I need all the details. This is the first mention of a Profile. Those sorts of details matter.

Not when you are responding from a phone and have presbyopia. Also, I often can’t copy and paste from a screen shot. That’s why I need the YAML.

Yes. I’ve a door contact. I linked a DateTime Item to it using the Timestamp on change Profile. I modified the State Description pattern to %1$tm-%1$td %1$tH:%1$tM and I see

image
image1554×1384 123 KB

No Default Widgets or anything like that.

As I’ve said, the straight forward approach works just fine for me. So I need to find out what’s different between your config and mine

This doesn’t make a whole lot of sense to me. It is true that some binding developers can specify their own state pattern for Items. And I think it may even override your State Description pattern (for which I’ve complained). But that would apply here. The Profile is completely transforming anything coming from the binding so all that should be lost.

Oh yes, now I see it. If the binding is forcing something like %s then you’re just gonna get the default date time formatting no matter what you do.

@denisdmenace, to get that, probably the easiest and most comprehensive thing to do would be to navigate to /var/lib/openhab/jsondb (assuming this is installed on Linux) and open the file with “Metadata” in the name. Post all the entries that are associated with the non-working Item. An entry will look something like:

  "stateDescription:FrontDoor_Lastchange": {
    "class": "org.openhab.core.items.Metadata",
    "value": {
      "key": {
        "segments": [
          "stateDescription",
          "FrontDoor_Lastchange"
        ],
        "uid": "stateDescription:FrontDoor_Lastchange"
      },
      "value": " ",
      "configuration": {
        "pattern": "%1$tm-%1$td %1$tH:%1$tM"
      }
    }
  },

I’ll want to see all the entries for that one Item. That will show us what you’ve applied as well as anything the binding may have applied.

24

Thanks for all your effort on this.
Ok I attach YAML code for the bits you want. You mentioned about working/not working. It has never ‘really’ worked except when the item is unlinked and thus that is only a frozen moment in time.
Also, I attach the jasondb stuff. In fact I’m on a Mac which is Unix, not Linux, and the file was nowhere like you mentioned…found them in the userdata/jasondb/ folder (directory in unix speak) and the one of interest was org.openhab.core.items.Metadata.json

The YAML code areas are almost empty. The widget one has effectively nothing.

Metadata State Pattern Design UI
Metadata State Pattern Design UI795×175 17.9 KB

Metadata State descr YAML

Widget config
Widget config804×314 31.5 KB

Widget YAML code
Widget YAML code877×180 17.3 KB

JSON State description & List widget Code: LINKED mode

Raining_since item code

Raining_since widget code

Do you need the actual code stuff as a copy paste inside code fences or are the screen shots ok for you?

25

That’s with it “working”, right? What does it look like after re-linking, using timestamp profile?

26

Noooo haha… :grinning_face_with_smiling_eyes:… this is all with it NOT working, as you can see the raw unformatted DateTime stuff in the widget header. I’ll try do the jasondb for the unlinked mode so, good idea.

27

Could you use the REST API (“API Explorer”) to examine your Item, with and without link? That should give us a complete ‘live’ picture of what the system thinks it is about at that moment.

28

UNLINKED MODE:

Unlinked widget shows format ok
Unlinked widget shows format ok879×304 31.3 KB

Unlinked widget YAML code
Unlinked widget YAML code837×167 17.1 KB

JSON code State descr-UNLINKED

JSON code Widget-UNLINKED

29

Sorry Ross, I’m not sure how to do that exactly… I see Developers tools and an API Explorer tab but all I see then are lists of commands…I don’t know the procedure, sorry.

30

Breakthrough!
Hi Rich & Ross,
It occurred to me this morning to try linking my ‘Raining_since’ item to a totally different item channel… chose my Fibaro FGS212 Relay switch for my Hall lights. The time stamp formatting worked perfectly and followed the hall light being turned on & off!

So after me cursing OH3 :flushed: it would seem that the problem is (unfortunately) connected with the particular brand new Aeotec Z-Wave ZWA008 Door/Window Sensor 7 that I’m using to pick up the switching state of my external rain sensor.

This doesn’t totally resolve the problem except it puts the focus on a particular Wave device not playing ball. Other users had problems so there may be some pattern with devices that don’t behave well. I don’t know what my options are now for my rain sensor or whether ye have any suggestions to get to the core of the issue.
Once again, many thanks for your time & patience. :slightly_smiling_face:

31

The difference will undoubtedly be to do with the device-tailored state description suggestions thrust upon the Item.

32

OK, I can confirm this is caused by the timestamp on change profile.
After reading all the above I realized both DateTime items I was trying to get to work were DateTime items set by timestamp on change on Zwave door contacts (two different brands). So I made a test button switch item. Then I made a test DateTime item. Then I wrote a little DSL rule to update the test DateTime item when test switch item gets toggled and put format in State Description metadata and… it works
Screenshot from 2021-12-17 08-04-23

33

Yes, I think both @denisdmenace and @Andrew_Rowe’s most recent posts confirm we are seeing the same problem as the issue @rossko57 posted in #22. I think it would be helpful if you went and posted these additional examples that show how it is indeed a problem.

Maybe if we can get enough reasons for why this is a problem we can get to a solution. I’ve always been a little down on the bindings thinking they know better than the users on how they want an Item displayed and used in the first place. But they definitely shouldn’t do so in a way that breaks other parts of OH.

34

Hi Andrew that was a good test you did. So we know that at least 3 brands (2 for you and mine) of Zwave door contacts are interacting badly with the ‘timestamp on change’ profile.
However, the profile and the successful formatting, worked perfectly for the Fibaro FGS212.

So to be clear in my mind, the ‘Bindings’ that Rich refers to are the device-specific ones rather than the Zwave binding itself? Thus some devices and their bindings are playing different to other devices/bindings with regard to Timestamp?

What can be done?? We have no control over manufactured devices. Is there anyway OH can be tweaked to ignore/block ALL binding ‘suggested’ formatting and allow the user (who probably knows better anyway) to dictate his own formatting? Maybe Profiles are not such a good idea at all? Just have State Description Patterns & Maps?
Right now, using a rule (like in Andrew’s test) to watch for changes & post updates to a virtual item seems the only option albeit rather clunky as an overall strategy.

35

Ultimately it is how the device is configured by the binding. Given the way Zwave works I would not be surprised if this is captured in the database entry for the device. Though it could just be as simple as “all Items of type Foo get this default state description” too. But ultimately it’s the binding that doing the injection of the state description that is causing the problems.

It’s definitely the Zwave binding in this case. It’s not the devices themselves. They don’t know anything about openHAB and openHAB state descriptions. Other bindings, e.g. MQTT, do not supply a default state description. Those don’t have this problem.

So either:

  1. the Zwave (and all other bindings that do this) needs to be modified to not supply a default state description
  2. maybe the database entry for the device in the Zwave binding needs to be updated to not supply a default state (assuming that’s how it works)
  3. OH core needs a way for users to override the default display state provided by the binding.

Once the Link is created I think you can modify the binding supplied state description through the REST API or by manually editing the Metdata file (when OH is off).

But the best thing you can do right now is to comment on that issue.

Eliminating Profiles isn’t an option, not least because what they do cannot be done with just the State Description Patterns and Maps. For example, how do you transform a CLOSED to the *current" date and time using a map? And even if you could, how can you use that in a Rule?

36

I’ve tried to tell you that this is not the profile’s fault.
The underlying problem is that a channel of one type is linked to an Item of different type, and the linking process brings some baggage that does not “fit” this mis-matched target Item.

None of the info shown so far shows exactly what that baggage is.
It would be a help to look at the metadata on the “normal” Item also linked to same channel, where it is actually useful. Then we can see what also gets thrust at the DateTime Item.