KNX/EIB All Off: limitations ?

[Warichet]

Hi,

I wonder if there are limitations to the All Off procedure.
I've:
58 GA on line 1.1.x
24 GA on line 1.0.x
so, a total of 82 GA

When using the All Off, I guess I'm sending a telegram to all 82 GAs, at exactly the same time.
Could it be that there is a limitation ? could some telegrams get lost ?

I noticed on 2 occasions, that some lamps do not go Off, bizarre.

Any hint, please ?

[Gaston]

Hi Warichet,

No in the case of "all-off" it shoul dbe 1 single GA where 82 CO are listeing to. This is no problem at all unless all actuators have status object that are sent upon receiving a switching telegram.

[Warichet]

No in the case of "all-off" it should be 1 single GA where 82 CO are listeing to.

Ouups, I ill formulated my question
Indeed, I've a single GA where 82 CO are listening to.

This is no problem at all unless all actuators have status object that are sent upon receiving a switching telegram.

Didn't think about that, but even if all actuators send their status object, this shouldn't prevent some actuators from switching off, unless some status telegrams are already coming back. I guess at 9.600 baud, there is plenty of room for 1 All-Off telegram and 82 status telegrams ?
I noticed that it is always the same actuator being "lazy"

[Gaston]

Didn't think about that, but even if all actuators send their status object, this shouldn't prevent some actuators from switching off, unless some status telegrams are already coming back. I guess at 9.600 baud, there is plenty of room for 1 All-Off telegram and 82 status telegrams ?
I noticed that it is always the same actuator being "lazy"

You are right the light shoul dbe switched off anyway since it depends only on one single frame. What is most often seen is th elight switching off but th estatu snot correctly displayed as the packet was not sent in the flood.

If the flood can be handeled does not depend on the timing alone where 57, 1-bit status replies would fit into a second. The problem is more toward the number of actuators (i.e. BCUs). The higher th enumber the higher the chance of collision. If actuators do have to many collisions they may drop the packet.

But also channels not switching could be explained in my eyes indirectly by the status replies depending on the interna of the actuator. Especially if it has a BCU1 and/or no co-processor.

Unless you are doing tests with all lights on and you are using status objects and if your actor supports it, you may try to set the "status send" to only send when the status changes (i.e. "all off" with a channel already off would then not send a status). And see if th ebehavior changes.

Cheers,
Gaston

[Warichet]

What is most often seen is the light switching off but the status not correctly displayed as the packet was not sent in the flood.

I think that's the case at hand.

The problem is more toward the number of actuators (i.e. BCUs).

Got it right !
So I checked the number of BCUs involved:
9 on 1.0.x
25 on 1.1.x
So, a total of 34 BCUs. Heck ! we aren't close to the limit ! (57) even with some retries & delay.

But also channels not switching could be explained in my eyes indirectly by the status replies depending on the internal of the actuator. Especially if it has a BCU1 and/or no co-processor.

I think I'll drop this hypothesis if I consider that the actuator did indeed do the switch, but failed to send/update the status.
The case at hand is a Merten 647890 8x230V.
The mask says: 2.1 so I guess it's a BCU2

Unless you are doing tests with all lights on and you are using status objects and if your actor supports it, you may try to set the "status send" to only send when the status changes (i.e. "all off" with a channel already off would then not send a status).

Hé hé clever idea.
My first goal was to understand what's going on, and try to find out if it's a hard/soft problem (altough I would hate to replace an 8 channel actuator).
For a moment, I thought bypassing the problem and moving the All-off to the HS, put it into a sequence and sending a batch of 10 "Off" every second. That would sure cure the problem, but your suggestion is much better.

Thank you Gaston.

[Gaston]

Got it right !
So I checked the number of BCUs involved:
9 on 1.0.x
25 on 1.1.x
So, a total of 34 BCUs. Heck ! we aren't close to the limit ! (57) even with some retries & delay.

I think you are mistaking here. 57 is no limit, but the packets per second. This figure is not directly involved here. This problem has nothing to do with the line capacity but the number of BCUs trying to send together.

In your case you have 34 BCU involved in sending 82 GAs on two lines. This makes a mathematical average of roughly 3 GAs per BCU and 17 BCUs per line.

Since every BCU in the Line receives teh "All Off" GA at the same time they will most probably start sending the Status at the same time as well, thus 17 BCUs are going to collide, one single winning the collision, 16 having to retry. They'll wait for the and of th ecurrent winner + 50bits and retry, most probably, many or all at the same time. So collision retry, and so on.

As far as I know the specififcations of teh KNX do not specify the exact behavior after multiple collisions, i.e. how many times to retry but it is likely that BCUs are going to drop packets they do not get rid off. So the more BCUs are involved th elikelier this drop would be.

The problem may also be emphased if some status are not used and thus not ACKnowleged or the Linkecoupler is setup to pass any packet (no routing table) and thus will transfer unused packets to the other line. As these packets will be repeated 3 times this will accentuate the above situation.

[Warichet]

I think you are mistaking here. 57 is no limit, but the packets per second.

Thank you for putting me right.

In your case you have 34 BCU involved in sending 82 GAs on two lines.

I made a mistake (I'm very goog at that )
I counted all devices part of the "All Off".
I should have counted only the actuators, as they are sending the status (not PB BCU). I ended up with 11 actuators on 1.1.x and 4 on 1.0.x

Just to avoid confusion .... I had the impression that only BCU are sending the status, but imho, all GAs have to be counted. That is, if an actuator has 6 GAs part of the "All Off", it will send 6 status telegrams, right ?

every BCU in the Line receives the "All Off" GA at the same time they will most probably start sending the Status at the same time as well, thus 17 BCUs are going to collide

I seem to remember that the protocol is CSMA/CA, A for avoidance (as opposed to CSMA/CD D for detection, as in Ethernet). I thought this protocol would minimise the collisions ?!?

but it is likely that BCUs are going to drop packets they do not get rid off.

That might be the case here, but I'm puzzeled by the fact that it happened on the same 2 channels of the same actuator.

[Gaston]

I should have counted only the actuators, as they are sending the status (not PB BCU). I ended up with 11 actuators on 1.1.x and 4 on 1.0.x

Just to avoid confusion .... I had the impression that only BCU are sending the status, but imho, all GAs have to be counted. That is, if an actuator has 6 GAs part of the "All Off", it will send 6 status telegrams, right ?

You are right but the number of the telegrams sent is not th eproblem I am speaking about as this would only result in some 1.5 second delay.

Imagine you have a single 80 channel actuator each sending a status. The BCU will than have an internal queue of 80 telegrams to be sent and if we make abstraction of any other packets on th eBus, these will be sent one by one within 1.5 seconds with no collision.

If however you have 10 actuators each having 8 channels each, each actuator will have a 8 packet queue but they will collide resulting in one sending and 9 having to retry, and than th enext round of collisions get fired off. This is the difference.

I seem to remember that the protocol is CSMA/CA, A for avoidance (as opposed to CSMA/CD D for detection, as in Ethernet). I thought this protocol would minimise the collisions ?!?

Well this depemnds on th epoint of view. CA ("Collision avoidance") is not really avoiding the collision but avoids the time to be lost. The CSMA is what is used for best try to avoid collision in both cases (CD & CA). In a CD protocol a collision is detected and both senders stop sending rescheduling the packet. So the sending time from the first bit send up to the next first bit (after the reschedule) is lost time. In CA there is still a collision but only one sender will "see" it and immediatally stop. The collision itself is not avoided but any corruption due to it is avoided so that one sender can continue to send.

Since the interrupted sender has detected the collision he may well decide ot give up sending aftre a repeated number of interruptions due to collisions where the other sender "wins" the collision.

That might be the case here, but I'm puzzeled by the fact that it happened on the same 2 channels of the same actuator.

Well both situations,the problem hitting different channels/actuators and same channels/actuators could be explained by the bus and actuator internal mechanics.

[Warichet]

Imagine you have a single 80 channel actuator each sending a status. The BCU will than have an internal queue of 80 telegrams to be sent and if we make abstraction of any other packets on th eBus, these will be sent one by one within 1.5 seconds with no collision..

Excellent example. Point taken

CA ("Collision avoidance") is not really avoiding the collision but avoids the time to be lost.

OK, fine
I've been puzzled by CSMA/CA since day one. Even the concept hurts me. What prevents 2 participants to listen to the bus, decide it is free and fire a packet at exactly the same µsec ? Nothing ! As you said, only the consequences can be minimized.

Well both situations, the problem hitting different channels/actuators and same channels/actuators could be explained by the bus and actuator internal mechanics.

Mmm, not sure, I've to experiment a bit more and get some additional facts.

Thank you