Binding improvements - Best practice

Development Add-ons
1

Hi,

I’m thinking about doing some minor improvements on the ComfoAir-Binding and wanted some opinions on a few things where I’m undecided beforehand.

  1. as mentioned in an other thread (Migrating addons to v4.0 - list of necessary changes available?) the way to go is to support DecimalType AND QuantityType for Number channels. AFAIR, sending a value with unit (QuantityType) to a plain Number channel should work out of the box in terms that the unit is just stripped. So basically I would just have to make sure, that sending a plain DecimalType is supported by Number:<dimension> channels, right?
  2. Most/all state patterns for Number:<dimension> channels used in the binding’s thing-types.xml have %unit% set. Is this still the way to go after the UoM changes for OH4 or should a dedicated unit be used instead (or no predefined state description at all)?
  3. When does the use of UoM make sense? There are some channels (mainly time-related) that do not use UoM yet as using any other unit than the default would not make much sense IMO. E.g., the filterWeeks channel (to set the “lifetime” of the filter between changing) uses weeks internally, so using, e.g., hours on item side makes not to me but rather creates a wrong impression of accuracy as it has to be stripped to full weeks internally. But this may be just my personal impression and users should be allowed to display and work with any unit they like… So should we use UoM in bindings wherever possible?
  4. Is there a way to set min and max values for UoM channels? There are a few channels that could use Number:Dimensionless but they have other limits than 0%..100%, so even if the limits are just used in UI, I would like to make use of them wherever possible.
  5. I couldn’t find a unit for rotational speed (i.e., RPM) even though it seems quite common to me. I could try to create a PR to but I’m not sure about the dimension: IMO it belongs to Frequency, but it could also be a new RotationalSpeed dimension (which would probably better fit for angular velocity like rad/s as well).

I would be happy for any advices!

BR Hans

2

  1. IMO UoM Numberchannels should accept and send QuantityType and plain Number channels should accept and send DecimalType. And in general the correct item-type should be linked. I’m currently working on a profile that allows adding/removing units if necessary. Number items currently accept both, a plain item strips the unit, a dimensional item adds the item’s internal unit. If the channel is plain Number, the unit is stripped (if present), if the channel is dimensional Number the unit is kept, if no unit is present, then it could be that a DecimalType reaches the channel.

  2. %unit% is fine for the state description. BUT: the unit in this case will NOT be the unit that is sent by the binding, but the unit set for the item (either the system default or the metadata unit. There is a system default for every dimension.

  3. IMO yes. Use UoM where possible, at least for new channels. For existing channels, it should be decided on a per-case basis if the benefit of UoM is higher than the potential issues that could be created.

  4. Yes, the same way as for others. There is a PR for proper conversion (Convert units for bounds when compiling full state descriptions by ccutrer · Pull Request #3132 · openhab/openhab-core · GitHub) which still needs review.

  5. RPM is the same as 1/min, which is indeed a frequency. You can just add a unit for that instead of creating a new dimension.

3

Thanks for your reply, Jan. I will see what I can implement.

  1. Then it should be fine with properly handling DecimalType on dimensional Number channels.
  2. IMO that’s preferred anyway to either use the system default or the metadata unit (which has to be set by the user, if I understand correctly?), rather than imposing the binding developers will on the representation.
  3. OK, will try to do so then. If my assumptions on 1. are correct, supporting UoM on current plain Number channels should affect existing configurations, but I have to think about it and test.
  4. Good to know that this is being worked on.
  5. Will try to create a PR for the unit. I’m just not yet sure, what the correct symbol should be: RPM, rpm, 1/min, or min⁻¹. Personally, I think I’d prefer the last one.
4

I would vote rpm, since that’s the layman’s term. This is analogous to openHAB using mph, rather than mi/h.

5

Heh, looks like it’s already done: [UoM] add unit rpm for rotational frequency by boehan · Pull Request #3616 · openhab/openhab-core · GitHub. Thanks! I actually already use “rpm” without realizing it wasn’t a supported unit yet.

1 Like