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