Indeed, it is just the items state that gets updated. The actual Hardware
acts ok. Since there is no issue with the other UIs i tend Not to think it
is a zwave binding issue. Would you have any Suggestion how to better
pinpoint the root cause?
Am 25.04.2017 7:17 nachm. schrieb “Yannick Schaus” <
bot@community.openhab.org>:
Could you try sending the command through the Karaf console and check the logs as you did above, to check if there’s any difference?
openhab> smarthome:send Licht_OG_zimmer1 ON
openhab> smarthome:send Licht_OG_zimmer1 OFF
Thanks.
I did: same result!
I tried stopping HABPanel by issuing bundle:stop for the " HABPanel User Interface"
but it still seems to run; client do not show “connection lost”.
How can i totally stop HABPanel to retry without it running?
Simply close the tab 
The bundle simply provides the files necessary to load the HABPanel application, which will run “on its own” once it’s loaded in your browser.
You’re right to try without HABPanel running, but I don’t see how it could interfere with the state, especially if you have the same behavior by simply sending the command through the console. It “somehow works” with other UIs, no idea why, perhaps try posting the logs when you switch on/off using e.g. Basic UI to see if there’s something different being done?
OK,I’ll repeat the test with the other UIs making sure every HabPanel instance is Off. I’m with you seeing no apparent reason how HabPanel could "mess"with the item states, but i definitely started to see this after starting with Habpanel. Might take a few days until i can report back - got some “Real Life™️” stuff to tackle first 
Thanks for taking the time so far…,
As promised here is an update: did the monthly “update&reboot everything” routine.
Started just one client (HABDroid) and tried: same result 
So, one the plus side i guess this means my issue is not related to HABPanel.
On the downside I got no friggin’ idea what could be causing this. It is kinda annyoing…
Yes, I have this issue with many or all of my sliders in HABpanel.
Clicking on a slider moves it immediately, but after 0.5 sec or so it jumps back. Sliders on my HABpanel only have ~50% success rate… 
Monitoring the rest/events channel over HTTP, I see that the rest interface (which HABpanel is listening to) sends out ‘state’ messages after I have clicked the widget with the old value, causing the widget to be reset to its previous value.
$ curl -s --keepalive openhabserver:port/rest/events | grep myitemname
When a widget click/slide is successful, the REST channel also emits a ‘statechanged’ event. Since the REST channel reacts to my clicks, something indeed happens between the javascript running HABpanel and openhab, but the actual wanted widget value gets lost.
Running OpenHAB 2.3.0 release build, fast hardware.
Some results from my curl command:
Following an unsuccessful click, trying to change from 20 to 60ish:
data: {“topic”:“smarthome/items/SqueezeboxRadio_Volume/command”,“payload”:"{“type”:“Percent”,“value”:“20”}",“type”:“ItemCommandEvent”}
data: {“topic”:“smarthome/items/SqueezeboxRadio_Volume/state”,“payload”:"{“type”:“Percent”,“value”:“20”}",“type”:“ItemStateEvent”}
(repeat twice)
And at last, a successful click gets this response:
data: {“topic”:“smarthome/items/SqueezeboxRadio_Volume/command”,“payload”:"{“type”:“Percent”,“value”:“62”}",“type”:“ItemCommandEvent”}
data: {“topic”:“smarthome/items/SqueezeboxRadio_Volume/state”,“payload”:"{“type”:“Percent”,“value”:“62”}",“type”:“ItemStateEvent”}
data: {“topic”:“smarthome/items/SqueezeboxRadio_Volume/statechanged”,“payload”:"{“type”:“Percent”,“value”:“62”,“oldType”:“Percent”,“oldValue”:“20”}",“type”:“ItemStateChangedEvent”}
data: {“topic”:“smarthome/items/SqueezeboxRadio_Volume/state”,“payload”:"{“type”:“Percent”,“value”:“62”}",“type”:“ItemStateEvent”}
Just started to have slider jumping issues as described since upgrading from 2.3.0 to 2.4.0.
any updates on the cause of the issue?
Mhmm, interesting… the issue still exists?
My setup:
[ ] openHAB 3.1.0 Release Build
[ ] habpanel (but the sidemaps do not works as well)
See the screen record… it jumps back to the original value:
((I recognize that you have to click this gif to start playing, interesting.))
Any suggestions how to cover this issue?
I can not really control any of my heat valves…
By the way… this happens with proxy items as well, so no binding involved.
One more example:
(as above, click to start playing)
Looks to me like your Items just don’t change state. How are you expecting the commands arising from UI clicks to affect the states? e.g. are these Items linked to some binding?
Ok, but keep in mind 99% of all examples in the World Wide Web just add (for example) “set temperature point” (i.e. Homematic IP device) as a binding to the sliders.
Please correct me if I am wrong, but… as far as I guess, the binding in the habpanel is a two-way-binding by default (see AngularJS examples/documentation), so changing of one side will inform the other and vice-versa.
Anyway, a small example case will looks like this.
Items:
Number dummySliderProxy
Rules:
rule "dummySliderProxy"
when
Item dummySliderProxy changed
then
logInfo("dummySliderProxy", dummySliderProxy.state.toString)
end
The console log:
2021-11-09 20:28:31.191 [INFO ] [b.core.model.script.dummySliderProxy] - 27
2021-11-09 20:28:40.227 [INFO ] [b.core.model.script.dummySliderProxy] - 55
2021-11-09 20:28:43.591 [INFO ] [b.core.model.script.dummySliderProxy] - 74
2021-11-09 20:28:46.561 [INFO ] [b.core.model.script.dummySliderProxy] - 20
2021-11-09 20:28:49.444 [INFO ] [b.core.model.script.dummySliderProxy] - 39
2021-11-09 20:28:53.141 [INFO ] [b.core.model.script.dummySliderProxy] - 56
The habpanel’s standard slider and my configuration:
The screen record:
((click for play))
Thats all standard stuff which I use, just added by few clicks. Am I doing something wrong?
Really, what are all the people do to get this working smoothly?
By way of explanation;
When people refer to bindings in openHAB, they’re generally talking about the configuration and add-ons that link Items to external devices or services. Not directly related to UI business, although obviously can effect state of Item.
When you “do something” in a UI, the results get communicated to openHAB as commands to the Item.
The UI visuals however will be derived from Item state. There’s no direct correlation. That makes more sense if you consider something like a roller shutter where you can issue command UP and get position state 75%.
Hence my question about any bindings involved with your problematic Items that can influence state in ways that perhaps you did not expect.
However, your dummy Item now makes a much better test by removing that unknown.
By default, that will have autoupdate enabled, acting like a simple dummy binding and translating Item commands into Item state.
From what I can make of your movie, some expected Item state updates do not appear to take place? So the next place to look would be to see if commands arrive at the Item (see your events.log)
I’ve no idea how reliable the HABpanel slider widget usually is in this usage.
The output of the events.log is the output you can see in the scree recording.
Nothing is logged, I guess I have to increase the verbosity level.
Currently my workaround will be the use of widget-selection with a range of values.
Not the best way to success, but after a while I need some results.
By the way… now I found your article which I will study right now.
No it isn’t. That’s a separate log file to openhab.log where your rule makes its entries.
Nope, I always check both at the same time:
As you can see… empty since the first install of openHAB:
Okay, then your UI is totally broken and never sends any commands to openHAB, and openHAB itself is totally broken and never logs any Item state changes either.
Alternatively, there’s something wrong with your logging.
Yeah, probably there was a bigger issue.
I have upgraded from 3.1.0 to 3.2.0.M4 few minutes ago and I got the events.log content back (see this topic Events.log stays empty, events.log.7 etc is filled - #13 by lil2k)
So far, it seems the sliders are improved, currently the slider change are recognized much better with very less jumping around (nearly zero, but only nearly, but good enough, 2 of 100 were bad).
Related to the small example case few posts ago with the dummy item dummySliderProxy (see Slider and Knob issues - #14 by lil2k) the same case seems to work right now…
Screencast
((click for play))
That’s a really odd side effect of whatever-it-was, but good it’s behaving now.
You might still see odd ‘slider jumping’ when real devices are involved, but if you read the ‘autoupdate’ primer you’ll understand that’s a consequence of the device technology. You get to choose an acceptable visual compromise.
