In respect of persistence service, I think yes. No default unit, no unit applied to retrieved data (e.g. charts and restore).
Some types (Temperature) have a system default unit, if the individual Item doesn’t get one.
Some types (Energy) don’t have a system default - so no Item metadata ‘pattern’, no default unit at all.
This really messes us up with Dimensionless types, where “no unit” is a valid unit
Nope, they hijacked it for UoM internal use as well. I think that might be a design mistake, but its what we got now.
(re retrieving 0.0)
So it might be that the whole retrieval is messed up. There are some other threads about getting null returns e.g.if the database is busy doing other stuff. Sounds similar.
That now starts to make sense. I stumbled across this on items with Number:Time and Number:Power.
I recently added initial metadata pattern to those items (via .items file) and have not encountered the issue anymore since. Now as that’s simple and language independent I’d think it’s the best fix.
PS:
then again wouldn’t be the best fix to have a system default for every type ? Metadata would still override that.
Are you aware of any openhab-core issue to reference ? Or better address this as a new one ?
I don’t know of any particular issue. I think the whole business of “default units” needs a review, to be honest. Re-using the presentation focused ‘pattern’ was a good idea to get UoM functioning in OH2 without introducing new Item properties, but I think we missed the opportunity to do default units ‘properly’ and separately from presentation at the OH3 point.
