Issue controlling Loxone items through Alexa group

I have setup Openhab with Loxone binding and with openHab Cloud in order to control the items through Alexa.

I can control each item (lights) separately through the “basic UI” and through Alexa.

I have created groups in Alexa. When I turn off a group composed of two lights there is no problem (both turn off).

The issue arises when the group is composed of more than two items. When I send a command to the group, only two from the several items react. Moreover, it are not always the same items that react to the command.

I believe it is a problem of communication between openHab and Loxone as in openHab, it seems the command is passed correctly although it is not the case in reality:

In this example, although it appears that the 3 lights are off, in reality, one remains on.

Anyone having the same issue? And a solution?

Can you show to what channels those three items are linked and to what functional blocks they correspond in Loxone? Also, can you please enable debug traces for Loxone (log:set DEBUG org.openhab.binding.loxone) and post the logs from that situation? Thanks.

Hi @ppieczul , thanks again for your help!

The 3 lights are connected to a lighting controller.

image

Output of debug for turning on the group through Alexa app:


Nevertheless in reality, only 2 lights are randomly turned on (i.e. not always the same lightes)

Output when turning off the group:


Again, most of the time, only 2 of the 3 lights turn off…

Thanks for more data. From the logs it looks like all three lights are set to on and each of the three commands is acknowledged by the miniserver. However, Miniserver reports back the status of only two of the changed lights. I suppose this may be some problem in the Miniserver, where the quickly sent commands for multiple outputs of a single lighting controller will not complete all, like there was not queue in the Miniserver for the commands. However, the API spec does not specify that there are any restrictions with sending the commands as long as each command reception is acknowledged by the miniserver and here it is the case. I can think of two solutions. First, report a bug to Loxone. Second, create a workaround in the binding that would artificially delay sending commands to multiple outputs of a lighting controller, as long, as a changed state is not received back from the miniserver. This would be somehow complicated to create and pretty artificial, so I would lean to reporting a bug to Loxone.

See answer from Loxone:

Not very helpful…

I will try to reproduce this with some test. But first let’s figure out the sleep behavior in your other thread.