Formatting date/time of a label-item (within a list-card-widget in a page) with YAML

I see in your first screenshot that you are setting the State Description on the group and not on the item itselves.

If you want to see data from your items in the group, you shoukd also have a look to the Group Settings in the group.

1 Like

That makes sense, now it basically works.
“Just” one more problem: When I enter “%tM” I get the correct minute, same with hour. But when I try to combine more than one (e.g. %tH:%tM or what I’d really like %te.%tm.-%tH:%tM) I get ERR.

Try "%1$te-%1$tm-%1$tH:%1$tM"

1 Like

There is way more available in a loop in an oh-repreater element. Everywhere else all you have is the state and displayState. I don’t know what isRootInsert is either.

I just happened to select an Item at random. The fact that it’s a Group is just a coincidence.

But, assuming that the Group Item has a state it works exactly the same.

I have seen cases where the page needs to be refreshed before changes to that sort of metadata gets picked up. There is no other event generated to tell the web page that the metadata has changed.

Here is a state description (in YAML) from a Number:Time Item which takes the same formatting as a DateTime.

value: " "
config:
  pattern: "%1$tH:%1$tM:%1$tS"

You cannot set this on a component. It’s completely separate from the widgets. It’s never going to work that way.

1 Like

well, thank you all, now it works like it should!
Looking at Formatter (Java SE 11 & JDK 11 ) I’d never have guessed the format. Didn’t see anything about “%1$” or what it means but I’ll remember now.

I’m trying to achive the similiar thing for an large numer of datetime Items that has been generated in the text file.
They have a display formating embeded and that works for displaying single item in the

DateTime SAIP_004_temperature_LastUpdate	"Temperature LastUpdate [%1$tY.%1$tm.%1$td %1$tH:%1$tM:%1$tS]" (modbus_LastUpdate) {  channel="mqtt:topic:eui-oh3:moxa:temperature_1" [profile="system:timestamp-update"] }

But when I try to do that in the oh-repeater loop I only display loop.item.state that will have default time formating.

The above solution is not working me as metadata are locked for bulk generated items.
is there a way to access proper formated datetime from within the loop for my case?

You mean for Items defined in .items files? Well yes, if you have the defined in text files you cannot change them in the UI. But you can add the metadata in your .items files. It will be something like

{ stateDescription=" "["pattern"="%1$tY.%1$tm.%1$td %1$tH:%1$tM:%1$tS"] }

I don’t do text based configs any more so there could be a typo in the above.

1 Like

Ok, thank for pointing me in the right direction so I did setup of the state description in the items file
The correct syntax accoring to some other post I found is (just pattern without “”)
DateTime SAIP_004_Temperature_LastUpdate "Temperature LastUpdate [%1$tY.%1$tm.%1$td %1$tH:%1$tM:%1$tS]" (modbus_LastUpdate) { channel="mqtt:topic:eui-oh3:moxa:temperature_1" [profile="system:timestamp-update"] , stateDescription=" " [pattern="%1$tY.%1$tm.%1$td %1$tH:%1$tM:%1$tS"] }

and it now shows up in the UI

image

but it looks like at the display in the widget it is ignored as I still get generic timestamp when I use =loop.item.state

1 Like

You should use displayState instead of state.

.displayState does not exist when you try to use it within the the oh-repeater component.
from the whole this tread I understood you can only use when accessing single item not in the loop.

that renders NULL for the footer.

loop.<var> in expressions within a oh-repeater context contains an array of EnrichedItemDTO (openHAB Core 3.2.0-SNAPSHOT API) which has a state but it isn’t updated dynamically (it’s what the REST API returned at the time of retrieval), so you shouldn’t use it; items on the other hand is a map of Strings - the item name - to StateDTO which is updated.

So your loop.i.state should rather be items[loop.i.name].state (or items[loop.i.name].displayState).

2 Likes

@ysc you are the man. Many thanks.

What is more surprising that with that method of calling the items it does display formatted time even for the items that do not have State Description in the items files, like the standard sitemap pattern is enough. If I add metadata it will override the sitemap pattern and display that instead.

i want to display the lastUpdate datetime for my handle items and i have implemented the items as explained here, but i still see the original datetime format and not what i have put into the pattern of the statedescription. Even after a restart of openhab nothing has changed. Any idea why the pattern does not work as in examples above?:


Item:

Metadata:

Page:

Yaml:

I don’t know if using just item in the widget will have it show the display state or not. Set the title field of the widget to =items["ItemName"].displayState.

nfortenatly does not work:


this widget “oh-label-item” is part of a list card. Also the selection of a special list type like Media List has no impact.

What i am a bit wondering is that already on the item level, where i have added the metadata and pattern the time is shown in the original format and not with the format adden in the pattern

i had a quick look at the item definitions using the Rest API. when i compare the item with the lastUpdate it looks different compared e.g. to an Astro-Item.

{
  "link": "http://ohshd:8080/rest/items/AstroLocalSun_CivilDusk_End",
  "state": "2021-10-12T19:03:00.000+0200",
  "stateDescription": {
    "pattern": "%1$tF %1$tR",
    "readOnly": true,
    "options": []
  },
  "editable": true,
  "type": "DateTime",
  "name": "AstroLocalSun_CivilDusk_End",
  "label": "Abenddämmerung Ende",
  "category": "sunset",
  "tags": [
    "Point"
  ],
  "groupNames": [
    "AstroLocalSun"
  ]
}

and the lastUpdate item

{
  "link": "http://ohshd:8080/rest/items/EOAZFenster_WindowHandleState_LA",
  "state": "2021-10-12T21:33:46.294294+0200",
  "stateDescription": {
    "pattern": "%1$tY.%1$tm.%1$td %1$tH:%1$tM:%1$tS",
    "readOnly": true,
    "options": [
      {
        "value": "OPEN",
        "label": "Open"
      },
      {
        "value": "TILTED",
        "label": "Tilted"
      },
      {
        "value": "CLOSED",
        "label": "Closed"
      }
    ]
  },
  "commandDescription": {
    "commandOptions": [
      {
        "command": "OPEN",
        "label": "Open"
      },
      {
        "command": "TILTED",
        "label": "Tilted"
      },
      {
        "command": "CLOSED",
        "label": "Closed"
      }
    ]
  },
  "editable": true,
  "type": "DateTime",
  "name": "EOAZFenster_WindowHandleState_LA",
  "label": "EO AZ Fenster LA",
  "category": "time",
  "tags": [
    "Point"
  ],
  "groupNames": [
    "g_sFenster_LA",
    "gPersMapDB",
    "gEO_Fenster_handle_state_LA"
  ]
}

This lastupdate item was created from the Main UI via thing with adding a link to a channel with the profile timestamp-change

Also the value in the state looks a bit different (numbers after the seconds):

"state": "2021-10-12T21:33:46.294294+0200"

compared to the state in the astro item

"state": "2021-10-12T19:03:00.000+0200"

is there an issue with the time values comming via the profile?

About the only think I can see that looks unusual is the options. It makes absolutely no sense for a DateTime Item to have OPEN/CLOSED option nor does it make sense that it has commandOptions. Perhaps that is causing some problems.

Comment; that’s the trouble with bindings forcing these options onto Items, when a transform to a different Item type is involved.

1 Like

agree with your comment and there is another issue:
i can’t see these options / value and commandOptions in the main UI:

and if i try to add metadata / Command Options i only get emty fields

Where are the values stored which i can see using the rest-api and how can i delete them?

This is by design:

These state/command options are provided by the channel the item is linked to, so you can’t override them.
And I believe like @rlkoshak that’s causing the formatting issue - you can’t have both state description options and a pattern. In that case the pattern is likely be ignored.
However this might a bug in the binding which maybe could set command options and leave the state description alone. Then the pattern would be considered for the display state and you’d still have the command options (a menu sheet with Open, Tilted, Closed when you click the widget).

1 Like