openLuup email server

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