updateConfig when move slider too

[ericfont]

onchange only would trigger updateConfig when user releases the mouse from sliders.

Adding oninput also allows updateConfig when dragging the sliders, which is nice cause user gets immediate feedback of the changes.

A big reason why I want this change is because the LED Lamp is very bright, and previously when user dragged the light slider, the user wouldn't get any feedback about just how bright the LED would become, and that presents a safety risk, cause that LED is bright!

[ericfont]

hmm...though I can't seem to get consistent correct behavior with Stop Stream & Start Stream. This probably messed that up, and so maybe that button needs to not have this change.

[ericfont]

The Stop/Start stream button seems to work when first reboot. However the moment I adjust any slider, then that Stop/Start stream button is broken because of my code.

[ericfont]

ok, I updated so triggers oninput only for range type inputs, I think. I don't notice the glitch I mentioned in my previous comment. However, I can cause the Stop/Start stream button to break if I do a lot of fiddling around with sliders and also press Stop/Start stream a bunch of times...though I'm not even sure that that is my code causing that glitch. Maybe it there are simply too many updates then the streaming simply fails to work.

[easytarget]

Cool! I hate the lack of updating while dragging that slider too, It hadn't occurred to me it could be done like this, good idea.
I'll look at this on my dev PC later, it may be that adding an minimum interval time to the update sending (150ms would seem reasonable) stops the glitching while remaining responsive to the user.
I'll play with your branch and see what happens.

[easytarget]

Merging onto a branch of my own to test

[easytarget]

Looking at this via browser developer tools 'network' tab, and the console (where lamp commands are logged), I can clearly see that a really large number of config update packets are being sent as the user moves the slider, and since this is an asynchronous connection they are arriving out of order at the esp32 itself.. Hence the laggyness, glitching and, sometimes, the lamp being left on when the last packet arrives out of order.

I've got a fix in mind and half-implemented, it's a bit fiddly but will, essentially, rate limit the packets. However it needs more coding and testing.