Aufbau Gruppenadressen

[alorenzen]

Man kann ja auch mit grade und ungrade Gruppenadresse arbeiten zur Unterscheidung ob die Gruppenadresse beim Aktor nun was steuert oder ne statusmeldung ist.
1/1/1 Licht an/aus
1/1/2 Licht an/aus Status

An vielen Stellen muss man sowieso meist beides verknüpfen da find ich ne eigene Mittelgruppe für die ganzen Statusmeldungen wieder eher unübersichtlich.
Zumal du bei nur einer Mittelgruppe für Statusmeldungen auch beim Licht dir die Zahlen ausgehen wenn du nen Status sowohl für an/aus als auch für den Dimmwert hast.
Sprich: Mittelgruppe schalten, Mittelgruppe absolutwert, Mittelgruppe Statusmeldungen
wenn du nun fürs schalten 1/1/1 hast. Für den absolutwert 1/2/1 dann haste bei 1/3/1 nur eine Sache die du verknüpfen kannst und bei 1/3/2 würde es wieder nicht ins system passen.

Wenn du Gewerke für die Hauptgruppen machen würdest könntest du da auch jeweils ne eigene Hauptgruppe nur für Statusmeldungen des jeweiligen Gewerks machen , sprich 1/x/x Licht 2/x/x Licht Status

Die Mittelgruppe für Gewerk ist eine Empfehlung und stammt noch aus Zeiten, wo KNX primär Gewerbebau war und man die Hauptgruppen und Gas für die Strukturierung brauchte. Und es auch nicht so viele Gewerke gab. Kein Ahnung welcher Depp damals gedacht hatte da sparen zu müssen.
Meine Empfehlung für den Privatbau, die Mittelgruppe für Geschosse und Außenbereich nutzen. Da braucht man selten mehr als 7. Hauptgruppe für die Gewerke.
Ne Strukturierung über die Adresse selbst macht nur bedingt Sinn. Wichtig sind folgende Punkte

- Genug Platz lassen zwischen den einzelnen Adressen damit man einfügen kann
- Bereiche in den GAs für Räume nehmen. Nicht als Strukturierungs-Hilfe, sondern damit es besser lesbar wird. Also z.B. alle Lampen eines Raums hintereinander sind
- Immer alles maximal konfigurieren. Z.B. für Licht immer alle 5 Funktionen/Stati konfigurieren/reservieren. Sollte sich die Ansteuerung mal ändern, muss man nicht verteilen.

Ich habe also z.B. nur 4 Mittelgruppen für 3 Geschosse und Außenbereich verwendet. Die Geschosse sind in Räume aufgeteilt und haben jeweils einen Bereich von 50 GAs. Das ist aber nur eine Möglichkeit. Es gibt weder Vorschriften noch Zwänge.
Wie gesagt dient das aber nur der Übersichtlichkeit. Wichtiger ist die Lesbarkeit.

LD_O02_57 WERT (OG Offener Bereich Wand)

Licht Dimmen - Obergeschoss Raum 2 - Reihenverteiler Nr - Dimmen Wert direkt ansteuern - Lesbare Beschreibung

Die Reihenverteiler Nr. habe ich reingenommen, um im Problemfall nicht ne 2. Doku heranziehen zu müssen, oder wenn was umgeklemmt werden soll.

Ich hoffe mal dass man sich bei der ETS6 dem Problem annimmt und die Adressen in den Hintergrund rücken

Wie soll das den gehen? Du brauchst in jedem Bussystem eine namensgebenden Struktur, damit es für den Normalsterblichen nutzbar wird.
Siehe DNS bei IP. Jetzt könntest du natürlich den Ansatz wie dort fahren, das sich Systeme mit den vergebenen Namen selbst registrieren.
Hilft dann aber nicht viel, weil du ja trotzdem dann auf den KOs die Namen vergeben musst.
Das ganze ließe sich nur mit intelligenten Reihenklemmen (die es nicht gibt) und KNX Integration teilweise erleichtern.
Wenn man Reihenklemmen dann Eigenschaften geben könnte, wie Gebäude/Geschoss/Raum/Position/Funktion, dann könnte die ETS daraus die GAs generieren.
Verbinden musst du sie aber trotzdem.

[ewfwd]

Wie soll das den gehen?

Im Grunde ist es nur eine 16Bit Adresse. Das Problem an in der ETS5 ist dass die Struktur fest vorgegeben ist 31 Hauptgruppen, 8 Mittelgruppen. Für diese feste Struktur besteht in der ETS ja keine Notwendigkeit. Man könnte dort auch einfach ein Ordnersystem einführen welches man beliebig aufbauen kann und die GA entsprechend dort einsortieren.

[luki89]

Also der Status vom Licht ist doch kein eigenes Gewer

Nun ja ich wollte dort auch die Status von den Fensterkontakten rein geben etc. Dann werde ich woll die Status vom Licht in der jeweiligen Gruppe "Beleuchtung" belassen und die Gruppe "Status " in "Alarm" umbenennen. Denke das wäre die Beste Lösung oder?

[DirtyHarry]

Für diese feste Struktur besteht in der ETS ja keine Notwendigkeit. Man könnte dort auch einfach ein Ordnersystem einführen welches man beliebig aufbauen kann und die GA entsprechend dort einsortieren.

Du hast es schon richtig ausgedrückt, für die ETS besteht diese Notwendigkeit nicht. Du kannst schon lange (glaube die ETS3 konnte das schon) davon abweichen und deine GAs aufbauen wie du möchtest, das Zauberwort heißt "freie GA-Struktur". Einstellbar unter Gruppenadressansicht.
Jedoch gibt es auch heute noch viele Geräte die damit nicht zurecht kommen. Als erstes PlugIn-Geräte, außerdem fast alle externen Sachen (Visus etc). Du könntest also kein Projekt in die Visu importieren und müsstest dir alle GAs per Hand wieder in zwei-/dreistufige zurückrechnen und in der Visu anlegen. Auch der CSV- und OPC-Export funktioniert nicht.
In wie weit für die Plugin-Geräte das Häkchen "Erweiterte Gruppenadressen vor Plug-Ins verbergen" ausreicht, ist mir nicht bekannt.

[Gast1961]

Für diese feste Struktur besteht in der ETS ja keine Notwendigkeit. Man könnte dort auch einfach ein Ordnersystem einführen welches man beliebig aufbauen kann und die GA entsprechend dort einsortieren.

Im Prinzip gibt es das ja schon in der ETS Inside: man arbeitet mit Funktionen, die GA die sich dahinter verbergen interessieren nicht mehr. Und somit gibt's auch keinen Bedarf, sich irgendwelche komischen Nummernsysteme als Hilfsmittel zu bauen.

[alorenzen]

Im Grunde ist es nur eine 16Bit Adresse. Das Problem an in der ETS5 ist dass die Struktur fest vorgegeben ist 31 Hauptgruppen, 8 Mittelgruppen. Für diese feste Struktur besteht in der ETS ja keine Notwendigkeit. Man könnte dort auch einfach ein Ordnersystem einführen welches man beliebig aufbauen kann und die GA entsprechend dort einsortieren.

Achso - du meintest eher die Beschränkungen aufheben.
Wird aber nix draus. Weil die Geräte es nicht können.
Nimm IPv4 und IPv6. Müssen die Geräte schon können.
Denkbar wäre eine ähnliche Erweiterung und Proxy in Linienkopplern. "KNXv6" Adressen gehen dann halt direkt und innerhalb einer Linie dann "KNXv4" und über Linienkoppler dann nen "KNXv6" Header.
Aber da müsste sich das Konsortium erstmal mit den Herstellern einigen. Da davon bisher garnix zu hören ist, gehe ich mal nicht davon aus, dass in der ETS irgendwas in der Richtung kommt.

[ewfwd]

Wird aber nix draus. Weil die Geräte es nicht können.

Sie müssen dazu nix können, es ist nur ne andere Darstellung in der ETS die eine bessere Sortierung ermöglicht.
Find es auch dumm Etage, Gewerk, Raum und Funktion alles in den Namen zu packen. Fände es sinnvoller wenn man da entsprechende Eigenschaften für die GAs hätte wo man dann an den passenden Stelllen alles eintragen könnte, wie Raum: __ Gewerk: __ etc.

Ein großes Problem ist dass viele daran scheitern das für sie passende System zu finden oder erst finden sie eins aber irgendwann passt es dann nicht mehr und man muss abweichen von seinem System und es wird unübersichtlicher und unübersichtlicher.

Vorallem bei den "Grundfunktionen" wie schalten, absolut, status vermisse ich da mehr Automatisierung bei der Verknüpfung.

[vento66]

Und wenn Du eine andere Struktur brauchst, weil Die die paar möglichen Räume nicht reichen?

[ewfwd]

Sofern das String bei "Raum" frei wählbar ist gehen mir nicht die möglichen Räume aus. Was nur dumm ist dass die Leute das Feld für den Namen letztendlich fürs tagging missbrauchen weil die ETS keine weiteren Eigenschaften für GAs kennt wo man gescheit alles sauber eintragen könnte.

Im Grunde gehts nur darum dass diese 3 stufigen Adressen dir ein "Ordnersystem" quasi direkt aufzwingt.

[vento66]

Dir vielleicht nicht, aber was machst Du in einem Zweckbau / Bürokomplex? Frei nach dem Motto „is mir egal, sollen sich andere ärgern“?

[ewfwd]

Was soll damit sein? Wo siehst du ne konkret ne Einschränkung?
Du kannst doch genug Eigenschaften für die GA definieren wie Raumname, Raumnummer, Etage, Gebäudename, Gebäudenummer etc.Das Problem ist aktuell eher das das es für viele Informationen dort kein festen Platz gibt sondern die Leute stumpf alles mit in den GA Namen packen.

[willisurf]

Ich denke, was ewfwd meint ist das zukünftige ETS Versionen eine Virtualisierung dsr GAs vornehmen könnten. Es gibt ja genug Meta Informationen über die Objekte und die logischen Verbindungen.
Das wäre natürlich seitens ETS ein gehöriger Aufwand, aber z.B. beim Abspeichern auf Festplatten müssen wir ja auch keine Sektornummern mehr angeben.

[gbglace]

Tagging ist das Stichwort. Es gibt zwar das Beschreibungsfeld und den Namen als Freitext aber intelligent darinnen suchen und Filtern lässt sich nicht.

Die nummerische GA-Struktur ist eine Möglichkeit sowas abzubilden aber eben in der Struktur wenig flexibel. Die GA definiert nur den Transportweg im Bus, das stört ja auch niemanden, die Anzahl ist soweit auch ausreichend um reichlich Informationen zu bewegen.

Tags zu vergeben wäre auch erstmal nur was, was die ETS benötigt.
Als GA Eigenschaft ist es natürlich auch interessant bei Visus usw. Die Hersteller müssten sich dann anpassen, damit der Informationsmehrwert für den entwickelnden User auf dem Server dann auch dort sichtbar wird.

Da allerdings auch niemand einen starren Katalog von Tags akzeptieren würde, gehört bei der Vergabe natürlich auch eine ordentliche Portion Disziplin dazu, damit es nicht viele Begriffe gibt die alle das gleiche meinen aber nicht unterschiedlich geschrieben sind, sei es Mal nur nen Buchstabe am Ende mehr, Mal in Umlaut Mal in oe.

Wie Florian ja schon anmerkte hat er eine sehr aussagekräftige Namensvergabe und den dynamischen Ordner, in dem er dann mit Sortieren alles gut entsprechend findet. Das in Tags aufgelöst und ein ordentliches UI zum Filtern usw. drüber wäre der deutlich modernere Weg.

Der Weg in der Inside das via Funktionen abzubilden funktioniert auch nur so lange wie Funktionen vordefiniert sind. Das wiederum ist auch wieder relativ eingeschränkt.

Für Große Projekte braucht es dann natürlich auch noch eine vernünftige Funktion die Tags schnell zu erzeugen, weil sonst wird das elendige Tipparbeit.

Ansonsten hab ich Tags auf Arbeit lieb gewonnen, macht schon Spass wenn man das konsequent nutzt.
In meiner KNX Umgebung macht mit der Timberwolf-Server die entsprechende Freude. Da wurde auch weniger auf Ordnerstrukturen oder ID-Strukturen gesetzt als eben konsequent auf Tags. Die kannst da für alles vergeben. So auch für alle GA's im Projekt als auch für die KO des Servers und der internen Logikobjekte oder Objekte anderer Bussysteme.

Wäre also für den KNX an der Quelle in der ETS Mal was neues. In den Geräten oder aus den Geräten muss das ja gar nicht kommen, der Herstelleraufwand ist da also eher gering.

Ich mag ja die Gebäudestruktur, das für GA wäre auch nicht schlecht, Tags aber flexibler weil nicht nur auf die Dimension Ort begrenzt.

GAs in den drei Stufen ordentlich zu sortieren kann man ja immernoch machen und auch gern in Projektrichtlinien vorgeben bei entsprechender Dimension. Gälte dann auch für die Tags denn mit Durcheinander hilft es auch niemandem der das mal zusammführen müsste.

[alorenzen]

aber z.B. beim Abspeichern auf Festplatten müssen wir ja auch keine Sektornummern mehr angeben.

Nein - aber wer vergibt die Dateinamen? Wer vergibt bei IP DNS Namen?
Die verwertbaren Meta-Information sind nicht zu gebrauchen, da die eigentlich Meta-Informationen die GAs sind. Was willst du mit nem Taster KO, oder nem Aktor KO? Selbst wenn du die halbwegs ordentlich benennst.
Die einzig sinnvolle Möglichkeit wäre, vorzugeben, dass die physikalischen Verbindungen bestimmte Eigenschaften haben müssen. Eine Reihenklemme müsste dann nicht nur ne Nr., sondern auch ihre Lokation beschreiben und weitere Eigenschaften wie z.B. Gewerk haben.
Dann könnte die ETS zusammen mit den Eigenschaften der benutzten KOs sinnvolle Namen erstellen.
Es wäre aber der gleiche Aufwand wie bei GAs. Vorteil wäre aber, dass niemand auf die Idee käme, da Dinge komplett zu verdrehen und sich diese Dinge ja überlicherweise nicht ändern. Und die ETS würde dann daraus ne Namensstruktur machen, die immer gleich, und für alle gleich lesbar wäre.
Das wäre aber der primäre Vorteil, der Aufwand wäre mindestens gleich. Es müssten ja feste Vorgaben gemacht werden, was alles an Eigenschaften vergeben werden muss, damit ein Objekt zulässig ist. Und damit wäre der Grundaufwand höher für jeden.

[Beleuchtfix]

Ich glaube, dass die Informationen eigentlich aus einem BIM kommen sollten, und dann sinnvoll von der ETS bis zur VIsu automatisch verarbeitet werden müssten.

Unsere Denkansätzen gehen viel zu sehr von der EDV Ebene aus, aber das Ganze sollte auch in der ELI Ebene zu verstehen sein. Elektriker sind keine Schriftsteller, es werden auch weiterhin die Dokumentationen viel offen lassen, egal auf welcher Ebene man etwas definieren kann.

Und solange nur von Spezialisten programmiert werden kann, wen es über klick klack hinausgehen soll, wird es zu teuer im Massenmarkt sein.

Gruß Florian