Why different types of Triggers within openLuup & ALTUI

[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.

[toggledbits]

Under the skin, I think everything operates pretty much the way it's supposed to (at least for switches and dimmers). I think the real problem being discussed here is that there's a UI design conflict in using the same single control for both command and status, because every device is going to have interstitial status while satisfying a command. If the UI had, for example, a slider that was command only, and bar graph of "LEDs" to show current dimming level, there would be no conflict here. I think this one of the reasons other tools, like Hass, in their UI, do little things like change the color of the bulb icon to approximate the dimming level, rather than move the slider programmatically.

[rafale77]

@toggledbits

Agreed with everyone here. Working on the UI (Which admittedly I don't do often) I have also discovered a number of strange things which I believe are oversight from @amg0. I will push a few updates to him on github.
This is all about display and changes nothing to how any of the logic work.
And yes, I never believed the problem had anything to do with new vs. old dimmers @ArcherS
That said I am trying to make things more consistent between plugins and bridges and in this case, the display of the sliders for the dimmer light didn't make sense as I said.
I made a few more changes in the file below:
ALTHUE and RGB device colors were looking for TargetColor first then CurrentColor. Strangely a number of plugins, including ALTHUE don't use that variable at all and therefore the color would show as black. In the same spirit as the slider I changed the logic to look for the CurrentColor first and display that color on the UI.
I also added a slider for window covering devices which now enables you to change the opening on the UI if your curtain/blind supports it without needing to go into the device screen and the slider reports back its status.

J_ALTUI_plugins.js.zip

[therealdb]

Having spent two years into virtual light switch and dimmers, I concur with the general sentiment here. In fact, I’m setting target first, call the http endpoint and later update the real value on the callback.

[ArcherS]

@rafale77 I tested the latest file and it does seem to work as intended regarding the dimmers. Dim level is displayed with the current dim level in AltUI devices.

Regarding the RGB controls, this is how it looks with the updated file (for a Hue strip included via AltHue):

In AltUI:

Inside the device:

Inside the device, first dialogue dropped down:

Inside the device, second dialogue dropped down:

The first dialogue inside the device does look a bit strange, not sure how it looked with the old file though since I never have used it.

I do not have any window devices, so that I could not test.

[rafale77]

Yup, that inside the device screen, the color picker, is actually controlled by the ALTHUE plugin, not by the file I posted so it was the same before... The changed file only affects multiple devices overview screen. I will look into why ALTHUE does this on the color picker.

Edit: I suspect that it is a change in the philips hue API in terms of how it is managing its colors and ALTHUE has not been updated to conform to it. From what I can see, only the second color box really matters as I don't quite understand what the first box does.

[CatmanV2]

@archers said in Wrong dimmer value in gui:

knob smart dimmer

Seriously

C

[rafale77]

I submitted PRs for both the openLuup console and ALTUI on github.
@akbooer, I dug into how vera handles it and it is displaying the LoadLevelStatus on its slider as far as I can see from the D_Dimmablexxx.json. That's why there is an inconsistency between what we see inside the device and on the device dashboard on ALTUI since they are being run by different files. I think there was a misunderstanding of the LoadLevelTarget value is being used for. It does not represent the load value when the dimmer is getting turned on. It represents what the target value is at every instant. What value the dimmer gets to when it turns from off to on is stored by the device, not the controller and if it is to be stored in the controller, it is in a different variable.

[ArcherS]

@catmanv2 Yepp! The full name on the instruction leaflet is "Push Compatible Z-wave Knob Smart Dimmer".

It is this kind of push-and-twist dimmer:

A quite common type of device in Sweden and in the other Nordic countries.

But a funny name, google translate at you service! I assume they don't sell it in the UK.

[toggledbits]

@rafale77 said in Wrong dimmer value in gui:

What value the dimmer gets to when it turns from off to on is stored by the device, not the controller and if it is to be stored in the controller, it is in a different variable.

I believe that's where we got the LoadLevelLast kludge.

[CatmanV2]

@archers said in Wrong dimmer value in gui:

I assume they don't sell it in the UK

Not under that name, no

C

[therealdb]

@toggledbits yep, I’m restoring it when a virtual dimmer is turned on and I suspect it’s what Vera is pushing anyway for some Zwave devices.

[therealdb]

@rafale77 do you think it’s easy to use d_** on the altui console for unknown devices? I’ve started to use it more and it’s annoying to develop custom templates for the console.

[rafale77]

Well, for unknown devices, it defaults to combo_device type I believe anyway and uses the corresponding device files. What do you mean by ALTUI console? Do you mean openLuup console?

[therealdb]

@rafale77 nope, I’m referring to the list page.

[rafale77]

Ohh. yeah they are managed by the J_ALTUIplugins.js file... Not my design. They indeed do not make use of the device json so I have tinkered with that file in the past as well.