Mehr als eine Multicast Adresse pro Projekt

The idea is good and has been in place in the past as well. However, I believe that when projects reach a certain size and require multiple multicast, they should not be maintained in a single ETS, but rather in multiple ETS project files.

It is recommended to approach this by building

This is an exclusive opinion, but it is difficult to implement in practice and, especially in practical work, means that several KNX projects have to be created for one and the same building. This can lead to errors in the topology and the group addresses. From my point of view it makes more sense to be able to manage several multicast addresses in a project. The programmer should be able to make this decision.

Hy, Marc. I am not entirely clear on the use case where a single building would have multiple MAC addresses assigned to it. What would be the advantage of this approach

Hi Alexander, a customer wanted to set up several offices in one building with different tenants. Each tenant should get their own multicast address so that they do not see the telegrams of the others. It's a project, but it has to be divided into different KNX projects, which makes it confusing. And there are a lot of projects like this.

Of course, this application does not appear in every project, but the programmer should be given the opportunity to make this setting if necessary. Finally it worked.

Hi Marc, you can make your project initially as one, to make sure you don't have any problem with physical and group address, and then use the ETS application "Split and Merge" to split the original project into several accordingly with the your needs (divide them in areas, lines, etc.) and them define in each subproject the multicast address that's fit you.

Dear Marc,

I understand your approach and I have actually implemented it myself in the past :) However, I now believe that it is cleaner to have a separate project for each task, especially considering the data transfer and visualization aspects, as well as the secure handling of keys.

By the way, once you have your own MC area, you are completely free in terms of topology and group addresses and can take advantage of this. That's another reason why having a separate project makes sense.

Just changing the MC address does not provide any protection against unauthorized access.

It's an interesting topic to discuss the best and most sensible approach here. One idea could be to program a secure IP router and adjust the filter tables accordingly, if there is a system administrator available.

Hi Paolo, hi Alexander,

the solutions don't convince me at all. What happens if, after separating the project via the app, I want to rejoin the project and I have used a separate multicast address in each project? Ultimately, I just wanted to point out at this point that it is not always good to switch off useful functions. Ultimately we will all have to live with the solution that has now been set. From my point of view more complicated but of course solvable. Thanks for the lively discussion.

The crux of the matter is that there exists a fundamental issue where, for instance, a line with the designation 1.1.0 and a group address 1/1/1 that is linked to an MC address bear no relation to any other MC address. Fortunately, this flaw has been rectified in the ETS.

In my view, the solution for such a situation requires a newer, more comprehensive approach from the ETS. One plausible remedy would be to introduce an additional higher-level category in the topology, building, and group address views, which encompasses a multicast range. This would ensure precision and orderliness.

However, implementing such a solution is likely to be a time-consuming process. Nevertheless, it's always beneficial to have an exchange of ideas on such matters as we never know what insights we may gain. :-)