Though I appreciate a proper input validation, the user should get at least a hint on what’s failing to validate.
Homematic bridges, which have numerous config options, work fine, while Things that do not have any config options at all fail to initialize. Even when adding a homematic thing via webUI, I do not get any validation errors beforehand.
What’s the suggested way to handle these failures for the different bindings?
@mstehle and @usambara :
My report regarding the BeNext Panic Button not showing up was false alarm. That had nothing to do with 3.3 M2;
The issue was that I just did not now how to make the new Zwave definition final in the database, so it was removed automaticcaly. That has been corrected now, and @chris 
took that over in the new Zwave binding. This binding is not (yet) in the default release.
I’m not sure whether your issues are the same or related …
Regarding homematic, I assume the following change fixed the problem
Yes that should fix the issue for Homematic devices, assuming it’s the same issue I was facing. I’m not sure if this is a proper fix though, but I guess only time will tell. I have no clue why an invalid value ends up there in the first place, so if someone wants to do further investigation it’s probably a good idea to check where the invalid value is coming from and why it’s not properly translated there (it probably should be done in the HmDatapoint, however for some devices it is actually correct and doing it there breaks those).
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.
@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.
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"]]}
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.
Bob
Hmm the error message is buried in the logs with DEBUG level 
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”
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.
Followed EDIT 1, and that solved the problem.
Also had to change Uint32swap and Uint64swap to Int32/64swap 
Change uint16 to int16 did the trick! 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.