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:
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:
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.
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?
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.
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.