Basic UI Slider not triggering changed event?

Setup, Configuration and Use Scripts & Rules
1

I have the following rule

rule "Living room dimmer"
when
    Item LivingRoomDimmer_LevelControl changed
then
    gLivingRoomLights.sendCommand(newState)
end

In basic UI I have

Frame label="Living Room"
  {
     Slider item=gLivingRoomLights
     Slider item=LivingRoom2_LevelControl
     Slider item=LivingRoomDimmer_LevelControl
  }

but moving the slider LivingRoomDimmer_LevelControl in BasicUI doesn’t trigger the changed even while my actual Hue Dimmer does. Is that expected?

2

Can you show us the configuration of Item LivingRoomDimmer_LevelControl?

It might be worth trying to call the state of the Item directly, for example:

gLivingRoomLights.sendCommand(LivingRoomDimmer_LevelControl.state.toString)

What do the logs show when the rule is running? Do you see Items changing?

3

LivingRoomDimmer_LevelControl was created in PaperUI as linked item as Dimmer

When I move a slider in basicui, all I get is
2020-09-18 01:16:39.439 [ome.event.ItemCommandEvent] - Item 'LivingRoomDimmer_LevelControl' received command 41

Also the rule itself works fine but it never gets triggered when I move the slider in basicUI. I have added all kinds of logging and the rule simply never gets executed.

4

Try:

when
    Item LivingRoomDimmer_LevelControl received command
then
5

Yes, I tried this variation… it works with BasicUI but doesn’t work with the actual hue dimmer :stuck_out_tongue:

6

I think I’m confused about what is and isn’t working, and how the Hue dimmer comes into play. Does it work if you use both triggers (changed and received command) in your rule?

Taking a step back: why not expose gLivingRoomLights directly in your Sitemap via a slider? It seems to me that you’re just 1:1 mapping states between two Items. Depends how you’ve defined your group: I’ve recently done this by defining the dimmer group as below:

Group:Dimmer:MAX gLivingRoomLights

You don’t need the :MAX - you can use MIN or AVG or just leave it out entirely. More info here.

EDIT: I just tried your original code, and it works fine with the following Items defined as below:

Items

Dimmer LivingRoomDimmer_LevelControl
Group:Dimmer gLivingRoomLights

Sitemap

Slider item=LivingRoomDimmer_LevelControl

Rule

rule "Living room dimmer"
when
    Item LivingRoomDimmer_LevelControl changed
then
    gLivingRoomLights.sendCommand(newState)
end
  • Double check how you’ve setup your Items - you haven’t shown us how they are configured.
  • Double check that you don’t have any other rule with the same name "Living room dimmer"
7

Look in your events.log - if there is no changed event, obviously the rule won’t trigger.

That’s all that is supposed to happen when you use UI controls, it issues commands.
That won’t change the Item state by itself.
Usually, a command will cause a real linked device to do something and report its new condition, leading to a state change.
(Or often, openHABs autoupdate feature will guess the likely effect and perform an update.)

So we’re zeroing in on your problem - your hue device is failing to report status changes to openHAB. You need to look at your hue configuration.

8

Thanks - I went through most of the command vs update docs and did not realize this nuance.

Maybe, but I have the hue slider also displayed in basicUI and it is responds perfectly to changes. But the zigbee bindings sends updates to the dimmer item instead of commands - and if I want to link the group to the dimmer, it looks like I have to write two different rules, one for changes and another one for commands. Am I missing something?

9

That is fascinating. I did setup all my items in paperUI, could this be the difference? I will try this exact setup later and create the items manually to see if it makes a difference.

10

Yes, I think you’re missing something.

Core openHAB functions;
Commands to Items get passed through binding to real devices.
Status reports from real devices get passed through binding to openHAB Item state.

If you want something to happen when the real device changes, you should listen for Item state change. Then it matters not who initiated that change.

If you have a problem where the device does not report changes, then you have a problem with your device reporting. You might start by looking at your Item/channel/Thing/device configuration.

Completely separately to any of that, a Group Item has no valid state of it’s own accord.
If you would like your Group to adopt a state that reflects the state of its members, you can configure it do that by giving an aggregate function.
You might use AVG or MAX for dimmer members for example.
UI widgets like sliders used with a Group Item will normally reflect that state, if you configure it.

11

Thank you for the clarification - yes I believe that might be the underlying issue. I will investigate my zigbee logs to see if I can figure something out.

12

Ah, zigbee. There are a couple of threads about zigbee binding failing to get immediate responses from devices, and having to fall back on infrequent polling.
For clarity, the key issue here is whether you see the linked Item changed in your events.log when the device really changes.