I have just migrated to OH4 and I have a problem with the stepper on my modbus thermostats that I did not have on OH3.
When I try to change the temperature I get the following error
2023-09-23 15:47:01.136 [WARN ] [nal.profiles.ModbusGainOffsetProfile] - Cannot apply gain ('0.1 °C') and pre-gain-offset ('0') to state ('23') (formula '23'/'0.1 °C' - '0') because types do not match (towardsItem=false): Cannot process command '23', unit should compatible with gain
2023-09-23 15:47:01.296 [WARN ] [nal.profiles.ModbusGainOffsetProfile] - Cannot apply gain ('0.1 °C') and pre-gain-offset ('0') to state ('24') (formula '24'/'0.1 °C' - '0') because types do not match (towardsItem=false): Cannot process command '24', unit should compatible with gain
2023-09-23 15:47:01.424 [WARN ] [nal.profiles.ModbusGainOffsetProfile] - Cannot apply gain ('0.1 °C') and pre-gain-offset ('0') to state ('25') (formula '25'/'0.1 °C' - '0') because types do not match (towardsItem=false): Cannot process command '25', unit should compatible with gain
These are serial-mobus thermostats, I apply a gain of 0.1 °C.
Have the same problem here, with textual item definition. Seems to be an incompatibility between tthe gainOffset profile of modbus and the unit handling in openHAB 4. @ssalonen , are you still maintainer of the modbus binding? If yes, it would be great if you could have a look at this.
I will have try to have a look at it as soon as I have some time. For the moment, the workaround stated by @JonasF works also for me, but I had to restart openHAB after changing my item definition file for the changes to be recognized.
No, it is not related to this, this is something different.
The UI stepper does not support sending units in commands, slider and knob do neither. Before introducing unit support everywhere it is needed in the UI, I would rather vote for having the openHAB server expect that a command without unit has the (configured) default unit.
I guess issue comes from the changed unit handling of openHAB core.
States are converted to the item unit before the state is set, for plain Number items units are stripped, DecimalType updates to dimension items are considered to be in the configured unit, incompatible units are rejected.
Commands are handled the same as states, the unit of QuantityType to a plain item is stripped, the item unit is added to DecimalType if there is a dimension, incompatible units are rejected. In contrast to state updates, the unit for commands is NOT converted.
In this case here, a plain number (i.e. DecimalType) is sent to the Item, so I would expect the unit to be added before that command is handed over to the profile of the ModBus binding. Or do I misinterpret something here?
@florian-h05 , coming back to this myself now that I have updated openHAB to 4.1.2.
When clicking Stepper plus or minus button in MainUI, I am seeing it injects command with Decimal payload (not Quantity!)
Is this an regression?
[TRACE] [openhab.event.ItemCommandEvent ] [org.openhab.core.io.monitor] - Received event of type 'ItemCommandEvent' under the topic 'openhab/items/KitchenTemperatureSet/command' with payload: '{"type":"Decimal","value":"5.5"}' [INFO ] [openhab.event.ItemCommandEvent ] [org.openhab.core.io.monitor] - Item 'KitchenTemperatureSet' received command 5.5
Item KitchenTemperatureSet is of type Number:Temperature with no unit metadata. I also tried to add the unit metadata, but the results are the same.
This is exactly the thing I talkes about in this message:
Can you please read the citation from pull request above? I think the behaviour you described is a bug, and expect to assume the Item‘s unit when sending a decimal type command.
This is also said in the PR description:
the item unit is added to DecimalType if there is a dimension, incompatible units are rejected.
E.g. in the evcc binding, I have implement additional handling for DecimalType commands, which migitates the issue.
Commands are handled the same as states, the unit of QuantityType to a plain item is stripped, the item unit is added to DecimalType if there is a dimension.
That’s what UI does as it’s not unit-aware (it just knows about basic data types like string and decimal).
There’s no need to send the unit, OH core takes both.
So you can send either a plain number or a string with number+unit.
PS there’s still display problems incl. a bug so you eventually may not see feedback in UI after clicking, but the commands are sent.
I’ve been using it like that in many places. Have not checked if it’s really DecimalType being sent but QuantityType it’s not for sure.
I was referring to this but didn’t recall it was fixed meanwhile (thanks and sorry).
There’s still this one open, though not really closely related to this question here.
I will also provide more info, there is clear regression for me…same profile, same item (number with quantity) and same MainUI starts to act differently
Basically, when commanding item vis UI, the profile is seeing plain decimals, not quantitype like in the past
Well OH4 like any major version came with some - documented - breaking changes, UoM handling being one of those.
So while it may mean you need to adapt stuff, it’s not a regression.
(do you have to after all ? UoM items now take both, with and without unit)
Yeah I get it that there were some changes… but I still find this particular thing unexpected
I will have to reproduce this minimally to make it more clear. Now it looked like the unit is lost, and profile would get (when commanded from ui) only Decimal, not the Quantity.
Well, reading at least about about breaking changes should be part of any upgrade preparation, check back with the OH4 release notes.
And I’m not getting what’s wrong with that.
As said you can send commands with and without unit so this particular thing/change shouldn’t be breaking anything, should it.
I tested with fresh install of openHAB 3.4.4 and 4.1.2, and I could not reproduce this now.
Now the stepper buttons result in QuantityType commands towards the Number:Temperature (as expected), not DecimalType (as the error message indicated with my other install)
EDIT: I can also reproduce the issue with plain REST calls, so UI is not to blame… There’s something else that is different between my 4.1.2 installations.
I will further check what could explain the difference…
OK, in my “lab test” I actually used Magic thing which is not exactly the same. I think I found the root cause for the behaviour
I debugged live instance of 4.x series (4.1.1, I suspect the same happens with newer version), Number:Temperature linked to modbus:data number channel and found out the spot where the quantity command is stripped from its unit –
So with 4.x, openHAB no longer passes the quantity with “plain Number” channels, even when the item might have the quantity configured. Modbus gain offset profile was banking on receiving the original command, so that it can do unit-aware conversion to raw number.
The CommunicationManager strips the unit and sends DecimalType if the channel has the accepted item-type Number, it adds the item-unit if the dimension of the item and the channel are the same. Commands with incompatible dimension are rejected. “Guessing” a unit based on the channel type when the item is dimensionless has been removed as it is confusing.
This is once again perhaps issue to bindings like modbus, mqtt etc which work with these “generic” channels, not having specialized Number channels for all the dimensions…
I can see how the intent is good but it also works against the idea where one uses profile to make things “compatible”. In this case, the profile is converting scaled modbus data (e.g. value of 35 encoded as 16bit Two’s complement) to numbers with unit (3.5 Celsius).
There are a number of new things that recent changes to Profiles have made possible that are not accounted for in MainUI. In particular the ability to change the type of the Item from a Number to a Switch (for example) which, prior to 3.2 (maybe even as recent as 3.3) was not possible.
