Rich, some progress/insight on the issue but not solved.
I added a Metadata ‘Default List item widget’ of flavour ‘Default-oh-label-item’, there was no progress until I UNLINKED the entire ‘Raining_since’ item from the channel and suddenly the properly formatted time appeared!
However, it stays frozen like that despite further changes because it’s unlinked.
So the Pattern managed to do its function on the item display as soon as the item was unlinked. It’s useless like this of course, but it might shed some light on why the properly formatted time is ‘hidden’/‘overridden’ by the channel profile until the moment the link is gone. It somehow caches and converts the last instantaneous value.
Screen shots below.
Notice:
Pic 1, channel is now unlinked from item. Correct format evident on top of item header viewed from Model perspective.
Pics 2 &3, correctly formatted time appears on both the metadata widget AND the UI Card.
The channel linking process has a feature (in my view poorly designed) where the binding can ‘suggest’ - in practice, silently force - a suitable pattern into metadata.
That should happen only once, at linking time.
You should be able to hand-edit a more suitable pattern after that one-time action.
Clearly that can lead to an issue where a switch type channel is linked to a DateTime Item, and a ‘switch’ suitable pattern is forced on the DateTime.
Open issue -
Unrelated to that -
The timestamp profile itself had a weird bug where it kept forcing Item update if something else changed it - such as you might get when linking two timestamps to same Item.
That one at least has been fixed recently -
but I wonder if an unnoticed effect of that was also re-forcing target Item pattern.
EDIT - ah I was just reminded of a nasty consequence of the ‘link forcing a pattern’ strategy. A binding may also suggest ‘state option’ metadata. e.g. a motion sensor switch sets [ON = motion, OFF=idle]. That is really going to screw up when used with a DateTime. You might check your misbehaving Item(s) for that metadata, too.
And that metadata widget has a code tab. Clicking on the code tab shows some YAML. I need that. Especially if it’s not working. Looking at one that is working for you and one that is not would also be informative if you still have one that works.
If you have the metadata still on the Item, then yes, the YAML will still be there. If you deleted that metadata then yes, there will not be any.
Navigate to the Item
Click on “Add Metadata”
Click on “Default Stand Alone Widget” or “Default List Item Widget”
You now see a form where you can customize the widget that get’s shown in that context (stand alone on Pages and at the top of the Item’s page, list item is how it appears in the cards on the location page, for example). There will also be a “Code” tab in the upper right. Clicking on that will show the YAML for widget. A nice and concise version of what you did through the form on the “Design” tab.
Screen shots are not all that useful but the YAML is very informative.
If you don’t have a custom widget assigned to the Item, then that is likely one of the differences between the one that worked and the one that is not working.
This is an interesting statement. I know that Bindings can provide their own formatting for how Items are displayed, maybe the Profiles can too.
That could be a source of difference and perhaps even point to a bug in the Timestamp Profile. Though it works as expected for me.
Yes but there really isn’t enough detail or precision in the detail provided for me to do it. Everything I’ve tried works for me. That’s why I need all the details. This is the first mention of a Profile. Those sorts of details matter.
Not when you are responding from a phone and have presbyopia. Also, I often can’t copy and paste from a screen shot. That’s why I need the YAML.
Yes. I’ve a door contact. I linked a DateTime Item to it using the Timestamp on change Profile. I modified the State Description pattern to %1$tm-%1$td %1$tH:%1$tM and I see
As I’ve said, the straight forward approach works just fine for me. So I need to find out what’s different between your config and mine
This doesn’t make a whole lot of sense to me. It is true that some binding developers can specify their own state pattern for Items. And I think it may even override your State Description pattern (for which I’ve complained). But that would apply here. The Profile is completely transforming anything coming from the binding so all that should be lost.
Oh yes, now I see it. If the binding is forcing something like %s then you’re just gonna get the default date time formatting no matter what you do.
@denisdmenace, to get that, probably the easiest and most comprehensive thing to do would be to navigate to /var/lib/openhab/jsondb (assuming this is installed on Linux) and open the file with “Metadata” in the name. Post all the entries that are associated with the non-working Item. An entry will look something like:
Thanks for all your effort on this.
Ok I attach YAML code for the bits you want. You mentioned about working/not working. It has never ‘really’ worked except when the item is unlinked and thus that is only a frozen moment in time.
Also, I attach the jasondb stuff. In fact I’m on a Mac which is Unix, not Linux, and the file was nowhere like you mentioned…found them in the userdata/jasondb/ folder (directory in unix speak) and the one of interest was org.openhab.core.items.Metadata.json
The YAML code areas are almost empty. The widget one has effectively nothing.
Noooo haha… … this is all with it NOT working, as you can see the raw unformatted DateTime stuff in the widget header. I’ll try do the jasondb for the unlinked mode so, good idea.
Could you use the REST API (“API Explorer”) to examine your Item, with and without link? That should give us a complete ‘live’ picture of what the system thinks it is about at that moment.
Sorry Ross, I’m not sure how to do that exactly… I see Developers tools and an API Explorer tab but all I see then are lists of commands…I don’t know the procedure, sorry.
Breakthrough!
Hi Rich & Ross,
It occurred to me this morning to try linking my ‘Raining_since’ item to a totally different item channel… chose my Fibaro FGS212 Relay switch for my Hall lights. The time stamp formatting worked perfectly and followed the hall light being turned on & off!
So after me cursing OH3 it would seem that the problem is (unfortunately) connected with the particular brand new Aeotec Z-Wave ZWA008 Door/Window Sensor 7 that I’m using to pick up the switching state of my external rain sensor.
This doesn’t totally resolve the problem except it puts the focus on a particular Wave device not playing ball. Other users had problems so there may be some pattern with devices that don’t behave well. I don’t know what my options are now for my rain sensor or whether ye have any suggestions to get to the core of the issue.
Once again, many thanks for your time & patience.
OK, I can confirm this is caused by the timestamp on change profile.
After reading all the above I realized both DateTime items I was trying to get to work were DateTime items set by timestamp on change on Zwave door contacts (two different brands). So I made a test button switch item. Then I made a test DateTime item. Then I wrote a little DSL rule to update the test DateTime item when test switch item gets toggled and put format in State Description metadata and… it works
Yes, I think both @denisdmenace and @Andrew_Rowe’s most recent posts confirm we are seeing the same problem as the issue @rossko57 posted in #22. I think it would be helpful if you went and posted these additional examples that show how it is indeed a problem.
Maybe if we can get enough reasons for why this is a problem we can get to a solution. I’ve always been a little down on the bindings thinking they know better than the users on how they want an Item displayed and used in the first place. But they definitely shouldn’t do so in a way that breaks other parts of OH.
Hi Andrew that was a good test you did. So we know that at least 3 brands (2 for you and mine) of Zwave door contacts are interacting badly with the ‘timestamp on change’ profile. However, the profile and the successful formatting, worked perfectly for the Fibaro FGS212.
So to be clear in my mind, the ‘Bindings’ that Rich refers to are the device-specific ones rather than the Zwave binding itself? Thus some devices and their bindings are playing different to other devices/bindings with regard to Timestamp?
What can be done?? We have no control over manufactured devices. Is there anyway OH can be tweaked to ignore/block ALL binding ‘suggested’ formatting and allow the user (who probably knows better anyway) to dictate his own formatting?Maybe Profiles are not such a good idea at all? Just have State Description Patterns & Maps?
Right now, using a rule (like in Andrew’s test) to watch for changes & post updates to a virtual item seems the only option albeit rather clunky as an overall strategy.
Ultimately it is how the device is configured by the binding. Given the way Zwave works I would not be surprised if this is captured in the database entry for the device. Though it could just be as simple as “all Items of type Foo get this default state description” too. But ultimately it’s the binding that doing the injection of the state description that is causing the problems.
It’s definitely the Zwave binding in this case. It’s not the devices themselves. They don’t know anything about openHAB and openHAB state descriptions. Other bindings, e.g. MQTT, do not supply a default state description. Those don’t have this problem.
So either:
the Zwave (and all other bindings that do this) needs to be modified to not supply a default state description
maybe the database entry for the device in the Zwave binding needs to be updated to not supply a default state (assuming that’s how it works)
OH core needs a way for users to override the default display state provided by the binding.
Once the Link is created I think you can modify the binding supplied state description through the REST API or by manually editing the Metdata file (when OH is off).
But the best thing you can do right now is to comment on that issue.
Eliminating Profiles isn’t an option, not least because what they do cannot be done with just the State Description Patterns and Maps. For example, how do you transform a CLOSED to the *current" date and time using a map? And even if you could, how can you use that in a Rule?
I’ve tried to tell you that this is not the profile’s fault.
The underlying problem is that a channel of one type is linked to an Item of different type, and the linking process brings some baggage that does not “fit” this mis-matched target Item.
None of the info shown so far shows exactly what that baggage is.
It would be a help to look at the metadata on the “normal” Item also linked to same channel, where it is actually useful. Then we can see what also gets thrust at the DateTime Item.
Hi Ross, can you elucidate a little on your understanding of profiles for me? My understanding from reading up in the openHab documentation… “one Channel is linked to several Items it also will have several profile instances, each handling the communication to exactly one of these Items” is they operate on the link between a channel & item. Their job is to link a channel of one type to an item of a different type. Thus isn’t it their fault??
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.
Link a Channel from a Thing to an Item
a. As part of the Linking, some bindings will inject a default state description for that Item. That appears to be happening here. But as far as the binding knows, it’s a Contact Item.
Apply a Profile to the Link, in this case Timestamp which will go to a DateTime Item. But at this point, the binding has already injected a state description to the Item assuming it’s a Contact Item.
OK, that’s setup. Now for processing an event.
A. Device reports the event
B. Binding receives the event and passes it to the Channel
C. Channel passes it to the Link
D. Link has a Profile that transforms the event from CLOSED to the current date and time
E. The DateTime Item is updated with the current date and time.
OK, so what’s the problem? Remember back on step 4.a when the binding injected a default state description on the Item? Well the binding doesn’t know anything about Profiles so the state description, in this case, assumes it’s for a Contact type Item. Obviously the state description for a Contact Item is unsuitable to be used for a DateTime Item. But there it is.
And it appears to be overriding the State Description metadata that you set on the Item too so not only does it inject a default but you can’t override it.
The only reason the Profile is involved at all here is because the Profile allowed you to take a CLOSED event and transform it to something suitable to be used in a DateTime Item. Without the Profile, you could only ever link that Channel to a Contact Item and there’d be no problem. There also would be no Profiles and you’d have to capture the timestamp using a Rule instead.
Yes. After linking the Item to the Channel but before setting your own State Description we want to see what, if anything, the binding has injected to the Item’s metadata.
… this is all with it NOT working, as you can see the raw unformatted DateTime stuff in the widget header. I’ll try do the jasondb for the unlinked mode so, good idea.
it would seem that the problem is (unfortunately) connected with the particular brand new Aeotec Z-Wave ZWA008 Door/Window Sensor 7 that I’m using to pick up the switching state of my external rain sensor.
