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
Thanks, i was not aware about this behavior.
Shoud i rise it as a bug in Github for the EnOcean binding to make the pattern work?
But under the current philosophy, it is quite legitimate (and considered desirable) for a binding to set state options e.g. a motion sensor Contact type channel supplies CLOSED=OK, OPEN=motion state descriptions.
The problem is not the binding supplying these options, it is the framework mis-applying them to a different Item type (when a profile allows to mis-match types in this way)
I see your point but how to come to a solution?
Maybe there is another way for what i want ot achieve:
I want to display in a page the lastUpdate for a window / door sensor to see when it was last time closed / opend.
in OH2 my implementation was
rule "enocean check updates"
when
Member of g_sFenster changed
then
val problemitem = triggeringItem
postUpdate (problemitem.name + "_LA", problemitem.lastUpdate.toString)
logInfo("Enocean.rules","LASTEUPDATE: {}_LA, {}, state: {} ", problemitem.name , triggeringItem.lastUpdate.toString , triggeringItem.state.toString)
end
but in OH3 this .lastUpdate.toString seems to be not available for an item.
Searching in different places i found the approach with the profile at the channels which i think is a really good aproach if it works.
In a next step i also want to check how long a window is open and e.g. send a message to close the window if it is to could outside. I think this could be done utilizing the persistance of the item with the sensor data.
You’re absolutely right, profiles can get in the way and make the options invalid, maybe it would be better not to advertise them if a profile is applied (since we don’t know in advance what a profile will do to the state nor what it implies regarding the type).
Yes having another item with the “last updated” profile is the best way to go.
Regarding the widget you can add “Default List Item Widget” metadata on it to alter the presentation when in a list.
For an item like this:
You can use a oh-list-item instead of the default oh-label-item and use an expression for the “after” label - in the “Code” tab of the metadata editor this could be:
value: oh-list-item
config:
title: Last Opened/Closed
after: =dayjs(items.HS1DSZDoorSensor_LastChange.state).fromNow()
(you have to specify the name of the item and its title explicitely, this could be improved)
and it will look like this:
This example uses Time from now · Day.js as an illustration but you can use other day.js functions to format it as you want.
For instance:
after: =dayjs(items.HS1DSZDoorSensor_LastChange.state).format('HH:mm on dddd')
You have only to remove the unwanted options from the Item. These only get applied when the channel is first linked, so you can remove them afterwards.
I don’t know where i should remove them because nowhere in the Item i can see them
I think the only way is to query for the Item using the REST API, editing those options out of the JSON, then submitting the edited JSON back to OH using the REST API. A less safe alternative would be to stop OH and manually edit them out of the JSONDB entry.
Though Yannick’s solution is probably the easiest and safest.