How does Slider sendFrequency work?

Setup, Configuration and Use Items & Sitemaps
1

I have a few Sliders that control dimmers via http REST commands. Updates to the actual dimmers are reflected back to OpenHab (currently 1.8) via MQTT.
When I drag the slider in the web UI, it sends multiple updates to the device, the returning MQTT messages then make the widget janky because it gets returned to where it was a few ms ago when the HTTP request was sent. It eventually settles down, but I was hoping that sendFrequency could be used to reduce the number of updates sent.
I tried adding sendFrequency=“100”, hoping that it would only send an update after 100ms, but it didn’t seem to change the behavior.

The documentation in the Wiki isn’t very clear on the actual behavior (to me, at least):

sendFrequency: Used for distinguishing between long and short button presses in the classic (web) frontend; this parameter defines the interval in miliseconds for sending increase/decrease requests

2

If you have a slider, I guess you’re talking of iOS or Android? Just click once to the level, you want to set.

sendFrequency is useful only if using INCREASE/DECREASE commands. This is in Classic UI, where Dimmer Items have two buttons but no Slider at all.
If you press the buttons short, it will send ON or OFF, depending what button is pressed.
If you press and hold the buttons long, it will send multiple INCREASE/DECREASE commands as long as you hold the button. There are dimmers which will dimm up/down as long as they get this commands.
And sendFrequency will set the pause in msec between two commands.

3

You can address this with a rule and a Timer to basically ignore the return MQTT messages until they stop coming. This should smooth out the slider a bit. However, this will mean separating out the MQTT from the REST into separate Items so the MQTT only updates the REST through this Rule rather than automatically.

var Timer dimmerTimer = null

rule "Dimmer Update"
when
    Item DimmerMQTT received update
then
    if(dimmerTimer == null || dimmerTimer.hasTerminated){
        dimmerTimer == createTimer(now.plusMilliseconds(500, [|
            DimmerREST.postUpdate(DimmerMQTT.state)
            dimmerTimer = null
        ]
    }
    else {
        dimmerTimer.reschedule(now.plusMilliseconds(500)
    }
end

Theory of operation: when an MQTT update is received, create a timer that expires in half a second. When additional updates are received, keep rescheduling the Timer into the future. Half a second after the last update, the most recent update is postUpdate to the REST Item to put them in sync. Using postUpdate is important as it keeps OH from sending out this last update as a command to the device.

The biggest drawback is that the last update will lag half a second. But if you are commanding the dimmer from your sitemap this will be transparent as the Item will already be at the latest value. But if something else changes the Dimmer the sitemap will lag half a second.

4

Udo, I’m testing with the web client, in a Chrome browser. Most use, however, will be Android and iOS apps. Maybe I’m unusual, but my intuition has me grab the slider and move it to the desired position, rather than clicking directly there. I’m not sure what others in the house do with this type of widget, if I’m the only one, I’ll not worry about it much.

Great suggestion, Rich. I’m thinking I may turn it around though, and only send the http request to the device after a few ms. That’ll implicitly get rid of the returning MQTT feedback, and also reduce load on the device controller. I could also filter duplicate commands (at one point the web interface was streaming “0” commands to the device, I had to close the browser tab to stop it).