Dimensionless State Description Pattern %unit% vs rpm, ppm, %, etc

With the new unit metadata, its seems that the best practice is to define the state description pattern within the thing.xml using the %unit% to inform the core of the actual units (once the unit metadata is set). Is this correct? If so, the drawback is when the user adds the item, it will not properly display until the unit metadata is set. Are there any plans to allow the unit metadata to be set in the thing.xml file?

Thanks!!

	<channel-type id="avgSaltLevel">
		<item-type>Number:Dimensionless</item-type>
		<label>Average Salt Level</label>
		<description>Average Salt Level</description>
		<state pattern="%d %unit%" readOnly="true"/>
	</channel-type>

vs

	<channel-type id="avgSaltLevel">
		<item-type>Number:Dimensionless</item-type>
		<label>Average Salt Level</label>
		<description>Average Salt Level</description>
		<state pattern="%d ppm" readOnly="true"/>
	</channel-type>

No, this option was explicitly excluded.

Maybe.

The new unit metadata controls the actual state of the Item. If I define unit=°F and the Channel delivers °C, the value will be converted to °F before the Item is updated. Therefore the value saved to persistence is °F, when it gets restoreOnStartup it gets restored as °F, and the value returned by the REST API is °F… The unit metadata controls the Item’s state. If the Item does not have unit metadata, the system default for that UoM type is used (e.g. for Dimensionless it’s ONE).

Now, the State Description Pattern only controls how the Item is displayed in MainUI.

My understanding is that it should be possible for the binding to push a state description using the desired unit (e.g. <state pattern="%d ppm" readOnly="true"/>). But that’s only going to change how it appears in MainUI and no longer will it change the state carried by the Item.

Therefore, as a binding developer, I’d recommend always document in your readme the units delivered by each Channel. You definitely have an option to provide a state description pattern with that unit defined (instead of %unit%). That certainly makes a lot of sense for Dimensionless.

In other cases though it may still make sense to push %unit%. For example, a Number:Length you may want to show the value as an integer %d but let the user select the actual units (or accept the system default).

I’m not sure if this answers your question.

Yes, that answers my questions. Thanks Rich!

Do you have a reference to that discussion? I’d be interested in the rationale for this decision, as AFAICT this negatively impacts UX (especially for dimensionless numbers), since there’s no way for binding or core to do The Right Thing™. The binding knows it wants e.g. percent for humidity values or ppm for CO2 levels, but still (IMO pointless) user intervention is required to set those units.

It was discussed at length in the issue that lead to the reworking of UoM. RFC: Change Number item type for improved UoM handling · Issue #3282 · openhab/openhab-core · GitHub. It was also discussed on the various PRs that fed into and were spawned from this issue.

From a UX perspective, the binding can still set the state description pattern. It’s only in cases where the user want’s the actual Item’s state to be different from that that the user needs to intervene.

And a counter argument can be made for other units. For example, why should I have to take pointless intervention to ensure that my Number:Temperature Items are always °F? This is a situation where there is always going to be some population of users who are going to be unhappy and forced to take action. The only argument is which users get forced to make the intervention.

Fair … in the Number:Dimensionless case it’s just all users :wink:

The main scenario where I noticed that issue is diagrams (both sitemap charts and MainUI’s ‘Analyze’ feature). State description doesn’t help you there, and the latter is available in the default setup…

Edit: reading this comment in the issue discussion (thanks for the link!) I see I’m preaching to the choir here as far as you’re concerned :wink:

Yes and no. Just as many end users are using temperature, pressure, and length UoMs and if the binding pushes metric or imperial it’s a problem.

My understanding is that the plan was to make charts unit aware.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.