[SOLVED] Sitemap not updating all group items

Setup, Configuration and Use Items & Sitemaps
1

I’ve created a group item and assigned two bulb to that group. The bulbs turn on/off when issued those commands, but when turned on, only one bulb’s state is updated in the UI. I even added a postUpdate(ON) to the rule to see if that would force an update, but no luck.

Here is my group item definition:

Group:Dimmer:OR(ON,OFF) gSideLights

My items:

Dimmer BackDoor_Dimmer_1 "Back door dimmer 1 [%.1f %%]" <dimmablelight>  (gSideLights) {channel="zwave:device:f21cd9de:node98:switch_dimmer"}

Dimmer BackDoor_Dimmer_2 "Back door dimmer 2 [%.1f %%]" <dimmablelight> (gSideLights) {channel="zwave:device:f21cd9de:node101:switch_dimmer"}

The rule:

rule "Back Door Contact update"
when
	Item BackDoor_Sensor received update
then
	
		if(BackDoor_Sensor.state == OPEN){
			gSideLights.sendCommand(ON)
		} else { 
			gSideLights.sendCommand(OFF)
		}	
end

I initially defined the group item as a Switch, but only one bulb would turn on, so I tried Dimmer.

I’m on a RPi3 running OH 2.4

Any ideas?

2

I don’t know, your items and rule look good (unless my old eyes are missing something)
edit to add… it is not just the sitemap not updating right? Only one of the bulbs actually turns on right?

3

Both bulbs are actually on. The site map only shows one as on.

“My Break-Dancing days are over, but there’s always the Funky Chicken” – The Full Monty

4

I think you need to get rid of the OR and just make it a plain group:

Group:Dimmer     gSideLights     "Side Lights"
5

That should only affect the state of the group, not sending commands to it and certainly not the states of child items.
But it’s worth a try

6

Well, I know it works with switch items as I just did that up in my own setup. Not sure about dimmers though?

Plus he said he initially had them set up as a switch.

7

Which UI please? Some are better than others at refresh. To be frank, there are weaknesses in this area.
What happens if you force a refresh?

You seem to be using a sitemap? - check your openhab.log for mention of it during system boot up messages.

8

BasicUI, and refreshing the page does not help.

9

So you got two events.log showing the Items changing to new states, but one of them still shows the old state on your display after browser refresh?
May we see that events.log and your sitemap lines?

(My suspicion is that you are running into a common zwave dimmer issue with updates to old value, circumvented by altering poll-after-command parameter.)

10

Thanks, but it didn’t work. Both lights on, but sitemap only updates one to ON.

11

That’s weird. When I set out to do this exact thing quite recently, that was the answer I found through searching the forums. And it works on my setup.

I was going to ask you if you are positive both items (especially offending item) are in the group, double check for typos and silly things like that. But maybe rossko57 is on to something… My setup is actuating a pair of relays attached to a single MySensors node, for whatever that’s worth… maybe your issue is Z-Wave related?

12

I also forgot to mention that I’m using a zwave 2.5 snapshot binding from about August. I’ll play around with it again tonight and maybe go back to using a Switch in my group definition. In any case, I’ll be moving my setup over to an RPi4 with the lasest release sometime soon. We’ll see if its still a problem.

13

Remember to show your events.log if you want more help.

14

Here is the log with the group assigned to the dimmers:

BackDoor_Sensor changed from CLOSED to OPEN
2019-12-19 16:18:02.349 [ome.event.ItemCommandEvent] - Item 'gSideLights' received command ON
2019-12-19 16:18:02.353 [ome.event.ItemCommandEvent] - Item 'gSideLights' received command ON
2019-12-19 16:18:02.361 [ome.event.ItemCommandEvent] - Item 'BackDoor_Dimmer_2' received command ON
2019-12-19 16:18:02.366 [ome.event.ItemCommandEvent] - Item 'BackDoor_Dimmer_1' received command ON
2019-12-19 16:18:02.370 [ome.event.ItemCommandEvent] - Item 'BackDoor_Dimmer_2' received command ON
2019-12-19 16:18:02.376 [ome.event.ItemCommandEvent] - Item 'BackDoor_Dimmer_1' received command ON
2019-12-19 16:18:02.388 [nt.ItemStatePredictedEvent] - BackDoor_Dimmer_2 predicted to become ON
2019-12-19 16:18:02.401 [nt.ItemStatePredictedEvent] - BackDoor_Dimmer_1 predicted to become ON
2019-12-19 16:18:02.418 [nt.ItemStatePredictedEvent] - BackDoor_Dimmer_2 predicted to become ON
2019-12-19 16:18:02.429 [nt.ItemStatePredictedEvent] - BackDoor_Dimmer_1 predicted to become ON
2019-12-19 16:18:02.437 [vent.ItemStateChangedEvent] - BackDoor_Dimmer_2 changed from 0 to 100
2019-12-19 16:18:02.441 [vent.ItemStateChangedEvent] - BackDoor_Dimmer_1 changed from 0 to 100
2019-12-19 16:18:03.930 [vent.ItemStateChangedEvent] - BackDoor_Dimmer_2 changed from 100 to 10
2019-12-19 16:18:03.940 [vent.ItemStateChangedEvent] - BackDoor_Switch_2 changed from OFF to ON
2019-12-19 16:18:03.974 [vent.ItemStateChangedEvent] - BackDoor_Dimmer_1 changed from 100 to 10

Here is the log with the group as a Switch:

BackDoor_Sensor changed from CLOSED to OPEN
2019-12-19 16:52:49.399 [ome.event.ItemCommandEvent] - Item 'gSideLights' received command ON
2019-12-19 16:52:49.408 [ome.event.ItemCommandEvent] - Item 'BackDoor_Switch_1' received command ON
2019-12-19 16:52:49.418 [ome.event.ItemCommandEvent] - Item 'BackDoor_Switch_2' received command ON
2019-12-19 16:52:49.424 [nt.ItemStatePredictedEvent] - BackDoor_Switch_1 predicted to become OFF
2019-12-19 16:52:49.430 [nt.ItemStatePredictedEvent] - BackDoor_Switch_2 predicted to become ON
2019-12-19 16:52:49.453 [vent.ItemStateChangedEvent] - BackDoor_Switch_2 changed from OFF to ON
2019-12-19 16:52:49.842 [ome.event.ItemCommandEvent] - Item 'gSideLights' received command ON
2019-12-19 16:52:49.847 [ome.event.ItemCommandEvent] - Item 'BackDoor_Switch_1' received command ON
2019-12-19 16:52:49.851 [ome.event.ItemCommandEvent] - Item 'BackDoor_Switch_2' received command ON
2019-12-19 16:52:49.896 [nt.ItemStatePredictedEvent] - BackDoor_Switch_1 predicted to become OFF
2019-12-19 16:52:49.898 [nt.ItemStatePredictedEvent] - BackDoor_Switch_2 predicted to become ON
2019-12-19 16:52:51.414 [vent.ItemStateChangedEvent] - BackDoor_Dimmer_2 changed from 0 to 10

Only one bulb on, and the sitemap reflects it. But this is curious, when the ON command is sent:

BackDoor_Switch_1 predicted to become OFF

I also swapped (ON, OFF) to (OFF,ON) and the behavior reverses. BackDoor_Switch_1 is ON, but BackDoor_Switch_2 is off.

Removing the OR and using the Switch:

2019-12-19 17:07:08.846 [nt.ItemStatePredictedEvent] - BackDoor_Switch_2 predicted to become ON
2019-12-19 17:07:08.859 [ome.event.ItemCommandEvent] - Item 'gSideLights' received command ON
2019-12-19 17:07:08.864 [nt.ItemStatePredictedEvent] - BackDoor_Switch_1 predicted to become OFF
2019-12-19 17:07:08.869 [nt.ItemStatePredictedEvent] - BackDoor_Switch_2 predicted to become ON
2019-12-19 17:07:08.872 [vent.ItemStateChangedEvent] - BackDoor_Switch_2 changed from OFF to ON
2019-12-19 17:07:08.875 [GroupItemStateChangedEvent] - gSideLights changed from ON to UNDEF through BackDoor_Switch_2
2019-12-19 17:07:08.879 [nt.ItemStatePredictedEvent] - BackDoor_Switch_1 predicted to become OFF
2019-12-19 17:07:08.884 [ome.event.ItemCommandEvent] - Item 'BackDoor_Switch_2' received command ON
2019-12-19 17:07:08.888 [ome.event.ItemCommandEvent] - Item 'BackDoor_Switch_1' received command ON
2019-12-19 17:07:08.896 [nt.ItemStatePredictedEvent] - BackDoor_Switch_2 predicted to become ON
2019-12-19 17:07:08.907 [nt.ItemStatePredictedEvent] - BackDoor_Switch_1 predicted to become OFF
2019-12-19 17:07:08.912 [GroupItemStateChangedEvent] - gSideLights changed from ON to UNDEF through BackDoor_Switch_2
2019-12-19 17:07:10.437 [vent.ItemStateChangedEvent] - BackDoor_Dimmer_2 changed from 0 to 10

One bulb on.

15

Okay, let’s analyse a little.

Your Group gets commanded twice inside a few milliseconds.
At the least, there’ll be the unwanted effect of doubling up on simultaneous commands flooding your zwave, reducing performance, so you’ll probably want to fix that.

You may have two rules doing same thing there, while you’ve been developing.

Or maybe your sensor generates many updates. Perhaps it’d be smarter to trigger your rule from a change, rather than an update.

Anyway, that’s not the complaint you started with. As expected, commanding the Group passes a copy of the command to all members. Let’s follow just one

Alright, we start off with the double command. That should kick off the binding to transmit to the target devices, it’s up to the binding to manage queuing that.
Next, the autoupdate feature works. This listens for commands and guesses the likely outcome, and applies an “internal” update in openHAB, so as to provide a snappy UI even with sluggish devices. So that’s the “predicted to become” part.
The guess is just a guess - autoupdate doesn’t know in detail how your dimmer works. Does it come on at full brightness, or resume last brightness? Best it can guess is 100%
So next we see the state change to 100%. Only one change, even though it gets autoupdated twice, because its already 100% for the second update.
That’s all over in a few milliseconds.
Meanwhile the zwave network does its thing.
A second a half later, a “real” update arrives - this is from the device via the binding, and changes state to 10%

That looks correct to me, assuming your dimmer did a resume to 10% ?? which depends on the device.
We end up with both dimmers at 10% i.e. “on”, what did your UI think?

I don’t know what your ‘backdoor switch’ Items are, but note that bindings will influence autoupdate’s guesswork. When I’ve seen autoupdate produce unexpected OFF prediction for ON command, the Item’s channel/thing has been misconfigured.

16

excellent advise, it is easy to make silly little mistakes :+1:

17

Both Things are configured the same.

18

Check one of my earlier replies. My Group, Item and rule definitions are there. Not only are there no typos, if I reverse the Group:OR(ON, OFF) to Group(OFF, ON), the behavior of the bulbs also reverses.

19

Well, you got a bunch of stuff going on. You can look overall, see some pattern, or you can pull at each thread and see where it leads.

This is pretty much a nonsense.
A Dimmer Item, which includes a Group of type Dimmer, has a numeric state 0 - 100
So looking to populate that from OR-ing ons and offs is not likely to give the results you want.

So, what do you want here?
Do you actually care about the Group state at all?
You might use
Group:Switch:OR(ON,OFF) gSideLights
if you want a simple on/off indication.
(a bit magic allows that to work with dimmer members.)
Or, you might use
Group:Dimmer:AVG gSideLight
or
Group:Dimmer:MAX gSideLights
if you want some kind of indication of what member dimmers are dong.

Have a play with that to get the effect you want.
Bear in mind Items can members of more than one group - you might for example have dimmers in one switch-type group purely for display, and also in another dimmer-type so that you can group command 50%

So far as I can see in your events.log , your individual dimmers are acting as I would expect.

You individual switches look to be acting odd, but those Item definitions are still secret.
We’ve not seen the sitemap lines you use with BasicUI.

20

My item definitions are posted above. My sitemap entries for the bulbs are:

Switch item=BackDoor_Switch_1
Slider item=BackDoor_Dimmer_1 visibility=[BackDoor_Switch_1==ON]
Switch item=BackDoor_Switch_2   
Slider item=BackDoor_Dimmer_2 visibility=[BackDoor_Switch_2==ON]