openHAB 3.3 Milestone discussion

@Tuny Did you find a solution for this issue, I have the excact same problem.

I had same issue with the registers that contained writing in M2. All read only data worked fine. When reverting to M1, all is good.

No, I don’t have a solution. You might go back to M1.
At the moment I don’t need to write holding register in my production system. So for me it is not a bigger problem.
I think a change has to be done in the modbus binding, so that the “more stringent validation” does not throw an error. Somone has to create a github issue I think. I might do this tonight.
@ssalonen 4YI. Sorry for pinging you directly.

There has been no changes in the modbus binding.

“The stringent validation” is in core, perhaps there are some issues with it? @cweitkamp , I believe even this core fix is already in M2? [config] Allow String values for other Types by cweitkamp · Pull Request #2699 · openhab/openhab-core · GitHub

There should be a log message stating what is considered invalid. Usually it’s an issue with wrong thing definitions.

1 Like

@Tuny @Nanna_Agesen @Jostein89 do you see any log message indicating what parameter is wrong? (See above message from J-N-K)

EDIT: I think it might be the writeValueType, int16 should be used instead.

EDIT2: further history into why write Value types have different values than read [modbus] Write data types should parallel read types · Issue #4148 · openhab/openhab-addons · GitHub ideally we would like to alias many textual values into one, without polluting the UI

What package do I need to “debug”?
I tried this. But as far as I saw there is no more information about what is invalid.

I did decide to upgrade from 3.3M1 to 3.3M2, first on my test system (basically a Rpi3 hot spare of the Rpi4 production and then (after the steps below) on production.

  1. On the test system I had 3 three devices, luckily all the same, that had the dreaded “Handler error”.
  2. Following the idea from a previous post in this thread I tried, log:set Debug org.openhab.core, then went into the UI to update one parameter on one of the devices (was not sure what was the problem at this point) and was rewarded with a very descriptive

2022-03-09 09:49:45.092 [DEBUG] [st.core.internal.thing.ThingResource] - Config description validation exception occurred for thingUID zwave:device:f1c43721:node101 - Messages: {config_12_1=The value 1 does not match allowed parameter options. Allowed options are: [ParameterOption [value="2", label="physical toggle and Z-Wave control disabled"]]}

  1. Interesting is that the value of “1” is the default, but nevertheless I went into the Zwave DB, saw the problem. Although “1” is the default, there was no option for “1”, just “2”. Made the change. Downloaded a new XML. Added it to my existing custom zwave .jar. And Tada! (the normal process is to make the change, ask for review and in a few days the Zwave .jar will be updated)

Leaving out my opinion as to whether this “strict validation” is a step forward for OH usability and reputation, I can now sleep easy knowing the default value on this device is “strictly validated”.

Since there are hundreds of Zwave devices and the Zwave DB is community maintained, I thought to document the steps here as this is likely to occur as more folks upgrade.



Hmm the error message is buried in the logs with DEBUG level :confused:

Would it make sense that “thing status” would have the error message? It would pop up in the UI and logs. Most importantly, all configuration errors would be visible to the user the same way - there would not be distinction of “core config validation” and “binding config validation”

1 Like

In my opinion it is a step forward. Especially those using config files quite often produced invalid configurations and bug reports popped up which turned out to be user-errors. This should be avoided now. The validation was enabled early in the 3.3 development, so smaller issues like you experience can be detected and solved before the release.


Yes, it is. In the latest snapshot there is additionally is a new validation for parameter options. This might be the cause for the mentioned issue.

@apella12 I have to second @J-N-K . It is a step forward. What I see from the past issues users are talking about is the way how they got informed about configuration violations. A log message on DEBUG level might not the best choice. We can change it to be a warning instead.

On the other hand I think the UI must be the place to see more information about wrong configuration parameters. Thus I suggest to add the violation meassages to the details of the ThingStatus which are displayed inside the UIs.


I can prepare a PR for that.

FTR: Show config validation messages in thing status by J-N-K · Pull Request #2829 · openhab/openhab-core · GitHub



Followed EDIT 1, and that solved the problem.

Also had to change Uint32swap and Uint64swap to Int32/64swap :slight_smile:

Change uint16 to int16 did the trick! :slight_smile: Now I am back on 3.3M2

Great to hear @Nanna_Agesen @Jostein89 that changing the write value type made the difference.

Maintainers, how could we get this breaking modbus change to 3.3 release notes?

We could document the breaking change like this

openHAB 3.3 enforces more strict configuration validation that might invalidate previously valid textual modbus configuration. As a result, manual corrections might be needed for data things defined in things configuration file.

Previously textual config accepted “unsigned” writeValueTypes such “uint16”. These are no longer accepted in openHAB 3.3.

Replace the writeValueType as follows with openHAB 3.3:

  • uint16 with int16
  • uint32 with int32
  • uint32_swap with int32_swap
  • uint64 with int64
  • uint64_swap with int64_swap

Despite the change in parameter value, the behavior is exactly the same as before.

Note that things defined in MainUI require no change. Also note that readValueType parameter requires no change.


Does changing while still on <= 3.2 work? Then we should get people to do it now.

Yes, it works also now. There has been no changes in the binding.

Good idea to change now but I would also like to have it documented in the change log.

I’d further advise to add a more general notice to be alert for “handler errors” since the strict validation also affects the Zwave users (and maybe other bindings I do not know about). See this.

Depending on the timing, complexity and approvals simply raising the log level from Debug to Warn might be a good interim step.



Raising the log level is not much easier than the solution I presented. In fact the code is much cleaner now.


Ok, just throwing it out there. You are the expert. Cleaner code is good.