After Update to OH3.4 one issue in ruleDSL

after the Update to OH3.4 i got an error:

var YRain = (Rain_Today.previousState().state as QuantityType<Number>)
	YRain = YRain.toUnit("mm")

error msg

Could not cast 1.4 to org.openhab.core.library.types.QuantityType;

is something changed in the Syntax of OH3.4?

How maybe someone can give me a tip?

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.

No success with QuantityType<Length>.

my Item is like this:

Number:Length        Rain_Yesterday                    "Rain Yesterday [%.1f %unit%]"                              <rain>                             

Your value (1.4) is apparently missing a unit.
Rather use DecimalType in that case.

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

"Rain Yesterday [%.1f mm]"

which I think should avoid the apparent bug.

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, today %unit% is a valid pattern.
I’d call it a bug when user has followed all the rules and it doesn’t work.

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%.

Yes, that is my point. Why should it.

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.

Alright, that’s fine, that’s a presentation thing.
Now the Item has a default unit, defined in 3.4
Why doesn’t persistence retrieval work?

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.

Well, that’s news.


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.

Please see the other UoM discussion. We‘ll decouple presentation and persistence/internal state.

This was clearly just a workaround to an existing problem identified with UoM in OH 2.

1 Like