Why different types of Triggers within openLuup & ALTUI

[ArcherS]

I installed a new dimmer a few days ago, a Sunrichter "knob smart dimmer" (SR-ZV2835RACS).

It included without problems into Z-way and shows up in AluUI and in the Console as usual.
However the dimmer value in AltUI/Console does not change when you adjust it manually on the dimmer. I have checked the variables and it seems as if AltUI displays LoadLevelTarget and when checking on the dimmer variables the LoadLevelTarget value is not updated in OpenLuup when the dim level is changed on the dimmer. In other words LoadLevelStatus and LoadLevelTarget differs and LoadLevelStatus shows the correct dim level set manually on the dimmer.
If you change the dim level in OpenLuup then both values are updated.
On/off state is however always updated.

In Z-way the dim level is updated as it should, so it works there as it should from what I can see.

Running OpenLuup 20.12.19 and AltUI 2.53b.2552.

@akbooer any idea if this is something that can be fixed?

[akbooer]

This is slightly tricky. Quite rightly, when you change a control (in openLuup) then the target level is changed, and the status reflects the actual brightness. AltUI show the position of the dimmer control as the target level (because that’s what it controls.)

So what should happen when the level changes on the dimmer itself? You might think that the target level should change accordingly, but you would be wrong. Why? ... because dimmers generally have quite a long ramp/up ramp/down timescale, and it’s common (Fibaro dimmers, for example) for intermediate brightness levels to be reported during the dim. So the target level would then switch to an intermediate value? For AltUI, then, this brings about a horrendous visual flaw in that if you change the target level to, say, full on by dragging the slider, then it immediately jumps back down to a lower level, possibly rising again by degrees. This is not desirable behaviour for a control.

I seem to remember making this an option somewhere, once. Possibly in the ZWay plug-in, having argued the case with @rafale77 and others.

Edit: just checked: the discussion for ZWay was about whether a target level slider should be set to zero when the device is switched off. I resolved this by adding a variable ZeroDimmerWhenOff to make it an option. Could possibly do this for the on state, as well...

[ArcherS]

@akbooer I can understand the trickiness.
In fact it may be the case that Z-way displays the LoadLevelStatus (I do not know how to check that in Z-way), but I have noticed the visual flaw that the slider jumps back and then steps up to the new value when testing to adjust dim level in Z-way.

I have added this dimmer in Homewave and there it interestingly displays the correct dimmer value, maybe Homewave uses LoadLevelStatus?

To be honest I do not really use the AltUI/Console very much other than for administration, but it would have been nice to fix it somehow anyway.
If and when I will add logic for this dimmer it can be done in Reactor by looking at LoadLevelStatus that has the correct dim level.

I was considering buying more of this kind of dimmer, but this strange behaviour by the dimmer makes me hesitate. The problem is that I used it to replace another knob dimmer that works very nicely, but that get "broken" in Z-way until you restart the Z-way server.

Some variable option could perhaps be a good solution for this kind of problem.

[rafale77]

@archers

What status do you see in z-way? I am trying to figure out the source of the gap. openLuup polls z-way for this status at a regular frequency so I suspect that the status is in sync with z-way. I have indeed had a long discussion for a similar problem: The doorlocks on the z-way forum. It can take time for some devices to physically get to the targeted status and for devices which do not send instant status frames, z-way is just too fast at polling after an actuation command is sent. For my doorlocks, I simply forced a reversed status logic whenever a lock a NIF frame is sent by the lock and it seems to work fine but it is a binary status. In your case, we could explore adding a logic in the z-way bridge to send a poll frame to z-way so it would poll the device again after x amount of time with the status is different from the target. This is assuming that the problem is from z-way polling too soon...

Edit: Sorry I just re-read your post. It seems Z-way is showing the correct value. This is rather strange as I am not seeing this gap between the two. What polling rate are you using on the z-way bridge?

[ArcherS]

@rafale77 Yes, the status in Z-way is showing the correct value. When you dim in either Z-way gui the value changes, but you can see that is a bit slow and jumps back down to the old vale and then steps up to the new.

The poll frequecy is set to 10, I think it is the defaul value.
Edit: The Z-way plugin I have is v 20.7.14.

[rafale77]

@archers

Thanks for this. Your pollrate is 1s which is what matters (I have mine set at 0.5s). I am therefore puzzled as to why your dimmer is out of sync between z-way and openLuup. I have not seen this. The longest delay should be 1s. What you see on the smarthomeUI of z-way should be the same status as the corresponding child device on ALTUI. The fact that it is displaying correctly on Homewave seem to indicate that it is an artifact of ALTUI... Does the status update if you refresh your browser on ALTUI?

[ArcherS]

@rafale77 The status does not change when I refresh the browser or even if I do a Luup relaod and then refresh. The variables stay unchanged.
If I change the dim level on the dimmer LoadLevelStatus changes to the new dim level and LoadLevelTarget is unchanged. LoadLevelTarget only seems to change when I dim in OpenLuup.

AltUI:

Homewave:

Variables:

[rafale77]

@archers

I just ran a test and indeed.... on the ALTUI:

But if you click on the device, this is what you see inside so it is purely an ALTUI slider management issue.

It can easily be fixed. I will fix it on my fork of ALTUI. I think the two sliders are just updating to different variables. You can see from the icon though that the icon is updating properly, it is only a problem with the slider.

And fun fact, the openLuup console does the same thing...

[therealdb]

@rafale77 this is a thing about ALTUI that is confusing me as well. While the dual system for templates seems good at the first stage, it's really hard to maintain and too hard coded for my own tastes.

[ArcherS]

@rafale77 Indeed, you are right, I didn't see the slider inside the device. Thank's for finding that one out!

It it for sure a bit confusing, as you also found out the console does the same thing:

Sounds promising that it can be fixed!

Edit: And that hopefully means that the dimmer itself does work correctly which will mean that I may even buy some more later on.

Thanks all for the help, as usual quick and to the point on this forum!

[rafale77]

@archers

Alright here we go. I fixed ALTUI, just replace this file in your ALTUI installation with the one attached. It still doesn't fix the openLuup console. The code was a little weird and I don't know what caused the need to do it the way it was.
Basically if the LoadLevelTarget exists and is a number, the slider would display that instead of the status. Only if it didn't exist would it use the LoadLevelStatus instead. I changed the code to make the slider always display the status.

As for the console... @akbooer around line 1675 of console.lua... clearly displaying the loadleveltarget instead of status and again, I don't know why.

if srv then    -- we need a slider
  local LoadLevelTarget = (srv.variables.LoadLevelTarget or empty).value or 0
  slider = xhtml.form {
    oninput="LoadLevelTarget.value = slider.valueAsNumber + ' %'",
    action=selfref (), method="post",
      xhtml.input {name="action", value="slider", hidden=1},
      xhtml.input {name="dev", value=d.attributes.id, hidden=1},
      xhtml.output {name="LoadLevelTarget", ["for"]="slider", value=LoadLevelTarget, LoadLevelTarget .. '%'},
      xhtml.input {type="range", name="slider", onchange="this.form.submit();",
        value=LoadLevelTarget, min=0, max=100, step=1},
    }
end

J_ALTUI_plugins.js.zip

[akbooer]

@rafale77 said in Wrong dimmer value in gui:

As for the console... @akbooer around line 1675 of console.lua... clearly displaying the loadleveltarget instead of status and again, I don't know why.

So, what you think, is that the slider should map the status and not the target?

[rafale77]

@akbooer

Yes and the reason is pretty simple: The slider gets completely out of sync when the device is being actuated in other fashion than openLuup. If for example you manually toggle a light switch, it reflects properly but the slider doesn't. It may remain at 0 when the light is on. I did this by dimming a light on Z-way. The status updates on openLuup but the slider on both ALTUI (fixed now) and the console do not reflect the dim level... unlike the switch representation. It makes things inconsistent.

[akbooer]

It’s a philosophical issue. On the one hand, the slider is an indication of the light level, on the other, it’s an indication of the level which will be used if switched on by this controller. So if the slider doesn’t represent the target level, then switching the light on from here will end up with it set to a different level than that indicated.

Which is best?

[rafale77]

Using Z-way definitely the status.
I think there is already another variable "OnEffectLevel" which is meant to reflect the target level if the switch is turned on.
Z-way also by default turns on to the last load level anyway. Certainly they do not use the LoadLevelTarget for this functionality and I have not seen it to work that way. My loadleveltarget are always 0 when the device is turned off... be it from the hue bridge or z-way bridge.
Also again the possibility of multiple sources for control of these devices also will render the display go completely out of sync. Including toggling the device manually, by turning it on to its previous loadlevel coded inside the device, the object on the UI will show a dim level of 0... while the switch is on. Any change I make manually to the dim level will change the icon on ALTUI but the slider will continue to show 0...

Because of this I don't understand what the slider is representing when it is showing the loadleveltarget. It's inconsistent with other controllers as well and you can see it is even inconsistent within ALTUI with two displays devices screen and the option screen within the device being different...

[akbooer]

So what’s the purpose of the LoadLevelTarget variable?

[rafale77]

It is used for load level changes, when we change brightness either with the slider or from a scene... From what I am seeing it's not used when the dimmer is going through the "turn on" action. Actually it is the opposite. When the LoadLevelTarget is set to any value above 0, the device turns on and it should turn off when it is set to 0.

These are observations also from the behavior of the window coverings and the vents (which I created based on a dimmer) and I can confirm that this is also the behavior of the ALThue plugin.

[akbooer]

@rafale77 said in Wrong dimmer value in gui:

When the LoadLevelTarget is set to any value above 0, the device turns on and it should turn off when it is set to 0.

Indeed, and the slider is the thing that controls it from the UI.

I don’t have an axe to grind here, it’s just that I’ve been through so many iterations of testing and reverse engineering ‘what Vera does’ that I’m now slightly loathe to change anything fundamental. But this is ‘just’ UI stuff and, just like @ArcherS said above “To be honest I do not really use the AltUI/Console very much other than for administration”.

It’s also true, now, that ‘what Vera does’ is far less relevant, aside from maintaining the Luup API which keeps old plugins running.

[toggledbits]

In UPNP, the "Target" variable is usually the desired state, and the "Status" variable is the actual operating state. So to turn on a light, as you know, you would invoke SetTarget with newTargetValue=1 on whatever device. The device would, presumably, do whatever it must to turn on the light, and then send an update advising that Status was not 1, light on. The idea is that Target causes a command to the device (and is only modified by an action), but Status is feedback from the device, updated any time.

They are related, but not bound. For a thermostat, for example, UPNP would have you set the operating mode target to HeatOn, but the status would remain Idle until the unit actually called for heat, and then would change to Heating, and when it made setpoint, go back to Idle.

LoadLevelTarget is the same. If you want the dimmer at 50%, you set LoadLevelTarget to 50, and the internals should tell the device to do that, and when the device has done that, it should report its actual current load level back, and the internals take that and put it into LoadLevelStatus.

But of course, Vera got this wrong on a bunch of devices, and the thermostats are among them.

[ArcherS]

It seems as if I stumbled into a bit of a rabbit hole here.
In fact when I now check more closely how my old dimmers behave they do the same as the new one in AltUI and in Console. In other words the new dimmer seems to work which is at least good to know! The only issue I can see with the new dimmer is that is is a bit slow in the reaction causing the "jump back" in e.g. SmartHome mentioned above.

The reason for me stumbling into this was that I looked at how the new dimmer behaves in detail after installation and the fact that most of the other dimmers are more or less automated, so the two values were the same on the old dimmers when I compared with them.

In fact have even missed the dimmer slider inside the device in AltUI all this time! My only excuse for that is that I usually use Homewave for normal manual control and use the gui's for administration mainly.

I can see the philosophical aspect of how the controls should look and behave, both sides have their merits. I leave it to the more knowledged people to decide what way to go.