KNX/EIB How to re-organize 2 lines with filtering

[Warichet]

Hi,

My installation has grown a bit anarchic over time.
Now, I want to re-organize my 2 lines, mainly
- enable filtering at the LC
- move the HS from 1.1.x to 1.0.x

What is the best procedure to do this, without much disruption nor risks ? I've no experience with filtering i.e. correctly building the filter tables.
I fear unforeseen consequences. Most of the devices are on 1.1.x, so I understand that much of the traffic issued by the HS will go over the LC

Thanks for any hint.

[Warichet]

OK, I'll do my best.

The way I see it:
1a) change the PA of the FT 1.2 from 1.1.254 to 1.0.254
1b) physically move the HS from segment 1.1.x to 1.0.x
1c) re-boot

2) enable filtering at the Hager TA006. No idea about how to do that.
The doc of the LC says: "build automatically by ETS", ah ?!? it's a bit short.
Just enable filtering in ETS and re-program de device ?

3) Open issues:
HS dummy application, how to re-configure ?

What can go wrong ? (Murphy is looking at me)

[SebastianFey]

2) enable filtering at the Hager TA006. No idea about how to do that.
The doc of the LC says: "build automatically by ETS", ah ?!? it's a bit short.
Just enable filtering in ETS and re-program de device ?

Filter tables are automatically built by the ETS. Each group that is connected to devices in more than one line is added to the filter tables of all the couplers between those lines. A coupler in filter mode only lets those GA pass that are listed in its filter table. (there is no space for main groups 14+15, so these are either never or always forwarded).

Your problem: the ETS doesnt know about the HS and no one knows which groups your HS is really connected to.
1. You have to determine all the groups the HS listens to and sends to
2. put a dummy-object on line 1.0 and connect all these groups with the dummy.
3. have a look at the filtertable (context-menu of the line coupler)
4. download GA to the coupler.

if you dont do this the homeserver doesnt get the status objects it listens to (eg a temp-sensor sending on line 1.1, not forwarded by the coupler). Or the HS sends some GA maybe to switch on a relais on line 1.2, but this GA is not forwarded because it is not listed in the table.

[Warichet]

Hi Sebastian,

Filter tables are automatically built by the ETS.

OK, but how/when do I know when the building process is fnished and I should re-program the LC ?

Each group that is connected to devices in more than one line is added to the filter tables of all the couplers between those lines.

I understand the filtering happens at the GA level (not the PA).
Filtering happens only when a GA has a KO from 1.1.x and a KO from 1.0.x ? (which is seldom the case)

Your problem: the ETS doesnt know about the HS and no one knows which groups your HS is really connected to.
1. You have to determine all the groups the HS listens to and sends to

But .... but ... that's almost all GA either for the Visu or GLE.
How should I carry out this inventory ? manually looking at all pages of the Visu and GLE, ouuuch, this will take me till next year

2. put a dummy-object on line 1.0 and connect all these groups with the dummy.
3. have a look at the filtertable (context-menu of the line coupler)
4. download GA to the coupler.

OK, understand

if you dont do this the homeserver doesnt get the status objects it listens to (eg a temp-sensor sending on line 1.1, not forwarded by the coupler). Or the HS sends some GA maybe to switch on a relais on line 1.2, but this GA is not forwarded because it is not listed in the table.

I vaguely fear such problems without being able to identify them clearly, as you did.
Looks like ETS and the HS are not good friends ?!?

Any pointer to some practical doc about the topic ? (just to avoid that the dummy asks twice the same question )

Thanks for taking the time and trouble to educate a filtering newbe

[SebastianFey]

OK, but how/when do I know when the building process is fnished and I should re-program the LC ?

I know, the ETS is rather slow, but this is done in "real time". Just try it out: change any GA and see that the coupler loses its "Grp-programmed-flag" (Column "Programmierstatus" in german)

I understand the filtering happens at the GA level (not the PA).
Filtering happens only when a GA has a KO from 1.1.x and a KO from 1.0.x ? (which is seldom the case)

Both adresses are of intereset: filtering happens when a GA is connected to PA in different lines.
Yes, this should be seldom the case, but its not in your case, cause you want the HS to know everything.

But .... but ... that's almost all GA either for the Visu or GLE.
How should I carry out this inventory ? manually looking at all pages of the Visu and GLE, ouuuch, this will take me till next year

In your case filtering doesnt make sense imo. You dnont need it in small projects. The coupler still gives you galvanic isolation of line 1.0 and 1.1, so a short circuit on one line will not kill the other.

This is not a problem of the HS alone. Only "bigger" visualization solutions bring the tools to handle this better. Or very small solutions like the MT701 which are full EIB-products with a database and so known to the ETS. These provide info for the filtertables.

I dont know any good literature but the official KNX-courses. Maybe you can get them from someone in english. EIB is teached to the german electricians so there should be some books out there.

[Warichet]

but its not in your case, cause you want the HS to know everything.

Right, but isn't that the case for ALL installations having a HS and more than 1 line ?
Looks like a generic problem, I guess many specialists have stumbled on this problem, looong before me.

In your case filtering doesnt make sense imo. You don't need it in small projects.

You are right at the core of my problem
It all started with the "All-Off" command. You might have seen it here

The conclusions I could draw: please correct me if I'm wrong
1) reconfigure the actuators to send their status only on change (that was already the case before the problem)
2) enable filtering to avoid the re-transmit of un-acknowledged packets (3 times) as mentionned in Gaston's argument
3) drop the whole stuff from ETS (this would mean failure for KNX to handle the situation) and move it to a Sequenz of the HS, and fire a group of 10 "All-Off" every second. It's a kludge

So, imho, Gaston's argument does make sense, maybe only to avoid the re-transmit of un-acknowledged packets from the "other line", hence I'm seriously considering filtering and its implications.

The coupler still gives you galvanic isolation of line 1.0 and 1.1, so a short circuit on one line will not
kill the other.

Full ack, strong argument, that was my first reason to implement a LC.

This is not a problem of the HS alone. Only "bigger" visualization solutions bring the tools to handle this
better. Or very small solutions like the MT701 which are full EIB-products with a database and so known to the ETS. These provide info for the filtertables.

OK. Agree.
I try to make the best of what I've at hand.
Does it mean that there is no nice & clean solution for the case at hand ? Sending an "All-Off" command to 82 GA (without dropping some status packets), is that an abnormal requests ? I guess it isn't, after all, as you mentionned, my case is to be considered as a (very) small installation. Heck, what about 3-4 lines and 200 GAs with a HS ? Are we bumping into the limits of the architecture ? hard to believe, but without a clean solution ....

Thank you for your right-to-the-point arguments, much appreciated

[Warichet]

Hi,

I'm still not confident with the move.

1. You have to determine all the groups the HS listens to and sends to

Suppose the HS has already moved to line 1.0.x, in that case should I determine all the groups the HS listens to or just the ones that are on line 1.1.x ? I guess all the GAs on line 1.0.x, near the HS are not concerned, right ?

If I manage to make the move correctly, the only benefit I can see so far, is to avoid the retransmit (3x) of unacknowledged packets.