Not all group members triggered are reacting

For the shutters I’ve defined groups for different rooms and floors. To trigger up or down for the shutters I just give the command to the group.

In the openhab 1.8/ 1.9 it worked as expected.

After upgrading to openhab 2.4 some of the shutters randomly are not reacting. If I give the trigger command a 2nd or 3rd time they are reacting.

The shutters which are not reacting first time are different from command to command. Mainly the same but always different. Some of the shutters are always going down with first command, others after 2nd or 3rd command. But as said not always the same shutters. Can be that one shutter is going down after 3rd command, next time after first.

My code:

item definition (only a subset):


Group:Rollershutter		gRollladenEG 		"Rollladen EG [(%d)]" 						<rollershutter>		(gRollladen)
Group:Rollershutter		gRollladenEGs 		"Rollladen EG einzeln [(%d)]"				<rollershutter>


/* Rollladen Zimmer EG */

Group:Rollershutter		gShutterEGWohnen 	"Rollladen Wohnzimmer [(%d)]"				<rollershutter>		(gRollladenEG)
Group:Rollershutter		gShutterEGDining 	"Rollladen Essen [(%d)]" 					<rollershutter>		(gRollladenEG)
Group:Rollershutter		gShutterEGKitchen 	"Rollladen Küche | Speisekammer [(%d)]" 	<rollershutter>		(gRollladenEG)

Triggering in rule:

rule "Sonnenuntergang_delayed_Informarmation_25minutes"

when
    Channel 'astro:sun:4bb21023:set#event' triggered START

...

// EG
			timer1 = createTimer(now.plusSeconds(100)) [|	{
				sendCommand	(gRollladenEG, DOWN)

You might get what you want by making use of the MQTT group topic instead of the group of openHAB items.
By using the MQTT group topic only one mqtt command is sent and all connected devices react

Have a look in your events.log, to make sure the command is propagated to the Items that you expect.
Then you’ll know it is not a Group issue, but rate of individual commands.

The log is mentioning following:

2020-04-27 19:57:34.736 [ome.event.ItemCommandEvent] - Item 'gShutterEGWork' received command DOWN

2020-04-27 19:57:34.766 [ome.event.ItemCommandEvent] - Item 'Shutter_GF_Work_J_1' received command DOWN

2020-04-27 19:57:34.797 [ome.event.ItemCommandEvent] - Item 'Shutter_GF_Work_J_2' received command DOWN

2020-04-27 19:57:34.827 [ome.event.ItemCommandEvent] - Item 'Shutter_GF_Work_J_3' received command DOWN

2020-04-27 19:57:34.848 [ome.event.ItemCommandEvent] - Item 'Shutter_GF_Work_J_4' received command DOWN

2020-04-27 19:57:34.856 [nt.ItemStatePredictedEvent] - Shutter_GF_Work_J_1 predicted to become DOWN

2020-04-27 19:57:34.881 [nt.ItemStatePredictedEvent] - Shutter_GF_Work_J_2 predicted to become DOWN

2020-04-27 19:57:34.902 [nt.ItemStatePredictedEvent] - Shutter_GF_Work_J_3 predicted to become DOWN

2020-04-27 19:57:34.924 [nt.ItemStatePredictedEvent] - Shutter_GF_Work_J_4 predicted to become DOWN

2020-04-27 19:57:34.947 [GroupItemStateChangedEvent] - gShutterEGWork changed from 100 to UNDEF through Shutter_GF_Work_J_1

2020-04-27 19:57:34.950 [vent.ItemStateChangedEvent] - Shutter_GF_Work_J_1 changed from 0 to 100

2020-04-27 19:57:34.953 [vent.ItemStateChangedEvent] - Shutter_GF_Work_J_4 changed from 0 to 100

2020-04-27 19:57:34.956 [GroupItemStateChangedEvent] - gShutterEGWork changed from UNDEF to 100 through Shutter_GF_Work_J_4

2020-04-27 19:57:52.351 [vent.ItemStateChangedEvent] - Date changed from 2020-04-27T19:56:52.321+0200 to 2020-04-27T19:57:52.324+0200

Three shutters: J1, J2 and J4 went down, J3 stayed up.

group definition:

Rollershutter Shutter_GF_Work_J_1	"Thomas: Terrasse" 			    (gShutterEGWork, gRollladenEGs) 	    { channel="knx:device:bridge:thomas:Shutter_GF_Work_J_1" }
Rollershutter Shutter_GF_Work_J_2	"Thomas: Garten links" 		    (gShutterEGWork, gRollladenEGs) 	    { channel="knx:device:bridge:thomas:Shutter_GF_Work_J_2" }
Rollershutter Shutter_GF_Work_J_3	"Thomas: Garten rechts" 	    (gShutterEGWork, gRollladenEGs) 	    { channel="knx:device:bridge:thomas:Shutter_GF_Work_J_3" }
Rollershutter Shutter_GF_Work_J_4	"Thomas: Feld" 				    (gShutterEGWork, gRollladenEGs) 	    { channel="knx:device:bridge:thomas:Shutter_GF_Work_J_4" }

item definition:

        Type    rollershutter   :   Shutter_GF_Work_J_1	    "Thomas: Terrasse" 			[ upDown="3/0/29", stopMove="3/0/30" ]
        Type    rollershutter   :   Shutter_GF_Work_J_2	    "Thomas: Garten links" 		[ upDown="3/0/31", stopMove="3/0/32" ]
        Type    rollershutter   :   Shutter_GF_Work_J_3	    "Thomas: Garten rechts" 	[ upDown="3/0/33", stopMove="3/0/34" ]
        Type    rollershutter   :   Shutter_GF_Work_J_4	    "Thomas: Feld" 				[ upDown="3/0/35", stopMove="3/0/36" ]

sitemap commando:

            Frame {
				Switch	item=gShutterEGWork		mappings=[UP="↥", STOP="X", DOWN="↧"]
				Group	item=gShutterEGWork
			} // END Frame Rollladen

the principle worked within openhab 1.9 without any problems.
Of course I can try to define groups within KNX and trigger the group address of KNX. But this is not the purpose for groups in openhab I assume.

The openHAB Group is working as expected, propagating the command out to four “real” Items in around 90mS.

Similar old thread -


I’m sorry, but I misconcepted that you would get using MQTT.
@rossko57 Thanks for stepping in.

Using grouped items in openHAB would enable to use a single openHAB command to trigger grouped items to do something. The downside is, each grouped device would need it’s own command to start that something. The command could be different for grouped item ( like KNX and MQTT).
Using the group concept of the binding ( if available) would use a single openHAB command to start single group command of the binding. All things configured for this group would react upon that.
IMHO the problem you observed is caused by KNX commands being skipped.

what is really annoying is, that it worked till the upgrade to openhab 24.
I used 1.8/ 1.9 on a mini pc connected windows via WLAN IP interface from Weinzierl.
Now I’m using raspberry connectd via USB, open 2.4 and a lot of things were not easily transferred, because of working differently…
At the end I assume I have two possibilities:

  1. define a group telegram within KNX
  2. call the shutters sequencially

There’ll be a lot of timing differences between OH1 on a PC and OH2 on a Pi.

Apparently.
Due to the fact that a lot of applications will be on a raspberry it’s a pitty that it’s not working as it should…

Based on observations I made a long time ago, so I might be misremembering things, what is probably happening is that the 1.x binding was much less efficient in how it published messages meaning the messages were far enough apart that the KNX could process them all. The new binding is more efficient resulting in the messages being published faster than KNX can handle.

The timing of the old approach worked for you but that doesn’t necessarily mean it was working as it should. It was mostly just a fluke. The MQTT binding is working as it should when it publishes all the messages it is asked to publish as quickly as it can without missing any of them.

You can verify that everything is in fact working as it should for the MQTT binding by attaching an MQTT client like MQTT.fx or MQTT Explorer. If all the topics receive a message when you command the Group than the binding is behaving as it should. The fact that it worked for you before was a fluke of timing and was never going to continue to work forever anyway. Any thing that depends on a computer or software being slow to work never does.

If some of the messages are in fact not published, there is a bug somewhere in the binding and an issue needs to be filed to correct it.

And there is a bugfix already for knx… see


So it seems it was an calimero bug, or at least calimero now takes care of the timing.

knx2 should be updated…

Sounds very promising. Thank you!
Unfortunately I was not able to follow the links or download some content.
What exactly do I have to replace or how can I build in the bug fixed versions?

I use the “physical” groups within KNX using group telegrams. Now it works, all items are triggered.
The big drawback of this solution is, that the physical actors are accepting only a limited number of telegrams they’re reacting.
That means, that you cannot involve one physical knx items in a lot of different groups, because the item (e.g. switching actor) is accepting only 8 or 10 entries per 4 items in one switching actor.
But anyhow. For the main important items you can use that “work around”

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.