search

openhab / openhab1-addons

Add-ons for openHAB 1.x
Eclipse Public License 2.0
3.43k stars 1.71k forks source link

HTTP Binding: command queuing not skipping deprecated updates #4794

Closed kohlsalem closed 7 years ago

kohlsalem commented 7 years ago

Hi,

i use a couple of esp8266 based devices (H801 LED controller and some tinkered esp based candle) which i can switch on/off and dim with a simple URL and a parameter. The configuration is really nice and simple.

Dimmer Candle "Kerzen [%d]" <fire> {http="<[http://candle:60000:JSONPATH($.b)] >[*:GET:http://candle/?b=%2$s] >[ON:GET:http://candle/?b=100] >[OFF:GET: http://candle/?b=0]"}

If i connect a slider to the dimmer, it comes up to a nasty situation:

A busy micro controller is not very fast in accepting the burst of http requests. It is not able to multitask at all. If I just set the slider to something it works great. But if I slide a little up and down, the intuitive movement one would do to find a nice dim level, the candle is blocked for the next 5-15 seconds and changes randomly to different values.

Sure, i could try to speed up and optimize the controller code as well. But actually i think that especially for Items like Dimmer and Rollershutters newer updates should directly replace qued and still not send updates.

I could probably simulate such behavior with a rule and a timer.I could wait for 0,5 sec in a timer before sending the http request and kill existing timers, if i get an update before. However, i think that's a low-tech solution for a rather generic problem.

I'm not really sure, if the command queuing is explicitly implemented or "just" an effect of parallel threads sending updates or something, but i would propose to place there a mechanism to drop already deprecated updates.

Thanks Michael

watou commented 7 years ago

Are you saying that a Slider widget rendered in the UI (which one(s)?) i sending commands while the mouse button is still down? I would think that commands should only be sent on mouse up for Slider widgets. If the act of sliding side to side is causing a flood of commands before the mouse button is released, I can see that would be a general problem with sending floods of commands. Others might disagree and see it as correct to send a flood of commands as the Slider slides back and forth.

The HTTP binding is working as intended, but the UI used to manipulate the Dimmer item it's bound to may be generating more commands than is appropriate to the end device, which should be addressed at the UI layer imho.

kohlsalem commented 7 years ago

Hmm. I'm sure either with the ios app or with the basic ui i had this event bursts. Yesterday. This evening i can not reproduce anymore...

If i click 10 times very fast on the basic ui i still can reproduce it, but thats very unlikely to happen at all.

So, principally i think precausions should be made for overtaking events, on the binding level. On the other hand, as long as i have to provoke such situation forcefully, it is prio "nice to have".

I leave it to you to close or fix - I would reopen only if i can reproduce better.

watou commented 7 years ago

I leave it to you to close or fix - I would reopen only if i can reproduce better.

Sounds good.