please read Rossko’s post above (way above it is post #11)
Ah yes Ross that makes sense. It’s a far more simple and elegant architecture which leaves the user to dictate & config stuff.
Is all this a case of OH3, in the effort to make it more and more sophisticated, that it is trying to be too clever, a bit like spell checkers often get in our way (and get things wrong) when we type stuff. At least we can turn off spell checkers! and override their mistakes.
For the lifetime of OH1 and OH2, people bitched about having to manually edit every damned line of this clonky old-fashioned text based sitemap thing, and about how limited ClassicUI and its successor BasicUI presentations were in the modern mobile world. Some people wrote alternative UIs even.
Meantime, nothing stops you continuing to use it for user-facing presentation. Examine why you have chosen not to do that, there are likely good reasons.
To encounter this problem at all there are several conditions.
You need to use a channel which carries additional device specific information
AND
You want to use it with an unusual type of profile
AND
You want to prettify the result for presentation, not just use for rules/admin.
That combination is fairly rare, and the majority of people who have arrived at the problem so far have been able to easily circumvent it with a one-time hand edit.
We’ve been all around the houses to establish why that doesn’t cut it for you guys, so far as we can make out it’s because you’ve got an even more obscure version of the same problem involving extra device-specific details.
The long term fix is the same - don’t have the system copy inappropriate presentation details in these unusual circumstances. Exactly how to code that in core is actually a challenge when you consider the detail, no-one has yet risen to it.
The simple-edit workaround is not available to you - I’ve no idea why.
The functionality you need is available to you, using a simple timestamping rule instead of a profile.
Hi Ross, thanks for your detailed reply. I do understand what you’re saying.
Yes I could stay with Basic UI etc but I liked the idea of following and supporting the new OH3. It is conceptually challenging in parts (and fiddly sometimes) but overall I manage it fine and I like the pre-populated cards/UI that flow from the semantic model.
It’s a pity we couldn’t get at/edit the file(s) we think are problematic. So it will have to be that workaround with a time stamping rule with no profile for the moment.
Thanks again for trying to help us out. Have a nice Christmas and good wishes for the New Year 
Navigate to the Item. Click on “add metadata” and then click on “state description”
Put a space under “Options”
That should overwrite anything that the binding inserted.
No, I think we have exactly identified the culprit. What we are trying to solve now is a work around. An issue is already open to address the root of the problem. Unless and until that issue is resolved we need a work around.
This is the only part that matters.
The options that has values has values that don’t work for a DateTime Item. As a work around we are trying to get rid of those options.
The readOnly option is not in play here. As @rossko57 said, it’s just a hint to the UI to choose an appropriate widget to display it. It has no other functionality. And even if it did, that functionality would be to prevent one from sending a command to the Item which isn’t being done in this case anyway.
I’ve seen no evidence yet that you’ve tried what @rossko57 asked you to do. Before giving up and/or flailing about blindly, let’s try that first. If I missed the post where you did try that than never mind, time to look elsewhere. But there is no file to edit. There is no special setting. Just go into the UI and change the options to a blank space and see what happens. Does that override what the binding is doing?
That’s not true at all. We have confirmed that the binding is injecting this state description options. We have confirmed that it’s probably built into the binding and not part of the zwave database settings.
What we have not confirmed is whether that metadata is just injected into the Item at link time or whether it’s requested from the binding every time. If the latter then we know exactly what needs to be fixed: don’t do that when the user has defined their own state description metadata. If the former, the work around by setting the options to blank should be a sufficient work around until the core issue gets fixed.
HABPanel is still supported in OH 3 with no plans to remove it. Same as with BasicUI. The good old days are today. If MainUI doesn’t suit your needs, please don’t use it. It’s not wrong to not use it. No one is going to think less of you.
1 Like
Hello Rich,
No it does NOT make any difference at all. My Options window was ALWAYS blank, I never inserted anything there. I only put the format pattern into the Pattern window.
**
[quote=“rlkoshak, post:85, topic:130130”]
However, to dispel any notion that I have not been following suggestions and merely flailing about, a disparaging remark that I do NOT appreciate and only serves to dissuade users form asking for help anymore,** I inserted a few spaces and a return and saved and refreshed…no change.
You will also note, if you read my earlier posts, that I did make the effort and supplied all the YAML/REST/JSON/API files I could find/manage.
We very deliberately and with purpose told you to insert a space there.
Not blank.
Not empty.
A space.
We need something there to overwrite what the binding is inserting. A space is a something and a something that will be ignored.
But you didn’t add the space to the Options field like was asked. Instead we went on a wild goose chase looking for some file to change when no file was asked to be changed. And instead of making the change requested you assumed that because it was blank you could not do as we asked.
Debugging something like this remotely is exceptionally difficult. We do our best to be precise in our instructions and we need them to be followed as closely as possible. When that doesn’t happen we all end up lost.
But if my participation here is not appreciated and dissuades people from asking for help, I’ll gladly spend my time elsewhere.
Rich, I have inserted a space (using one tap on the spacebar), then saved the change, then refreshed the browser. Is that what you asked/meant?
It had no effect unfortunately, timestamp data still in raw state.
This is the first time anyone has suggested this test btw, nobody raised it before. I did try editing files earlier in the discussion as per Ross’s suggestions.
I am NOT a programmer, thus a lot of this can be difficult and what appears obvious to ye may sound like a foreign language to others. I do appreciate your involvement and am always courteous to forum members.
I think I misunderstood one of the posts @rossko57 posted when he asked you to delete it. I read it to mean delete it by setting it blank.
Anyway, we’ve found one more way that won’t be the work around for the issue.
I’ve got too many irons in the fire right now with the RC1 release and other stuff so I’m probably hindering rather than helping on this thread. All I can strongly recommend is that you and @Andrew_Rowe please add what was discussed and learned to that issue rossko57 linked to above.
No problem Rich, you’re a busy man I can see… thanks again for your input, these tech teething issues make me tetchy. Have a nice Christmas and all good things for the New Year 
Yeah, I added some stuff and link to this thread (even thou the bot had already linked it)
here is link to my comments on git
https://github.com/openhab/openhab-core/issues/2037#issuecomment-997410943
enjoy the holidays Rich
1 Like
Hi Andrew, did you manage to link both of our recent discussions to Ross’s post? Thanks for doing that cos I’m not sure how to manage/navigate some of the forum stuff.
I hope all our digging and will help the cause. regards and Happy Christmas
When one adds a link to a GitHub Issue or PR in a forum post, a bot will see that and add a comment to the PR/Issue with a link to the forum post. It’s pretty nice actually. But adding a comment helps too because it will bump the issue and put it in front of the developers again.
But I’m considering opening a new more generic issue because I think the devs are looking at the title and ignoring it because it appears to only impact hysteresis.
1 Like
I think that is a good idea Rich
there is another issue linked in that one that is about the same issue, I think Ross linked both of them way up above. Rossko made some great comments in the git issue today…
as he said with the ‘recent proliferation of system profiles and binding-specific profiles’ that a ‘framework policy decision’ needs to be made
Hello all,
I have the same question to this.
I try to configure it in my YAML:
component: oh-cell
config:
title: =items.date_actualntpdatetime.state
value: =items.date_actualntpdatetime.state
pattern: "%1$tH:%1$tM:%1$tS"
slots: null
But it is showing:
2023-01-05T18:14:13.171+0100
My item and thing description:
Thing ntp:ntp:smarthome [ hostname="de.pool.ntp.org", refreshInterval=60, refreshNtp=43200 ]
DateTime date_actualntpdatetime "[%1$tA, %1$td.%1$tm.%1$tY %1$tH:%1$tM]" <time> {channel="ntp:ntp:smarthome:dateTime"}
Try .displayState ?