I have ZWave dimmable bulbs (Domitech DTA19 Smart LED Light) and controlling them via ClassicUI/BasicUI/HABDroid works flawless.
With HABPanel, I’m not that lucky.
If i control them with a slider, they react OK but immediately the Items Value is reset to the previous state:
2017-04-23 22:32:29.075 [ItemCommandEvent ] - Item 'Licht_Wohnzimmer_Decke' received command 51
2017-04-23 22:32:29.080 [ItemStateChangedEvent ] - Licht_Wohnzimmer_Decke changed from 0 to 51
2017-04-23 22:32:29.144 [ItemStateChangedEvent ] - Licht_Wohnzimmer_Decke changed from 51 to 0
If i press the Global Off Button for the room, the light turns off and the Item value/slider is set to the previous state instead of 0.
With Knobs it’s even stranger: if I press the associated switch light goes to 100. So far so good.
But if a press the switch again, OFF is sent but Knob turns to some random value, and only several button presses actually set the knob to 0:
2017-04-23 22:43:53.810 [ItemCommandEvent ] - Item 'Licht_OG_zimmer1' received command ON
2017-04-23 22:43:53.814 [ItemStateChangedEvent ] - Licht_OG_zimmer1 changed from 0 to 100
2017-04-23 22:44:08.535 [ItemCommandEvent ] - Item 'Licht_OG_zimmer1' received command OFF
2017-04-23 22:44:08.539 [ItemStateChangedEvent ] - Licht_OG_zimmer1 changed from 100 to 0
2017-04-23 22:44:08.738 [ItemStateChangedEvent ] - Licht_OG_zimmer1 changed from 0 to 98
2017-04-23 22:44:11.465 [ItemCommandEvent ] - Item 'Licht_OG_zimmer1' received command OFF
2017-04-23 22:44:11.469 [ItemStateChangedEvent ] - Licht_OG_zimmer1 changed from 98 to 0
I’m running the latest OH2 snapshot.
Is anybody else experiencing such behavour and/or has an idea how to solve this issue?
Many thanks in advance,
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?
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.
Running OpenHAB 2.3.0 release build, fast hardware.
Following an unsuccessful click, trying to change from 20 to 60ish:
And at last, a successful click gets this response:
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.
Item dummySliderProxy changed
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.
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.