As mentioned in the issue below, the tado binding has a humidity channel that exposes itself currently as a DecimalType. I believe that it should in future be exposed as a QuantityType of Number:Dimensionless with UnitHint “%”. I am looking for advice how to recode the binding so as not to break anything for existing users, but also expose the channel as a QuantityType for new users. I believe that OH has some mechanisms for migrating channels between versions, but I have never used them, so am looking for documentation or examples how to do it.
I don’t think that changing this will break things as much as one might think.
When you link a DecimalType Channel to a Number:X Item, the unit defined for that Item will be automatically applied.
When you link a Quantity type Channel to a Number Item, the unit gets dropped in the update.
So if you change the Channel Type it should be transparent to the end users either direction.
That is one of the things that was fixed in the UoM changes for OH 4. Prior to that, even if you had a Number without dimensions, if you sent it a QT state, it works would keep the unit. Number Items could suddenly become Number:X Items out of the blue.
This doesn’t really answer your question but it make the question moot in this case.
@rlkoshak many thanks for the feedback. I’m feeling a bit dim today so perhaps I can walk this through with you further?
Currently the binding returns new DecimalType(h) for the humidity where h is in the range 0…100, and in future I think it should return new QuantityType(h, Unit.PERCENT). I think the issue is that for Unit.PERCENT the default unit is Unit.ONE, so after this change, a Number Item would flip from showing 0…100 to showing 0…1?? By contrast, a Number:Dimensionless would not have worked before, but would now work with the given item unit applied.
Have you seen this: https://www.openhab.org/docs/developer/bindings/thing-xml.html#updating-thing-types
1 Like
I had not seen that. But I think it is at least part of th he solution I was looking for. Many thanks.
Correct and so the number part is still a number between 0 and 100.
No, because the unit just gets dropped. The number doesn’t get converted to a different unit first so it will still be a number between 0 and 100. It won’t get converted to a number between 0 and 1. 57 % just becomes 57.
The value only gets converted if the destination Item is a Number:Dimensionless and the unit isn’t %. Therefore your Number Items will continue to get a value between 0 and 100 with the only change being that decimal values are now allowed and the number can theoretically be > 100 though in practice never would for humidity.
Actually, since OH 4, a Number:Dimensionless would have worked too. The value would be assumed to be in the units of the Item. So if you send 57 to a Number Item with unit %, OH just tacks on the % and the Item’s state becomes 57 %.
If the user didn’t set the unit on the Item, that 57 becomes 57 ONE. No conversion takes place because there’s no unit information to tell OH what to convert from.
Here’s a table showing the combination of possibilities if I send 57 or 57 %.
| Update | Item Type | unit | Result |
|---|---|---|---|
| 57 | Number | 57 | |
| 57 % | Number | 57 | |
| 57 | Number:Dimensionless | 57 ONE | |
| 57 | Number:Dimensionless | % | 57 % |
| 57 % | Number:Dimensionless | .57 ONE | |
| 57 % | Number:Dimensionless | % | 57 % |
1 Like