Disclaimer: I’m on Openhab 3.0 RC1 (M5 used to behave the same way)
I wanted to change reporting intervalls (40,42,43) which should be integer (input fields) but instead a radio button is shown.
Is this a binding issue or an openhab issue?
Oh, and @chris the current documentation for V3.5 allows values as low as 30 seconds where your V3.3 only allowes 600 seconds and larger.
If the configuration has changed for different versions, then we’d need to create a new database entry.
I’m not sure if they really changed their firmware/hardware or just loosened up documented restrictions, as they kept the same product number. My Device is labeled ZMNHXD1-H1S1P2 manufactured in 2020/27
so is V3.3 documentation
Anyhow, any idea on the radio button for integer value issue?
It is very common for manufacturers to keep the same device identification and add features in newer firmware versions.
Either there is a restriction, or there isn’t. If there is a limit, then it is managed in firmware. If the limit has changed, then the firmware has changed.
It’s not only common - it’s normal. Normally a device would retain the identification and just increase the firmware version if firmware is changed.
No hints?
How can I contribute here (in finding out)?
I am seeing the same issue on one of my motion sensors:
If only one option is available there is no chance to enter any values.
As this did work on openHAB2, the question is: binding issue or gui issue? @chris?
Ask the manufacturer for firmware changes.
Which openHAB version and UI?
OH3 and the Main UI may behave differently.
I am pretty sure it is a general problem and not version related.
I would think that if the UI is showing a radio button for an integer value, and it works on OH2, then probably this is a UI issue.
If I look at the definition for parameter 40, it looks fine to me and I would think it should be presented as an integer -:
<parameter name="config_40_1" type="integer" groupName="configuration"
min="0" max="100">
<label>40: Reporting on power change</label>
<description>
</description>
<default>50</default>
<options>
<option value="0">reporting disabled</option>
</options>
<advanced>true</advanced>
</parameter>
@ysc - any thoughts. I think you already fixed some things like this
I thought it works … I did not change parameters on my devices since three years, but I tried now and: it does not work 
Edit: I suspected the missing “min value” in the OP device
to cause the problem, but the parameter I showed in the screenshot for my device does have a min value and still does not work.
On the new site minimum of 0 shows up as empty. I assume limit to options only is false too.
Correct - it’s annoying and I’ve not worked out how to change this 
.
You can however see from the information above that the export into the XML uses minimum of 0.
<parameter name="config_40_1" type="integer" groupName="configuration"
min="0" max="100">
Yes that’s one of those cases of range-constraint-plus-options-that-may-or-may-not-fall-into-that-range. It was not handled properly i.e. the number field was refusing to allow values outside its range, so if there’s a min/max/step and also options, they are not enforced at all, until we find a more permanent solution.
That rendering makes me think limitToOptions is set to true. Otherwise you’d have a text field instead of this.
Please guys, I don’t want to hijack the OP thread, please discuss his issues, I don’t have any 
So, should i file a (blocking) Bug for 3.0?
You probably should file a bug but I doubt there is anything like a blocking bug for OH3.
