Loop(?) in PaperUI "Control" page

[MHerbst]

I have used the PaperUI to addseveral things to my OpenHAB 2 configuration (Homematic, Astro, Yamaha Receiver). At some time the "Control" page stopped working correctly. In Chrome I could see that the refresh function was activated permanently before it "crashed" with a Chrome error.
On Firefox I got this error message after some seconds:

Perhabs the rendering of the page took too long and the refresh was triggered before it was rendered completely.

[maggu2810]

The rendering of the control page takes some time. I don't know if it has been faster before but also for only a few things it needs (IMHO) to much time.

[kaikreuzer]

@aounhaider1 Could you please have a look?

[kaikreuzer]

I don't know if it has been faster before but also for only a few things it needs (IMHO) to much time.

We just tested it against an older version - and no, it wasn't any faster in earlier versions.

The problem is that a rather complex HTML is constructed dynamically for this page - there isn't really a quick fix for this. The best workaround is to not have too many things on a page) - with #1083, we will have the Things on multiple tabs, which will ease the situation.

[maggu2810]

For me it has been the combination of the (unused but active) Z-Wave binding in the runtime and the circumstance that the Paper UI loads all thing types "/rest/thing-types".
The response content length is 1,579,263 Bytes

[markusjw]

I just wanted to raise the same issue.
The effect is reproducible when you have a Number item (usually defined via a thing channel) with a high maximum value, combined with a small step value.
The problem is multiplied with the number of affected Number items. If there are several of these items, the page script can take minutes to load. It seems to load eventually, so it might be rather a very long than an infinite loop.

An example would be an energy counter item which can reach high numbers. Such item definitions actually exist, so this effect is not just theoretical.

I suppose that the slider control is not designed to create a high number of discrete value stops.

[markusjw]

@aounhaider1 Does this information help to find out more about the problem?
I hope there is a solution because right now the Control UI is just not usable for things with wide range Number items.

[markusjw]

Besides the fact that the web UI should not block, there is a general question:
Should a slider be shown for values with large number ranges? In these cases, the slider is no longer usable for precise inputs.
@kaikreuzer What do you think?

[kaikreuzer]

Does the slider cause any issue? It is still the fastest way to get close to some desired value - and with large ranges, you usually do not want to have a precise number. For the cases where you need it, the number value itself can be selected and the desired value can simply be typed in.

[markusjw]

Yes, it seems to me that it is the slider that causes the issue. As said above, the problem rises especially when using large range number items with small steps.

There are use cases for "large range, but high precision". For example, if you can configure a light duration. For some applications youtwant to set it precisely for a few seconds (that is why the step should be in seconds), but in other applications you want to duration to be 8 hours (which would already be 28800 seconds)

You are right, the number value input is usable. But maybe the slider should be deactivated for larger ranges, especially if it cannot be made to work properly so that is blocks the complete control page.

[kaikreuzer]

Jus thinking about that again: I actually thought that the slider should only be there for Dimmer items, i.e. the range will always be 0-100. So I actually agree with you: For number items, I'd tend to say that the slider is not really useful and we should dismiss it there.

@maggu2810 & @aounhaider1 Would you agree?

[maggu2810]

The PaperUI uses a slider for Dimmer items.
If the item type of a channel (type) is using "Number" I don't think that a slider is used at all.
Or do I miss something?

So, shoudn't this be solved by using another item type instead of dropping the slider for large values?

[kaikreuzer]

If the item type of a channel (type) is using "Number" I don't think that a slider is used at all.

So we are not having any problem after all. @markusjw Could you clarify?

[markusjw]

@maggu2810 I'm sorry, but Number items do show sliders. For me the problem is therefore reproducible.

[aounhaider1]

@maggu2810 is right, PaperUI checks if stateDescription contains minimum and and maximum values, if so, it renders a slider instead of an input field.

[kaikreuzer]

So back to my suggestion above then - would everyone agree with that?

[maggu2810]

I am fine with:

• DimmerItem => Slider
• NumberItem => No slider

I assume we inspect the min, max and step for Dimmers regardless that it's typical in the range of [0,100].

[markusjw]

@kaikreuzer Yes.
Firstly, that is a clear concept.
Secondly, that should solve the problem I am encountering. At least if my assumption is right that large Number item sliders are the cause.

[MHerbst]

@kaikreuzer Sounds good.

[markusjw]

@aounhaider1 Do you have time to implement this?

[aounhaider1]

I have to check but I think it is already implemented.

[htreu]

With the slider in place the validation of the input value was not necessary. How do we validate new values when the input is changed to input field?

[aounhaider1]

Do you mean the validation of number input field? Currently, there is no client side validation on control page AFAIK.

[htreu]

I guess with #3437 merged and the ng-min and ng-max attributes + disabling the submit button is a completely sufficient solution. Can this be closed then?

[htreu]

@MHerbst or @markusjw are you able to verify the fix for this issue with the latest SNAPSHOT build?

[MHerbst]

@htreu I have tried it with about the same number of items but now everything works fine. Tested with Chrome, Firefox and Edge. In my opinion this issue can be closed.

[markusjw]

I had no time to check that directly, but in openHAB 2.1 there are no more sliders and no more loading problems for my use case. Thanks for the changes.