I’m faced with a situation that I’m not sure is a bug or not, so before posting it on the issue tracker, I’d like to have your opinion.
Here are the steps:
Start a blank OpenHab 4.2 snapshot installation
Go through the initial setup with default values
Install the Astro binding
Add an “Astro moon” thing
Setup its location
Go into the model
Select Create equipment from thing
Select the moon thing
Select “Moon age in days” (phase#age) and “Moon age in percent” (phase#agePercent)
Notice how both “Unit” fields have a value, and that the default for phase#age is seconds when the description says days.
Validate the creation of the items
Once back to the model, click on the first “Moon age” item and notice that it is displayed in seconds.
click on the second “Moon age” item and notice that it is displayed as a number followed by “one” like this:
If you look at the metadata section for both you will notice that no metadata is present.
We left the default units in the creation phase, but they are missing in the created items.
If one adds the unit metadata as % for the second one, then after a while it gets a valid value with %
I tested this with 4.1 as well and it’s worse because the unit is hardcoded in the State description pattern, meaning that it has to be changed at both places at two different times.
We have already discussed the fact that a binding should be able to provide a default unit and I believe this is one more case arguing in favor of this because getting seconds by default for the moon age is pretty useless to the vast majority of users.
But the main issue here is that the unit indicated during item creation is NOT propagated to the item itself.
The metadata for unit and state description: pattern will only be created if you change it on that form. By default it shows the default but it will only create the metadata if it’s changed by the user.
There is an open issue/PR which might change this behavior in the near future, and will show the state description pushed by the binding.
However, it’s not so simple as just letting the binding push this because what happens when the Item is linked to multiple Channels? Which one wins out? What happens when a transform changes the type of the Item, or does some calculation to generate a different unit? In both of these cases, the fact that the bindings have pushed state description options have caused significant problems to end users.
Not really. The state description pushed by the binding will show days (or whatever) just about everywhere in the UI except on the Settings → Items page.
In rules they can and should be doing math using Quantities so the fact that it’s seconds doesn’t even matter. If they are not using Quantities they should probably link it to a plain Number Item in the first place.
The only places where it matters (for now, there are issues and PRs open to address some of this too) is charting, persistence, and events.log.
And if the default unit of seconds isn’t what the end users wants they can change it right there before the Item is created. In all places where an Item can be created in MainUI now, the unit is a field that can be set along with name and label and such. It gets pre-populated with the unit that will be used if the user doesn’t change it.
That’s what I was expecting too, but at least in 4.1 it did not work.
First the state description included the unit directly instead of the %unit% placeholder, and even if I changed both from one to % they were never updated and the item got created with default values.
I tried again with the 4.2 snapshot and it’s the same behavior.
Type anything you want in the Unit field upon creating the items and it won’t be set for the newly created items.
I tried with d for the first one and dB for the second one, items were created with s and one respectively.
By the way, one is not even the default value shown in the UI.
I know that and it’s not what I’m suggesting here.
All I’m suggesting is that the binding could suggest a default unit for the item, that would be used by MainUI to populate the field when the item is about to be created. With this, you keep the flexibility to be able to set whatever value you want, while there is a sensible default value that would make sense in the context of the binding.
Obviously, this would only work if the unit was correctly taken into account upon creation, but that’s another issue altogether.
I really can’t see why it’s so difficult to consider that a binding would have a good understanding of what a sensible default unit would be for a given channel.
There was a bug that got fixed on that not too long ago which should be be in 4.2. Hmmm. All I can offer is to try it in the latest snapshot and if it still doesn’t work file an issue. Maybe it only got fixed in one place and it’s still broken on this page.
All I can offer here is to comment on the PR I linked to above.
From my perspective, it’s because in the past it’s really been implemented as “binding authors know better than the end users” and it’s cause lots of very subtle problems that have taken many many hours of end user’s and forum helper’s time to figure out.
For example, I spent about 20 hours a while back helping someone who couldn’t set a state description pattern on a DateTime Item which is linked to a Channel that pushed it’s own state description metadata which included options. Because options don’t make sense for a DateTime Item the overall metadata became unusable and the end result was incorrect. The only way to override the options pushed by the binding was to go to the code tab and manually override them with a "" value. Note that this problem still exists as far as we can tell.
It stuff like this which makes me extremely cautious when it comes to bindings pushing stuff to the Items.
There is no guarantee that the type of the Item linked to the Channel is the same as the type of the Channel.
There is no guarantee that your Chanel is the only Channel linked to an Item.
When there is more than one Channel linked to an Item, there is no guarantee they are all of the same type.
If units are involved, there is no guarantee that the units used by the end Item are even the same dimension, let alone the same unit as pushed by the Channel.
How many of these do you as a binding author consider when setting the State Description pattern or would consider when setting a unit? But thanks to profiles, any of the above can occur.
I understand all the issues if the binding was to force a unit every time it pushes an update to the state.
But what has been suggested is for the binding to give a unit suggestion to be used when filling in the “create item” elements. Nothing more.
And that’s where I don’t see an issue because it is not tied to the state being pushed when running the binding, it’s all done even before the item is being created.
As for the issue you see, if it doesn’t get updated, it is a bug. I have limited time at the moment to look into it, but if confirmed it is still in the latest snapshot, I will.
Awesome !
I’ll have a look at it and may comment over there if need be.
Just downloaded the snapshot currently available here for Windows and it definitely happened just as described: set “d” for age and “dB” for “agePercent” and the item got created as “s” and “one”
I confirm there is a bug.
When you do from the thing channel → add link to item → create new item, the unit is saved correctly, but not when adding equipment or point.
