Sorry to ask again Ross, but where is this file or how do I get at it, that has the stuff about closed/open options that you suggested to edit out?? I don’t see anything in any GUI…thanks
I cant get it, I keep getting an error in the REST interface, I think I’m screwwing up the yaml
Edit: it won’t work in REST api, says item not editable
FWIW - I have been following this and was able to recreate the format problem on a Senative AB door contact using the Door sensor Contact channel. The battery channel on the same device (with a datetime) formats as expected. The idea came to me with post 51.
I have tried to use the API to put "options": [], but it does not change. (reverts to original, but indicates it was executed fine (200)).
I also tried to use the API to jam in a timestamp-trigger (missing from my options) as this might be what was intended for this type of channel, but no luck (actually I got it to register, but the format was still a problem). There is a comment under profiles Install transformation add-ons to get additional profiles., but I can’t figure out what transformation it is talking about.
I also tried a textual item with the channel and profile="system:timestamp-trigger", but item was null. It really should have worked (almost a direct copy from the documentation), so that is a mystery, but unrelated to the core issue posted here.
I’m thinking we need the UI guru.
Bob
Hey Bob, very interesting post! Great that you tried all that code manipulation… so this problem is probably quite widespread and it would seem we haven’t clearly identified the culprit. All the various strategies have seemed plausible but we’re missing something.
At least from reading your post I think I see how to get the API to ‘do’ something (edit code?) as opposed to just interrogating items 
We might need the 3 wise men from Christmas at this stage… 
Andrew and Ross, I think ye have identified different clues between ye.
The two cases below are for the DateTime Item linked to the same Contact device. I did not change the linkage to the Fibaro FGS as in previous tests. Notice how format works ok when link is removed.
Notice the working one has ‘readOnly’ set to false, whereas the non working has ‘readOnly’ set to true.
Notice the working one has ‘options’ [], (empty), whereas the non-working one has ‘options’ [values, labels, open, closed etc…stuff]
Notice both cases still have the Pattern intact so it doesn’t get erased, just ignored.
So the readOnly setting seems to be doing more than just earmarking the device as a sensor. Also those options that get populated are screwingh things up.
Compare the two REST responses below:
DateTime formats ok when Link removed
{
"link": "http://localhost:8080/rest/items/Raining_since",
"state": "2021-12-17T22:23:27.841547+0000",
"stateDescription": {
"pattern": "%1$tl:%1$tM %1$tp",
"readOnly": false,
"options": []
},
"editable": true,
"type": "DateTime",
"name": "Raining_since",
"label": "Dry/Raining since",
"category": "time",
"tags": [
"Point",
"Timestamp"
],
"groupNames": [
"ZWaveNode039AeotecZWA008DoorWindowSensor7"
]
}
DateTime does NOT format ok
{
"link": "http://localhost:8080/rest/items/Raining_since",
"state": "2021-12-17T18:26:44.974284+0000",
"stateDescription": {
"pattern": "%1$tl:%1$tM %1$tp",
"readOnly": true,
"options": [
{
"value": "OPEN",
"label": "Open"
},
{
"value": "CLOSED",
"label": "Closed"
}
]
},
"commandDescription": {
"commandOptions": [
{
"command": "OPEN",
"label": "Open"
},
{
"command": "CLOSED",
"label": "Closed"
}
]
},
"editable": true,
"type": "DateTime",
"name": "Raining_since",
"label": "Dry/Raining since",
"category": "time",
"tags": [
"Point",
"Timestamp"
],
"groupNames": [
"ZWaveNode039AeotecZWA008DoorWindowSensor7"
]
}
Yes Bob, exactly same for me, it fools you into thinking it has implemented the item update, but promptly reverts back to what it was…
Rich, Ross and Bob,
Despite all our combined expertise and skills, I don’t think we are ever going to solve this formatting anomaly, let’s be honest.
I still use Habpanel on my iPad display and have posted a few screen shots of the set up to remind us how simple and elegantly a display could be and still can be achieved… note that in these pics, I deliberately deleted the Item metadata pattern (since it’s being blithely ignored in OH3 UI) and let Habpanel do some simple parsing on the raw time stamp.
I would also remind us how all this torture and fuss so far was obviated in the Basic UI + Sitemap with 2 lines code. Ah yes…the good old days…
Actually after sleeping on it, my revised theory is that a “string” channel is going to return the DateTime in a “string” format. OH doesn’t know what to do with the pattern on a string. I was going to try something with an On/Off switch later today. Don’t know how to fix it, but I think it might be that IMO (this minute anyway)
Bob
Bob I think you you mean a String-Type ITEM, not a channel?
We have no control of the channels offered by the device, just the Profiles we apply.
I actually already tried a String Type Item and still got the same stubborn unformatted date-time raw info showing up in OH3 … BUT interestingly, Habpanel wasn’t able to make sense of the data then or to parse it like my previous screenshots. Dunno if this helps the mystery…
I’m guessing it comes from assigning device COMMAND CLASS to specific descriptions like sensor_door. Somehow somewhere else, sensor_door gets defined with options like (English - open/closed, German auf/zu) etc.?
Assuming you’re still talking about the door sensing channel, it is not a trigger type (event type) channel. It’s a state updating channel, you would use profile timestamp-update or more likely timestamp-change
After some trying. I realized that too.
I still think that part of the problem is it is a string (or boolean) and so the DateTime comes back as a string, but I defer to you on if that could be an issue
I do think the door sensing channel is in the Alarm CC. From the class documentation;
/**
* Handles the Alarm/Notification command class.
* The event is reported as occurs (0xFF) or does not occur (0x00).
and
/**
* Z-Wave AlarmType enumeration. The alarm type indicates the type of alarm that is reported.
*/
@XStreamAlias("alarmType")
public enum AlarmType {
GENERAL(0),
SMOKE(1),
CARBON_MONOXIDE(2),
CARBON_DIOXIDE(3),
HEAT(4),
FLOOD(5),
ACCESS_CONTROL(6),
BURGLAR(7),
POWER_MANAGEMENT(8),
SYSTEM(9),
EMERGENCY(10),
CLOCK(11),
APPLIANCE(12),
HOME_HEALTH(13),
SIREN(14),
WATER_VALVE(15),
WEATHER(16),
IRRIGATION(17),
GAS(18),
PEST_CONTROL(19),
LIGHT_SENSOR(20),
WATER_QUALITY(21),
HOME_MONITORING(22);
Bob
I do not know in OH3. Logic says it should be alongside ‘pattern’ metadata.
Perhaps we completely misunderstand the process, and instead the Item has no options metadata - when it is requested for UI purposes it goes off and fetches it from the linked channels every time. That would be a rubbish strategy (which of multiple channels?) but as we already know, this whole area is poorly planned.
Additionally, I do not have Denis’ device, but with the Sensative the channels are;
<channels>
<channel id="sensor_door" typeId="sensor_door">
<label>Door Sensor</label>
<properties>
<property name="binding:*:OpenClosedType">COMMAND_CLASS_ALARM;type=ACCESS_CONTROL</property>
</properties>
</channel>
<channel id="alarm_tamper" typeId="alarm_tamper">
<label>Tamper Alarm</label>
<properties>
<property name="binding:*:OnOffType">COMMAND_CLASS_ALARM;type=BURGLAR</property>
</properties>
</channel>
<channel id="battery-level" typeId="system.battery-level">
<properties>
<property name="binding:*:PercentType">COMMAND_CLASS_BATTERY</property>
</properties>
</channel>
</channels>
OpenClose Channel: DateTime Format problem (pattern ignored)
Battery channel: DateTime Format correctly with pattern
Hope this helps
Bob
Folks,
We really aren’t getting anywhere here. My posted Item REST API code for the scenarios showed the differences and the effect of the ‘linking’ and we are no closer to diagnosing or fixing the issue. Some files we can’t even locate and others defy us when we do edit them they just bounce back to the previous values! What more can I or Bob do? Rich has even gone quiet haha, so maybe he has given up too haha.
The culprit HAS to be the OH3 UI system and its inability to deal sensibly with Items & Channels & Formatting. I think worrying about Command classes is a red herring. Let us remind ourselves again that the simple Basic UI of OH2 has no problem at all dealing with this particular DateTime Item, as we speak, even though it has all these options embedded along with the readOnly set to true. Basin UI & Sitemap is able to respect the format pattern & implement it! Even old HabPanel could cope! If Basic OH2 UI can deal properly and format it, then it’s NOT the Item/Channel but the new (inconsistent) OH3 UI. This is a logical conclusion. I don’t think we can fix here a core fault/flaw in OH3, the developers need to be involved. We will just be spinning in circles here otherwise!
This problem has been present in OH3 for a year now. It’s no good getting excited about an overnight fix. None of the information reported here has been added to the Github issue #2037 oustanding since December last year, although I don’t think anything truly new has been learned.
I didn’t feel like this was a UI issue. I thought the UI is doing what it is being told to do. I was wondering if core was the place to raise this issue. The issue Rossko mention above here is about hysteresis profile getting buggered for same reason, with as he notes is over a year old. And just as the op in that issue, I’ve found a workaround (unlink timestamp profile and let little DSL rule set timestamp). I just feel it makes timestamp profile hamstrung by no formatting capability
Hi Ross, I’m not really expecting a quick fix tbh. I didn’t know it has been present for the last 12 months… it’s a pity that this wasn’t mentioned before now… so we really wasted our time here, especially if you are now saying that 'nothing new has been learned’!! I wouldn’t have bothered with all that digging and generating of REST files etc if I had known! Since I’m not familiar with Github I’ve no idea how to chase that up and tbh I’ve no appetite to do it.
I’m so frustrated with this escapade! 
I can’t add anything new or more to this issue. NOBODY seems able to diagnose or fix it.
Hi Andrew, does anybody understand at all why OH2 & Basic UI & Sitemaps have NO problem dealing with this DateTime Item with its Timestamp profile (as I posted earlier)?
I don’t think it’s to do with the Profile. Rather it has to be the core/UI or whatever of OH3 is the culprit.
Sure.
The sitemap Text widget doesn’t even consider Item options, inappropriate or not.
It does consider the pattern, and you were able to successfully override that in your sitemap widget definition.