Sinnvoller Adressaufbau

[BadSmiley]

Herrje, wer sich da noch zurecht findet... aber ja, kann man so schon machen.

[Crazyus]

Hier mal ein Beispiel wie ich die Struktur aufbaue.
Funktioniert für mich so seit Jahren und bisher hat es jeder auf Anhieb verstanden und alles schnell gefunden.
Vorteil ist auch hier das man bei den Aktorkanälen sofort sieht wenn ein Fehler drin ist.
Die Reihenfolge ist übrigens so gewählt das sie perfekt zu MDT Aktoren passen, da ich diese am meisten verwende, ist aber bei den meisten anderen Herstellern die gleiche oder ähnlich.
Geschosse oder gar Zimmer in Haupt oder Mittelgruppe macht es meiner Meinung nach sehr unübersichtlich.
Ausnahme bei Großen Projekten wo man schön nach Wohnung, Aufgang, Abteilung... aufteilen kann.
Wenn man größere Projekte hat, sollte man auch versuchen es so aufzubauen das viel Copy&Paste möglich ist.
Daher habe ich viele leere Gruppenadressen als Platzhalter. Bspw. Dimmen auch bei Lampen die nur geschaltet werden.
Sollte der Bauherr auf die Idee kommen doch dimmen zu wollen spart das viel Arbeit.


Gruppenadressen Struktur.jpg

Aktor Zuordnung.jpg

[Hightech]

Der Aufbau ist sicherlich Geschmackssache und es gibt kein falsch oder richtig - jeder muss es so aufbauen, wie er am besten damit zurecht kommt.

Hier mal ein Beispiel wie ich die Struktur aufbaue.

Hauptgruppen finde ich so auch gut, die Mittelgruppen finde ich nun etwas unglücklich, wäre nicht mein Ding. Du hast somit die verschiedenen Adressen zu einem Objekt alle in verschiedenen Mittelgruppen. Gerade beim Aufbau einer Visu, wo man oft alle Objekte zu einem Gerät direkt nacheinander benötigt, finde ich das schöner, wenn sie auch alle zusammenstehen und ich nicht durch verschiedene Ordner surfen muss. Ich vergleiche das immer mit dem Explorer in Windows: Du legst ja auch alles, was zu einem Projekt gehört, in einen Ordner. Was Du hier machst: Die Protokolle für alle Projekte in einen Ordner, die Statusberichte für alle Projekte in einen anderen Ordner, die Präsentationen in einen 3. Ordner.... das ist für mich unübersichtlich und entspricht nicht üblicher Ordnungsstruktur.

Geschosse oder gar Zimmer in Haupt oder Mittelgruppe macht es meiner Meinung nach sehr unübersichtlich.

Sehe ich genau anders rum: Genau das macht es übersichtlich - aber wie geschrieben: Geschmackssache.

Daher habe ich viele leere Gruppenadressen als Platzhalter. Bspw. Dimmen auch bei Lampen die nur geschaltet werden.
Sollte der Bauherr auf die Idee kommen doch dimmen zu wollen spart das viel Arbeit.

Warum die ganzen leeren Platzhalter mitschleppen? Ja, den Adressraum lasse ich auch immer frei, also auch bei schaltbaren Lampen die Adressen, die ich vielleicht mal brauche, wenn ich die Lampe auf dimmbar umbaue. Aber so viel leere Platzhalter? Wofür soviel Müll rumschleppen? Das erhöht die Übersichtlichkeit auch nicht gerade.

Wenn Du die Adressen einfach freilässt (die müssen ja nicht fortlaufend sein), spart das genausoviel Arbeit.

Aufwändiger ist mit den Platzhaltern dann auch, dass Du nach dem Import in die Logikmaschine (HS, Edomi, whatever) beim Setzen der Häkchen "beim Starten abfragen" für jedes Statusobjekt überlegen musst, ob da jetzt wirklich was hinterlegt ist oder ob das leer ist. Denn leere GA's abzufragen kostet bspw. beim HS beim Booten 4-5 Sekunden pro Adresse (wird als Scanfehler ausgewiesen).

Hier mal ein Stück meiner Struktur - nicht wundern, in Englisch bzw. Denglisch, weil ich mir als erstes für die Visu die Gesamtstruktur von Gewerken und Räumen überlegt hab, die Software nur in Englisch war.. da hab ich es dann wg. der immer wieder gleichen Namen in Englisch/Denglisch durchgezogen. GA.png

[DirtyHarry]

Hier mal ein Beispiel wie ich die Struktur aufbaue.

Genau das ist etwas, mit dem ich mich gar nicht anfreunden kann.
Würde mich interessieren, wie du Sachen abbildest, die 10 oder mehr GAs benötigen...

Hier mal ein Stück meiner Struktur

Erinnert mich ziemlich an meinen Grundaufbau (bis auf die Punkte als Trennzeichen, fehlende Groß/Kleinschreibung, Denglisch )...

Ansonsten, so lange wenigstens überhaupt eine Struktur vorhanden ist, soll es mir ja recht sein. Aber was man manchmal an Projekten bekommt, die andere verbrochen haben...

Wobei, eines der schlimmsten Projekte ist noch das unserer Firma: Zu viele Köche in den letzten 20 Jahren dran gewesen. Am Anfang vermutlich keine Struktur, dann wurde immer wieder erweitert und jeder hat ein bisschen seiner Struktur rein gebracht. Und ich schiebe nun alles, was ich angreife in eine neue Struktur. Für alles auf einmal hab ich weder die Zeit, noch den Nerv (vor allem da die Datenbank nicht komplett der Realität entspricht).

[bazzman]

Hier mal ein Stück meiner Struktur - nicht wundern, in Englisch bzw. Denglisch, weil ich mir als erstes für die Visu die Gesamtstruktur von Gewerken und Räumen überlegt hab, die Software nur in Englisch war.. da hab ich es dann wg. der immer wieder gleichen Namen in Englisch/Denglisch durchgezogen.

Das heisst du hast Gewerk / Stockwerk / Funktion als Struktur gewählt, den Raum codierst du nur im Namen nach dem Stockwerk mit rein?

Könntest du vielleicht noch ein paar Beispiele von Adressen aus anderen Gruppen zur Übersicht als Screenshots einstellen?
Bin auch mitten in den Überlegungen für mein Setup und da helfen solche Bilder von erfahrenen KNX-lern ungemein weiter

Grüsse
Paolo

[Hightech]

Punkte als Trennzeichen, fehlende Groß/Kleinschreibung, Denglisch

Punkt: angelehnt an Klassen in Java - (mache IT-Projektmanagement und unsere Software ist in Java, da hab ich das halt "abgeguckt". Irgendein Trennzeichen musste ja her und Leerzeichen in der IT geht für mich gar nicht (hier wohl eher unkritisch, aber sehr häufig Stolperfallen!)

fehlende Groß-Kleinschreibung: kenne ich halt auch nur so, dass groß/klein irrelevant ist - wenn ich Email-Adressen als "Max.Mustermann@web.de" angegeben sehe oder jemand fragt "groß oder klein geschrieben" Hast mal ausgerechnet, wie viele Tastenanschläge das über so ein gesamtes Projekt spart? Da hält die Tastatur glatt nen Monat länger

Denglisch: hatte ich ja geschrieben, warum das so ist.... ich musste das übrigens in Englisch machen, da Support für commandfusion nur in Englisch verfügbar ist. Sonst hätte ich das ja immer alles erklären müssen.
Ok, ich sollte es mal von Denglisch zu Englisch aufräumen.. das mit den Etagen bspw. ist mir selbst erst recht spät aufgefallen und dass shades US-Englisch ist und es in GB-Englisch blinds heißt auch... ist also sogar amerikanisches Denglisch

So, der Ausflug musste sein, jetzt aber BTT.

[Beleuchtfix]

da helfen solche Bilder von erfahrenen KNX-lern ungemein weiter

Wenn du die Sufu anschmeißt, dann brauchst du nicht mal auf die Antworten zu warten
An irgend einem Punkt wirst du aber immer von deiner Ideallinie abweichen müssen.
Gruß Florian

[bazzman]

Hi Florian

Wenn du die Sufu anschmeißt, dann brauchst du nicht mal auf die Antworten zu warten
An irgend einem Punkt wirst du aber immer von deiner Ideallinie abweichen müssen.

Habe mir schon einige Threads zu dem Thema durchgelesen, aber so eine richtige best-practice hat sich für mich noch nicht ganz herauskristallisiert, daher kam dieser Thread gerade recht um ein paar konkrete Beispiele zu sehen. Werde mir natürlich auch selber noch Gedanken machen, aber habe etwas Respekt davor, eine ungünstige Struktur zu wählen und nachher nur mit viel Aufwand später nochmals umstellen zu müssen weil ich irgendwelche Anfängerfehler gemacht habe.

Grüsse
Paolo

[Hightech]

Das heisst du hast Gewerk / Stockwerk / Funktion als Struktur gewählt, den Raum codierst du nur im Namen nach dem Stockwerk mit rein?

Könntest du vielleicht noch ein paar Beispiele von Adressen aus anderen Gruppen zur Übersicht als Screenshots einstellen?

Ja, fast: wenn die Struktur mehr als 3 Ebenen hergeben würde, hätte ich das auch runtergebrochen. Funktion ist daher also immer "Raum.Objekt.Funktion.[Detailfunktion, wo nötig]"

Das ko am Anfang hab ich übrigens, damit ich am Objektnamen im Homeserver sofort sehe, ob es ein HS-internes oder ein KNX-Objekt ist - dort hab ich nämlich ansonsten namentlich exakt die gleiche Nomenklatur.

Klar. gaw.png gas.png gah.png

[Hightech]

An irgend einem Punkt wirst du aber immer von deiner Ideallinie abweichen müssen.

Yepp, irgendwann passt das noch so gut überlegte Konzept nicht mehr - insbesondere bei den ganzen globalen Objekten, die zu keinem Gewerk, Etage, Raum etc. passen, wird das dann schwierig und endet, wenn man es durchziehen wollte in so sinnlosen Objektnamen wie "global.global.global.aussentemperatur" ;-)

[Crazyus]

Genau das ist etwas, mit dem ich mich gar nicht anfreunden kann.
Würde mich interessieren, wie du Sachen abbildest, die 10 oder mehr GAs benötigen...

Das die Mittelgruppen auf 8 limitiert sind hat mich in der Tat schon gelegentlich (aber selten) gestört und ich hätte mich über 16 sehr gefreut.
Bisher konnte ich das über eine zusätzliche Hauptgruppe aber immer lösen.
Daher bekommen RGB, Klima, Beschattung usw. eine eigene Gruppe.

Je nach Schwerpunkt hat sich da natürlich jeder etwas anderes angewöhnt.



Der KNX Standard ist einfach zu alt und teilweise nicht schnell genug mit den ganzen Möglichkeiten der Geräte mit gewachsen.

Das merkt man auch oft daran das die Hersteller Dinge unterschiedlich lösen und so teilweise Inkompatibilitäten entstehen.
Besonders deutlich bei HKL.
Mal Sollwerverschiebung, mal absoluter Sollwert, Status mit unterschiedlichen Modi oder bei RGB bzw TW wo es auch einiges an durcheinander gibt.
Hier würde ich mir wünschen das mal ein Großes Update kommt. Vielleicht ein Abwärtskompatibeles KNX 2 ähnlich wie auch bei Dali.

Eventuell das man am Anfang auswählt ob Einfam.Haus, Hotel, Firma... und sich die Struktur von allein erstellt.

[Beleuchtfix]

Es gibt doch den Wizard in der ETS, auch für unterschiedliche Gebäudearten.
Gruß Florian

[n3de]

Danke für die ganzen hilfreichen Antworten. Für einen Anfänger ist es sehr schwer ein passendes Konzept zu finden, weil wie hier schon gesagt, gibt es kein richtig und kein falsch. Es gibt aber Ansätze die sich bewährt haben und wo man aus Erfahrung weiß, was in welchen Fällen besser klappt und was nicht.

Ich für mich denke, dass ich mit Gewerk / Etage / Funktion am besten fahren werde.

@Hightech
Wofür steht das ko genau? In der ETS verwendest du ko und im HS ein anderes Kürzel, richtig? Das sind auch solche Details, die einem das Leben später leichter machen können.

@Beleuchtfix
Wo gibt es den Wizard? Oder meinst du den Wizard von hier und die Importfunktion in der ETS?

[Hightech]

ko = Kommunikationsobjekt
Für die HS-internen Objekte wird oft der Begriff iKO = internes Kommunikationsobjekt verwendet, daher hatte ich dann ko für die Objekte vom Bus genommen.... die im HS haben bei mir kein Präfix - reicht ja, wenn eins von beiden eins hat zur Unterscheidung.

[Beleuchtfix]

Hier: Zwischenablage01.jpg

KOs sind die Software-"Klemmen" der Geräte, die GAs sind dann die Drähte.
Gruß
Florian