Channel Details polling. Smal validator issue: Polling Period 2147483647 Value must be less than or equal to 86400.

[FranzSchi]

In case that "do not poll" (2147483647) is set as value the Validator complains about Value must be less than or equal to 86400.

[cdjackson]

I think this is a bug in the UI - possibly introduced in the latest updates.

@florian-h05 any thoughts. I've just spun up a test instance of 5.2 snapshot and I noticed that options are not shown, when options outside of the min/max should be shown.

[cdjackson]

@FranzSchi why do you say "do not poll" is an option? I just looked at the configuration for this definition and it doesn't seem to have such an option.

This is the definition -:

    private static final Integer POLLING_RANGE_MIN = 15;
    private static final Integer POLLING_RANGE_MAX = 86400;
    private static final Integer POLLING_DEFAULT = 900;

        parameters.add(ConfigDescriptionParameterBuilder.create(CONFIG_POLLING, Type.INTEGER)
                .withLabel("Polling Period").withDescription("The time period in seconds between subsequent polls")
                .withDefault(POLLING_DEFAULT.toString()).withMinimum(new BigDecimal(POLLING_RANGE_MIN))
                .withMaximum(new BigDecimal(POLLING_RANGE_MAX)).withAdvanced(true).build());

@florian-h05 my comment above still stands, but I had intended to double check before I raised it and it seems I might have linked this issue to something else I've seen. Please disregard and I'll raise an issue on the web repo if I confirm the issue...

[FranzSchi]

Hello,
@cdjackson : No "do not pull" its not an option but i guess the max value is entered to avoid polling i guess.
Simply said i guess the real max value is larger than the validator in the gui.

[florian-h05]

That's bit of a weird situation for the UI: It should provide an input for a number and provide options for it, while at the same time it is asked to enforce min/max boundaries. What should it do now? Ignore the boundaries and allow the option or follow the boundaries?

[cdjackson]

There was a discussion on this many (many!) years ago - probably ESH days. We agreed back then that options could be outside the min/max - this is to allow a system where you have (for example) and allowable range of 0-100, but a value of 255 disables the feature.

So the UI should allow values between min/max, and any value defined in an option.

I hope that is what you are asking?

[cdjackson]

I see this is actually documented in the OH docs -:

https://www.openhab.org/docs/developer/addons/config-xml.html#xml-structure-for-configuration-descriptions

[florian-h05]

Okay. Can you please report this as a bug? We use the built-in validation of <f7-list-inputY which I guess doesn't support this, so we have to build validation ourselves.

[cdjackson]

Will do - I just want to check a few things first, but will do that tonight...

FYI (off topic) I will probably take another look at the firmware update stuff in the UI at some point - I've been playing with that in the zigbee binding all weekend....

[cdjackson]

openhab/openhab-webui#3777