DateTime format with OH3 items not working

[rossko57]

@denisdmenace

Their job is to link a channel of one type to an item of a different type

Does that have anything to with the state presentation stuff that is giving you the problem?

[rlkoshak (Rich Koshak)]

@denisdmenace

In the door contact case, is the contact open/close status the ONLY data delivered on that channel and hence does the profile ‘watch’ for changes and produce its own timestamp in response and deliver it to the DateTime item? Or are both status & timestamps sent out and the Profile merely filters out the timestamp changed events? I’m trying to get the correct understanding here.

Just to be clear in the answer to this question, only the CLOSED event goes to the Profile. The Profile creates the timestamp on its own.

But as @rossko57 said, that has nothing to do with the actual problem on this thread. The root cause of the problem is the State Description, not the Profile.

[rossko57]

What would be most instructive here is the JSON returned by REST API in response to a “get Item”, for each of -
Normal contact Item
Datetime that formats
Datetime that doesn’t format

[denisdmenace (Denis)]

Ok Ross, I’ll try do that, sounds an excellent idea. I haven’t used the REST API before but I’ll try figure it.

[denisdmenace (Denis)]

Super clear summary of the process I understand it much better now, thank you.

So the Zwave binding injected a default state description for my DateTime Item when I linked to the contact channel and which effectively ignores/overrides the fact that it’s NOT a Contact Item in this case and we can’t seem to insist/imprint our desired State description onto the DateTime item. Is this correct?

I wonder though how the correctly formatted DateTime ‘popped’ into view (and stayed) as soon as I deleted the channel link? Does the State Description somehow ‘regain control’ at the last instant? How would it do this if it was never successfully written into/accepted by the DateTime Item?? It must be there all the time but is dynamically overridden whilst the link is in place.

[denisdmenace (Denis)]

@rossko57

What would be most instructive here is the JSON returned by REST API in response to a “get Item”, for each of -
Normal contact Item
Datetime that formats
Datetime that doesn’t format

Ross, I have that done. Do ye want those JSON files (from the REST API tool) posted as text document files or a load of code within ‘fences’? Actually I’m not sure what fences are on the keyboard…? Sorry if silly Q

[denisdmenace (Denis)]

@rossko57

What would be most instructive here is the JSON returned by REST API in response to a “get Item”, for each of -
Normal contact Item
Datetime that formats
Datetime that doesn’t format

Here are these files! I’ve already noticed that there is a readonly setting set to true for the non-working item. I never interacted with this setting anywhere.
ALSO, there was NO METADATA WIDGET involved in these tests, just a State Pattern setting.

JSON files from REST API queries:

JSON Normal Contact Item;

{
  "link": "http://localhost:8080/rest/items/ZWaveNode039AeotecZWA008DoorWindowSensor7_DoorSensor",
  "state": "CLOSED",
  "stateDescription": {
    "readOnly": true,
    "options": [
      {
        "value": "OPEN",
        "label": "Raining"
      },
      {
        "value": "CLOSED",
        "label": "Dry"
      }
    ]
  },
  "commandDescription": {
    "commandOptions": [
      {
        "command": "OPEN",
        "label": "Raining"
      },
      {
        "command": "CLOSED",
        "label": "Dry"
      }
    ]
  },
  "editable": true,
  "type": "Contact",
  "name": "ZWaveNode039AeotecZWA008DoorWindowSensor7_DoorSensor",
  "label": "Rain Sensor",
  "category": "rainsensor",
  "tags": [
    "Point"
  ],
  "groupNames": [
    "ZWaveNode039AeotecZWA008DoorWindowSensor7"
  ]
}

DateTime formats OK - DateTime item linked to FibaroFGS212

{
  "link": "http://localhost:8080/rest/items/Raining_since",
  "state": "2021-12-17T19:13:17.134672+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 - DateTime item linked to Aeotec Contact Sensor

{
  "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"
  ]
}

Could the readonly status-true that has been mysteriously set be the problem? Could we stop OH, edit the setting in the file and restart OH?

My problem; What actual JSON file has that detail about the readonly-true status?? I have (using Visual Studio Code) opened up and looked in the following:
org.openhab.core.items.Item.json
org.openhab.core.items.Metadata.json
org.openhab.core.thing.link.ItemChannelLink.json
org.openhab.core.thing.Thing.json

I saw listings for both the Raining_since and the Door contact items in most of these files but NO MENTION of a ‘readonly-true’ parameter. Where can it be? How did the REST API find this parameter in its request?

[rossko57]

@denisdmenace

Could the readonly status-true that has been mysteriously set be the problem?

No.

The ones that don’t work have state description options. None of the supplied options will fit a datetime.

[denisdmenace (Denis)]

I don’t understand your reply, sorry. One channel link did work and one didn’t. Also, what do you mean by “none will fit a DateTime”? Sorry I don’t know what you mean or are referring to…
Also, do you know where this readonly status info IS stored so??

[rossko57]

@denisdmenace

    "options": [
      {
        "value": "OPEN",
        "label": "Open"
      },
      {
        "value": "CLOSED",
        "label": "Closed"
      }
    ]

These are options in the Items state description properties.
Te zwave binding put them there, thinking you have a Contact Item and you would like state OPEN displayed as Open. Might seem silly, makes more sense when it automatically selects language like Offnen instead. You have no choice if you don’t like, but you can hand-edit them later.

But the Item is a DateTime, its state is not OPEN and so it matches none of the supplied options.
The options failure I think stops it even getting as far as the ‘pattern’ format.
So you get the default datetime string display because in case of total failure, that’s the backup.

Try deleting (not setting blank) options metadata.

[Andrew_Rowe]

REST response for test DateTime item that works

{
  "link": "http://localhost:8080/rest/items/TimeStampTest",
  "state": "2021-12-17T07:47:05.596157-0500",
  "stateDescription": {
    "pattern": "%1$tm-%1$td %1$tH:%1$tM",
    "readOnly": false,
    "options": []
  },
  "editable": true,
  "type": "DateTime",
  "name": "TimeStampTest",
  "label": "Time Stamp Test",
  "category": "",
  "tags": [],
  "groupNames": []
}

REST response for problematic zwave door contact item without state description set

{
  "link": "http://localhost:8080/rest/items/LastBathDoorOpen",
  "state": "2021-12-17T07:40:49.585991-0500",
  "stateDescription": {
    "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": "LastBathDoorOpen",
  "label": "Last Bath Door Open",
  "category": "",
  "tags": [],
  "groupNames": []
}

REST response for problematic zwave door contact item with state description set

{
  "link": "http://localhost:8080/rest/items/LastBathDoorOpen",
  "state": "2021-12-17T07:40:49.585991-0500",
  "stateDescription": {
    "pattern": "%1$tm-%1$td %1$tH:%1$tM",
    "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": "LastBathDoorOpen",
  "label": "Last Bath Door Open",
  "category": "",
  "tags": [],
  "groupNames": []
}

[denisdmenace (Denis)]

Thanks for that clear explaination. I think you might be right!
Curiosity… as we see also in Andrew’s posting, what does this readonly-try-false setting do? Who does it prevent writing what to where ?

Back to your editing advice:
Which of the json files will I be editing? In fact I can’t find any mention of these OPEN/CLOSED label/command options etc in ANY of the JSON files I looked into!
If I (ever) find them, how much ‘deleting’ of those options do I do?.. all the words AND all the curly brackets but leave the square brackets alone?? Do I shut down OH before? Can I use Visual Studio Code app to do the business or will it have to be via the REST editor…if that’s possible? I’m getting out of my depth…

[rossko57]

@denisdmenace

what does this readonly-try-false

Read only ; this device is a contact, a sensor, it can inform you if a door is open. You cannot send it an instruction to open the door, it is not an actuator.
The binding sets this because the binding knows what sort of device it is.
It doesn’t actually limit what you can do very much - but it’s useful for a GUI to know whether to give you a graphical knob to twiddle or not.
All irrelevant here.

@denisdmenace

Which of the json files will I be editing?

None. Do this in the GUI, edit Item metadata.

[Andrew_Rowe]

Rossko got it…
I stumbled across a funny thing last night
I tried it in a widget, but I just clicked the big blue button and created a new widget
The screen shot in Post 11 showed the newly created widget. (Sorry Rich I cut off the yaml but I didn’t think it mattered because it was a newly created widget with the same yaml as any other newly created widget)
here is result

notice last line of yaml in code window

content: =items[props.item].displayState || items[props.item].state

then I edited it to this

content: =items[props.item].state

and got

Duh… still the same… so then I edited last line again and made it this

content: =items[props.item].displayState

and got this

actually last night it was a dash like so -
sort of what PaperUI would give when there was no state to show (state was nan)
I think because of

  "stateDescription": {
    "pattern": "%1$tm-%1$td %1$tH:%1$tM",
    "readOnly": true,
    "options": [
      {
        "value": "OPEN",
        "label": "Open"
      },
      {
        "value": "CLOSED",
        "label": "Closed"
      }
    ]
  }

Read only true and options OPEN or open…
so… off to find if this device in the zwave database per device is how binding decides some device not others

[Andrew_Rowe]

@rossko57

Read only ; this device is a contact, a sensor, it can inform you if a door is open. You cannot send it an instruction to open the door, it is not an actuator.

yeah but the read only is in the state description part of the yaml and in the one that works
read only - false

"stateDescription": {
    "pattern": "%1$tm-%1$td %1$tH:%1$tM",
    "readOnly": false,
    "options": []
  },

[denisdmenace (Denis)]

OK that makes sense.
Do you mean the normal GUI where we design the item metadata details? Those OPEN/CLOSE stuff don’t show up anywhere there… all I can see is how to ADD metadata parts… is it to be done in the CODE TAB of the metadata config…gawd I’m getting more n more lost…

[rossko57]

And …? As you can see from options or not-options being present on similar devices, in the case of zwave devices this is all derived from crowdsourced device entries and the crowd members have different opinions and skillsets, I wouldn’t expect brilliant accuracy, if you see an error go fix the zwave device database.

[Andrew_Rowe]

@rossko57

And …?

ok… not sure, can’t find anything in the database where options are set
here is link to device in database
https://opensmarthouse.org/zwavedatabase/947

[Andrew_Rowe]

@rossko57

I wouldn’t expect brilliant accuracy, if you see an error go fix the zwave device database.

I think the fix would be if core (or whatever) checks item type (which is in yaml) and if item type is DateTime instead of whatever (in this case contact) throws away the state description (containing the ‘forced’ state description) if a pattern is present

[Andrew_Rowe]

@rossko57

As you can see from options or not-options being present on similar devices

No… options - no options being present is from MainUI created item, created from the Thing —> channel —> add item button, picking DateTime type item and clicking ‘timestamp on change’ option
this one has options in yaml

Other item is just MainUi created item not tied to any Thing or Channel and just DateTime type and update from little DSL rule