Dimmer slider always remains at zero position

Plugins & Plugin Development Alternate UI
#1

Hello Amg0

I’ve got a plugin that has a lot of dimmable lights controlled by a master controller. Each light comes up as a standard dimmable light child Each child uses the Vera default dimmer files. For some reason I don’t understand, the dimmer slider doesn’t stay at the level found in LoadLevelStatus. This is all under openLuup, so the Vera UI isn’t available to check the slider functionality. The AltUI interface works OK for:

  • The slider can be used to control the dimming of the light OK.
  • The On/Off button reflects the slider’s movement.
  • The On/Off button itself works OK.
  • The text that says On or Off works OK : the slider or On/Off button will operate it.
  • The slider percentage shown, varies as the slider is dragged.
  • The light bulb icon changes to match the dim level as requested by the slider.
  • LoadLevelStatus variable always reflects the correct dimmer status.

However the slider always moves back to zero no matter what. If you drag it, it stays in position for say 200 ms and then returns to zero; even though the light goes to the dimming setting selected. Does this in Firefox and Chrome. Any ideas on this?

#2

Which plugin? What version of openLuup? This is likely an openLuup issue, rather than an AltUI one.

Are you using the asynchronous option for the VeraBridge plugin?

Don’t understand this. The Vera UI is always available.

#3

It’s the DALI plugin. Note the GitHub code for it is a little bit out of date. I wanted to update it hence the found problem. The plugin is running on a RasPi under openLuup version 2019.03.14. I set AsyncPoll to false on the bridge but no difference, although I don’t see how that’s relevant.

“The Vera UI is always available.” It’s not running on a Vera.

#4

Ah, yes, fair point!

AFAIK, AltUI should reflect the status/level variable. I do have some issue with the way it does control animation, which leads to sliders jumping about for a moment, but it should settle on the right value.

#5

altui takes the LoadLevelTarget value to display if it exists and falls back to LoadLevelStatus if LoadLevelTarget is not a number
this is to give the user the optimal experience, we display what he requested, optimistically expecting that LoadLevelStatus will follow soon after but the user does not want/need to see this latency of time

if it comes to zero that could mean LoadLevelTarget is reset to 0 by the plugin which is probably not the right behavior

1 Like
#6

Understood. The problem being both that LoadLevelStatus may be ramped, and also that it is updated asynchronously from the action request, hence the possiblity to jump around.

However, I’m not sure what better you could do.

#7

Ok - that makes sense. I’m assuming that LoadLevelTarget is just “set” and that LoadLevelStatus is used to “get” the outcome. I’ll update LoadLevelTarget so a “get” on it will work as well. In the plugin, LoadLevelStatus just reflects changes to LoadLevelTarget. Getting the actual LoadLevelStatus from the light would be complicated by the lights’ functionality, as they can fade up and down, which results in the true LoadLevelStatus varying over the fade time.

I note in ‘D_DimmableLight1.xml’ there are also GetLoadLevelTarget and GetLoadLevelStatus actions along with all sorts of other actions that never seem to be implemented by coders. eg Set OnEffectLevel. Does it make sense to distribute a different file derived from ‘D_DimmableLight1.xml’ that strips out all this other stuff? Or will that just confuse matters? ie like mobile apps, etc.

#8

Flawed though they are, it seems to me that, for implementing existing functions, you should stick to the available device/service files whenever possible.

A properly written UI should actually work with recognised service files only (ie. an unknown device type) but there’s no guarantee.

#9

Agreed, better not to change these files.
To my understanding, The loadleveltarget should never be set in fact it should be set by the implementation when the upnp action setloadleveltarget is called. Then the plugin should set the target variable, call the underlying hw, and update the status variable as the hw gives feedbacks on the actual status

#10

This is consistent with my understanding and approach in all of my plugins as well.

#11

All fixed - knowing that LoadLevelTarget was used for the status rather than LoadLevelStatus resolved the problem. I note however that LoadLevelStatus is used to drive the selection of icon images. Regardless, all good and thanks for the help.