OH 4 - Issue with writing to temperature item, due to wrong configuration or binding?

Hi all,
I have upgraded from OpenHab 3.4.4 to OpenHab 4.0.1, one of the issue I experienced after upgrade is that when I adjust target temperature of my thermostats, it send command with input value divided by 10. I read the release notes of OH4 and saw there was introduction of Units Of Measurement, however I’m not sure my configuration needs any change. What I have observed so far:

  1. When I change target temp by the physical thermostat, OH get updated temp correctly.
  2. When I change target temp by OH, it sends temp/10 to the device. For example when I set target temp to 20, it sends 2 to the thermostat.
    Below is my item configuration:
Number    WavinOfficeTargetTemp            "Office Target Temperature [%.1f °C]"             <temperature>    (gWavinOfficeThermostat)                              {homekit = "TargetTemperature"  [minValue=15, maxValue=25, step=0.5], channel="zmartmodbus:jablotron_tp150:918a900e8b:chn9e2:ManualTemp"}

What I see in the events.log when I make a change in OH:

2023-08-13 08:26:22.318 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'WavinOfficeTargetTemp' received command 20.0
2023-08-13 08:26:22.343 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'WavinOfficeTargetTemp' predicted to become 20.0
2023-08-13 08:26:22.343 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WavinOfficeTargetTemp' changed from 19.6 to 20.0
2023-08-13 08:26:34.422 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WavinOfficeTargetTemp' changed from 20.0 to 2

What I see in events.log when I make a change from the thermostat:

2023-08-13 09:53:24.757 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WavinOfficeTargetTemp' changed from 2 to 20

I’m not sure if this issue is due to the wrong item configuration or due to binding, but I did know that in the binding the conversion of numbers are made in a generic way that doesn’t seem to take care of measure of unit (I have to convert all primitive numbers to strings to make OH4 happy):

    public static State fromModbusToState(ModbusThingChannel channel, Object payload) {
        int index = channel.getIndex() * channel.getValueClass().size();
        State state = UnDefType.UNDEF;
        // logger.debug("{} {} {}", state, channel.getUID().getClass(),
        // channel.getValueClass());
        switch (channel.getValueClass()) {
        case Bit:
            state = (OnOffType) (((BitVector) payload).getBit(channel.getIndex()) == true ? OnOffType.ON
                    : OnOffType.OFF);
        case OnOff16:
            state = (OnOffType) ((registerToShort((byte[]) payload, index) == 0) ? OnOffType.OFF : OnOffType.ON);
        case Int8:
            state = new DecimalType(unsignedByteToInt(((byte[]) payload)[index])+"");
        case Uint16:
            state = new DecimalType(registerToUnsignedShort((byte[]) payload, index)+"");
        case Int16:
            state = new DecimalType(registerToShort((byte[]) payload, index)+"");
        case Uint32:
            state = new DecimalType(registersToUnsignedInt((byte[]) payload, index)+"");
        case Int32:
            state = new DecimalType(registersToInt((byte[]) payload, index)+"");
        case Float32:
            state = new DecimalType(registersToFloat((byte[]) payload, index)+"");
        case Int32_swap:
            state = new DecimalType(registersToIntSwap((byte[]) payload, index)+"");
        case Uint32_swap:
            state = new DecimalType(registersToUnsignedIntSwap((byte[]) payload, index)+"");
        case Float32_swap:
            state = new DecimalType(registersToFloatSwap((byte[]) payload, index)+"");
        case Jablotron_power16:
            state = new DecimalType(((float) registerToUnsignedShort((byte[]) payload, index) * 24 / 0.54)+"");
        case Jablotron_power32:
            state = new DecimalType(((float) registersToIntSwap((byte[]) payload, index) * 24 / 0.54)+"");
        case Jablotron_modeset:
            state = new DecimalType(((int) ((BitVector) payload).getByte(index) & 0x0F)+"");
        case Custom8_4bit:
            state = new DecimalType((unsignedByteToInt(((byte[]) payload)[index]) & 0x0F)+"");
        case Custom8_5bit:
            state = new DecimalType((unsignedByteToInt(((byte[]) payload)[index]) & 0x1F)+"");
        case Custom8_6bit:
            state = new DecimalType((unsignedByteToInt(((byte[]) payload)[index]) & 0x3F)+"");
        case Custom8_7bit:
            state = new DecimalType((unsignedByteToInt(((byte[]) payload)[index]) & 0x7F)+"");
        case Jablotron_RSSI:
            state = new DecimalType((unsignedByteToInt(((byte[]) payload)[index]) * 0.5 - 74)+"");
        case Jablotron_battery:
            state = new DecimalType((unsignedByteToInt(((byte[]) payload)[index]) * 10)+"");

However this section of code should only take care of conversion from the device to OpenHab state, so I’d be surprised that it causes the issue.

Any suggestion how to trouble shoot issue like this? Appreciate your input in advance!

If the issue only occurs if you update the item in OH, I would more guess that this is based on your widget/rule not working as expected rather than the binding.

How are you setting the 20° state? Via UI or via a rule? Maybe post this configuration

1 Like

Hi @Matze0211 : looks like this indeed has something to do with UoM. I have edited the items to the following and everything now works flawlessly:

Number:Temperature    WavinOfficeTargetTemp            "Office Target Temperature [%.1f °C]"             <temperature>    (gWavinOfficeThermostat)                              {homekit = "TargetTemperature"  [minValue=15, maxValue=25, step=0.5], channel="zmartmodbus:jablotron_tp150:918a900e8b:chn9e2:ManualTemp", unit="°C"}

I can’t explain why it didn’t work initially though. Thanks for your reply!

Yes indeed adding back in the units has indeed fixed it. But I doubt that UoM (or lack of it in this case) was the root cause of the problem in the first place. Looking at your events:

  1. received command 20.0
  2. predicted to become 20.0
  3. changed to 20.0
  4. changed to 2

1-3 are exactly what you would expect from a command. Something came back and updated the Item again after it changed to 20.0 and UoM wouldn’t do that. It would have changed the value to 2 before it ever changed to 20.0.

So whatever you the original problem is, that problem became masked by introducing UoM into the mix. But lack of units was not the root cause of the original problem.

1 Like

Discovered just today that I seem to have the same problem after updating to 4.0 (currently running 4.0.3). The item was updated locally in openHAB but not really written successfully to my modbus device (Wago 750-841). Turned on debugging for Modbus and did not even see a write attempt. For the moment I directly set the value in the device, will dig deeper into it when I have more time.

Writing coils works without problems, otherwise I would have found the problem much earlier.

Update follows.