Setting up a knob to send setpoint temp to the thermostat and I get some odd behavior.
Knob has a range of 66 to 76. At the start of this the thermostat is set to 71.
On an iPad if I change it to lets say 75 the logs shows it sending the command to go to 75 but it steps through and then changes it back to 72. It’s kind like it only wants to increment the setpoint by one degree at a time.
It’ll be difficult to pick out,because of overlapping cause-effect-delay, but looks like the known bug.
While you are turning the knob, it generates a stream of commands. Meantime, openHAB generates a stream of autoupdates.
The updates get sent to the UI, which repositions knob- probably in-between other commands.
The bug causes repositioned knob to send a new command, round we go…
Meantime there’s probably a real device getting a stream of conflicting commands and trying to return it’s own updates … which get passed to UI … which the bug passes back as new command …
Try M3 version, I think the fix is included.
On the other hand,your command stream does not look as chaotic as this.
Maybe your device only acts on first command,ignores other while busy, and after everything is over gets the last word by responding with a final update associated with the very first command.
Got the M3 installed. At first it looked to be fixed but a couple more attempts to change the setpoint shows that the problem is still there. It’s only a minor annoyance at least. And I’ve been looking for a new thermostat. Looks like that might be a more attractive option now.
What’s the technology of the device concerned? It looks tobe taking a couple of seconds to respond to a command. But that might be because whatever network is jammed up with follow-on commands.
You probably just need a throttle here, reducing that command flurry. I don’t know if MainUI provides a means for that.
It’s a CT100 thermostat (z-wave) that I originally got with a Vivint home security system. It’s probably 11-ish years old. That age is the reason I thought a new one might be in order. Just started looking at what options are available and which ones might be supported really well in OH3.
I was thinking about this; I reckon you can effect a proper cure with a proxy Item and simple rules to decouple cause and effect.
Put the proxy on your UI, hide the real linked Item.
The throttle part is a rule that adds a short delay to UI commands, and when they come in a flurry discards all except the last one.
var Timer throttleTimer = null
rule "throttle UI commands"
when
Item proxyItem received command
then
throttleTimer?.cancel
var lastCommand = receivedCommand
throttleTimer = createTimer(now.plusSeconds(1)) [ |
realItem.sendCommand(lastCommand)
]
end
Couple the proxy state to real state for display, by rule -
rule "state repeater"
when
Item realItem changed
then
proxyItem.postUpdate(realItem.state)
end
not sure if that helps in the end, but you could try sending a new value to the item using the console (openhab:send Thermostat_Setpointcooling 68) and then analyze the event log. It might help identify if the issue comes from the UI or the binding.
Jumps right to the new setpoint with no problem. Looks to be the knob is sending multiple commands when I think it oughta wait until it’s released and only send the final state.
2021-04-17 12:40:05.410 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Thermostat_Setpointcooling' received command 68
2021-04-17 12:40:05.423 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_Setpointcooling' predicted to become 68
2021-04-17 12:40:05.455 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Setpointcooling' changed from 72 °F to 68.0 °F
Ok, so seems @Rossko57 is right and it’s an UI issue. Though, it’s different from the mentioned github issue #789, which I fixed lately and was related to Groups.
I’d suggest to open a new github issue for this mentioning the relation to knobs and this forum thread.
So far as I can see,issue 789 was not about groups in particuar, it was about UI widget generating REST commands when state changes received.
I think the widget here is doing what it is supposed to do, generate a number of commands as the knob or slider is twiddled.
In this particular case, the device does not like the stream of multiple commands
But it’s not an unreasonable thing to do in general, for a more responsive device. “Don’t limit my system because yours performs poorly”
Of course we can work around that with rules, but that’s a bit clumsy.
I would say what is needed is an adjustable repeat rate on the widget. I guess that would need to take the shape of a delay from first touch before issuing command, then same delay for repeats if changes further.
No idea if this is possible since I have no clue how this stuff is programmed. But could there be an option on the knob so it behaves as is normally, but could behave so commands are only sent after release?
Added: And yes, I see what you mean about don’t limit systems. A light dimmer for instance should ramp up or down along with the slider or knob. But in this case I think it should wait till the end result of the user input is known as final.
When working on fixing (the Group related part of ) #789, I learned that “sliders” actually behave that way: They only update when released. I then realized that this is the reason why my lamps’ brightness doesn’t follow my movements - which I would actually like a lot.
I found that it would have been possible to have created that behaviour by simply having chosen a different f7 event. That’s what made me think it must have been done intentionally, the reason probably having been to not “flood” the system with changes.
I didn’t look into “knobs” yet, but from this discussion it seems they maybe behave the second way - causing the issues mentioned.
I fully agree to that and I think the response time also highly depends on the type of device and binding.
So, yes, I think an “adjustable repeat rate” would actually be a good solution. Though, it might be a bit too complex (and hidden) for many users, so it should come with a suitable default.
Well at risk of adding complexity …
Start timing when control touched. Time has a default say 1 sec, but optionally user selectable.
If released before “time’s up”, send immediate command.
If we get to time, send a command and start timing again.
