There have been changes that make it surface now with 3.4 but the problem is with your code. QuantityType<Number> is not a valid type to derive the unit from, it would need to be QuantityType<Length> or some other valid dimension.
Right, I didnât spot that. Try to remove [...] or %unit% from the item pattern definition, it possibly prevents the new UoM default unit from being applied. Or cast it to a Number first and then make a UoM item out of it in a second step.
But the whole UoM implementation and changes itâs currently undergoing is pretty complicated and still under discussion.
Thing is, thatâs a value retrieved from persistence.
Persistence service should automatically reconstruct state with a unit, before it gets to the rule.
User cannot change or influence that.
To do that reconstruction, default unit is needed.
New in 3.4, default units for all types - canât go wrong now?
Somehow it has.
This Item has no per-item default unit - the [%unit%] is a valid presentation but should be ignored for default unit purposes.
We should then fall through to pick up the system per-type default - this seems to have gone wrong i.e. a bug.
Iâm going to guess though that the historic data here was recorded as âmmâ (1/.4m daily rain seems unreasonable) and recovering the data in a per-type default âmâ would not be helpful.
The practical solution would be to update Item state description to
Well, it works in accordance with @J-N-Kâs explanation in the other thread and picks the state pattern as the new default unit on restoreOnStrartup. Unfortunately with a pattern %unit%, that isnât a good idea as that still does not give OH any idea about the unit to apply.
But I think we should not consider that a bug and change it. So far, user provided patterns arenât validated at all, thatâs somewhat by design so we must not start validating in this case, that would be inconsistent software design (and just like Rich, I hate inconsistencies).
Hence my proposal to remove the pattern. Or change it to a pattern that includes a unit (such as [%.1f mm]).
Well, itâs a pattern that prevents applying default UoM. And certainly itâs tbd what âallâ the rules you mentioned are, I would not second that claim.
Once you qualify this a bug, users will start to expect a fix for it on the software side and they often insist on getting that delivered rather than change their config, but zooming out to look at it from 25k ft the whole situation canât be resolved like that. You know thereâs no way out of the UoM mess without config or persistence data change i.e. a breaking change of some sort.
And once we remove the current functionality to derive unit from state pattern (as discussed over in the other thread), it should work (again) to use %unit%.
Because of what I explained on software architecture in my previous post.
It would be very inconsistent to apply it in one case (display pattern) and not apply it for the other one (default unit).
But it worked before 3.4
(I imagine the mechanism being that there was no default, so persistence returned just a decimal)
Shall we call it a regression, would that be okay?
I donât like neither âbugâ nor âregressionâ as both imply action needs to be taken on the software side (exclusively) which I donât see to be the right solution here.
Iâd think itâll dissolve into wellbeing once we remove that get-defaultUnit-from-statePattern âŠ
In fact it was more a bug that it worked before. Providing a default unit only for some cases was wrong, that has been fixed. The â%unit% -takes the value of the stateâ is closed to being non-breaking for those that previously did neither have a state description with an explicit unit nor a default unit.
Retrieval works, but without unit (as you can see in the error message). %unit% means âthe state knows itâs unitâ, so getUnit returns null and therefore a plain decimal is returned. If that was different before, it was a bug.
The more I think about it, it was a mistake to introduce that and it should be removed in OH4.
It was clearly established in the past that for persisted items, â%unit%â must not be used in the state pattern. I have myself changed (few years ago, it is clearly not new) all my items that are persisted to use a real unit in the state pattern.
Now that every type has a default ⊠justification for such a weird policy?
Why on earth shouldnât a user specify for display in âwhatever units it happens to be inâ. And what does that have to do with persistence, now that every Item has a default unit.