Best Practices: Objektbaum & Orga

Hallo,

es gab ja schon Threads zum Thema Dokumentation. Ich bin ein großer Freund von „Standards“ (wie auch immer definiert und deshalb in Hochkomma gesetzt) und „Best Practices“, weil die den Doku-Aufwand deutlich reduzieren können.

Ich würde daher gerne mal einen Thread starten, um über die Anordnung der Objekte im Objektbaum sowie deren Benamung und Nutzung (Typen-Bezug etc) und weiters Dinge wie Folder-Strukturen etc zu diskutieren.

Ja, ich weiss, das wird bei 1000 Usern vielleicht zu 1000 Varianten führen - vielleicht auch nicht? Oder vielleicht gibt es Parallelen, die man dann leicht zu einer Empfehlung machen kann?

Ich würde mich freuen, wenn auch der Hersteller „Steiner“, der das Produkt ja offenbar professionell nutzt, hier ein paar Hinweise zur Erfahrung gibt - ins besondere natürlich zum Thema „Nachvollziehbarkeit“ und „Wiedereinstieg nach ein paar Monaten“.

Dieses Post als Überschrift, ich werde meine Gedanken in einer eigenen Antwort abgeben, will aber jetzt nicht schon (vielleicht falsch verstandene) Zeichen setzen.

Mein Objektbaum ist klar geographisch Orientiert. Was im Erdgeschoss/Küche an Elemten drin ist, ist auch dort zu finden. Dazu zählen auch alle Scripte die zum Beispiel die Kaffeemaschine steuern.

Sematisch davon abweichende Kategorien, wie zum Beispiel Hilfscripte, Webfront-Link-Sammlungen und ähnliches beginnen mit einem großen ZF_ (ZentralFunktion)

Bei überlagerung der Interessen werden Links erstellt.

werde heute abend versuchen auch noch Screenshots zu erstellen

Hallo jwka,

gutes Thema…

mein Baum ist eher funktional aufgebaut, ich habe im Root eigentlich nur 4 Kategorien:

[ul]
[li]Hardware - hier befinden sich alle „physikalischen“ Schnittstellen wie IRTrans, Homatic Devices, IPS868, diverse Register Variablen …[/li][li]Program - hier ist die Funktionalität beheimatet, also mein IPSLogger, meine Licht Steuerung , Beschattungssteuerung, Bewässerungssteuerung …[/li]Über diverse Konfigurationsfiles verlinke ich dann auf die Hardware, meistens durch die Angabe des absoluten Pfades (also z.B. „Hardware.Homematic.Raffstore_Wohnzimmer“
[li]Webfront - hier liegt die WebFront Struktur (könnte mit der Version 2.4 - Stichwort multiple WebFront Konfiguratoren - noch mehr werden). In diesen Ordner exitieren nur mehr Links auf den Programm Ordner[/li][li]iFront - selbiges wie des WebFront Ordner, nur mit eigener Struktur für mein iFront Interface.[/li][/ul]

lg
Andreas

jwka das finde ich wirklich mal einen guten Thread!

Also bei mir sieht es derzeit noch so aus wie bei dapor aber sobald ich meinen neuen IPS-Rechner in Betrieb nehme möchte ich es so umbauen wie bei Brownson.
Muss nur mal sehen ob sich das dann mit meinen Scripting-Ideen noch so verträgt :wink:

Nicolai

Mein Baum trennt sich ähnlich auf wie brownsons.

  • Stockwerke ( Erdgeschoss, OG, Garten )
  • Webfront
  • Skripte

Das war es, hat sich in der Praxis eigentlich als sinnvoll erwiesen.

Gruss,
Christian

Hallo zusammen,

ich habe eine an Etagen und Räumen orientierte Struktur (wie es ja in der IPS Doku empfohlen wurde) und dazu eine funktionale Ebene für Musiksteuerung und Alarmmelder / Sensoren.

Bisher kann ich mir damit für versch. Webfronts und das Ifront auch fast alles im Webfront Konfigurator zusammenbauen (Zusatzinfos Musik/ Melder sind dann in einer weiteren pane) ohne Links benutzen zu müssen.

  • Allgemein

  • Boden

  • Wohnung
    –Wohnzimmer
    –Küche
    –weitere Räume

  • Melder
    – Allgemein
    – Boden
    — Wohnung
    ---- Wohnzimmer
    ---- Küche
    ---- weitere Räume

  • Musik (wie Melder aufgebaut)

  • Zentrale Steuerung (ausgeblendet)
    – (div. zentrale Skripte und Includes in Kategorien einsortiert)

  • Test (ausgeblendet)
    –(Skripte etc. für Tests)

Grüße, Benjamin

Hallo,

Interessant. Habe beruflich viel mit Standards zu tun und bin daher auch ein Fan davon.

Ich habe das bei mir mehrmals auf der Suche nach der idealen Struktur angepasst.

Eine Basis-Struktur nach Räumen ist schwer zu meiden. Ist auch meistens räumlich im Kopf organisiert.
Dann habe ich auch eine zusätzliche „horizontale“ Struktur nach Typ/Funktion: Heizung, Schalter, Fenster/Türen… Das sind dann meistens nur Links zu Objekten in den Räumen für die Webfront und Skripte, denn die Steuerung geht generell nacht Typ über mehrere Räume.

Natürlich sollten dann Objekte des selben Typs anhand des Names schnell identifizierbar sein mit „naming conventions“. Ist dann auch für Skripte einfacher.

Gruß,
Zapp

Klasse Idee, das mal zu analysieren.

Ich verwende neben den Kategorien im Namen selbst eine DOT-Notation. Das ist historisch gewachsen (aus V1). Damals habe ich mich wegen Unzweckmäßigkeit gegen eine raumbezogene, sondern für eine funktionale Struktur entschieden, um objektübergreifend arbeiten zu können. Also ein Handling-Script greift jeweils für alle Heizungen, Jalousien, Fenstergriffe, Schalter usw., per Namen (primärer Namensteil, Präfix ) gesteuert. Beispiele: Heizungen beginnen mit „hz.“, Jalousien/Fenster mit „f.“, gefolgt vom Raum bzw. konkreten Fenster („f.WzTs.“ = Fenster/Wohnzimmer/Terasse/Süd). Analog die Schalter (SST.nn = Schaltsteckdose Nr. nn) usw.

Darunter liegen dann die Werte bzw. Steuerelemente. So hat zB. jeder Schalter bei mir neben den Systemvariablen auch Steuervariablen oder sekundäre Variablen wie
…sollStatus,
…Caption (String: „an“ / „aus“),
…updated (Zeit-String),
…since (Zeit-String),

Daneben gibt es weitere sekundäre Systemvariablen, wie zB. bei allen Fenstern/Jalousien einen numerischer Auslöser-Status (Jalousie zuletzt gefahren per: manuell, Sturmwarnung, Morgen-/Abend-Event, passive Klimatisierung/Abschattung, autom. weil Fenster/Hoppe-Griff geöffnet wurde usw.), um davon abhängig reagieren zu können (wieder zufahren, wenn Fenster wieder geschlossen wird, aber nicht, wenn inzw. das Morgen-Event die Jalousien hochgefahren hat, kein Öffnen per passivKlimatisierung, solange Sturmwarnung etc.),

Das alles ist per o.g. Namens-Notation (Präfix) eindeutig dem übergeordneten Objekt (letztlich: Instanz) zugeordnet, damit ein einziges Script das objektunabhängig behandeln kann bzw. neue Instanz-Objekte nach Festlegung eines Namens sofort integriert sind.

Aber auch schon ab V1 gab es schon eine andere, eher horizontale Ebene, die davon unabhängig arbeitete. So legt eine am einzigen Script als Event registrierte Variable bei erstmaligem Event sofort eine Sekundär-Systemvariable an ("…updated", „…since“, „…sollStatus“ usw.) mit dem (Instanz-)Namens-Präfix aus der auslösenden Variable.

Mit V2.x ist vieles einfacher geworden. Namen können mehrfach existieren und statt der Präfixe sind die Sekundärvariablen direkt den Instanzen untergeordnet.

Da ich aber einerseits eher anschaulich denke, und andererseits es gewohnt bin, Projekte transferabel und nachnutzbar zu gestalten, verwende ich niemals IDs direkt, sondern immer nur als Variableninhalt. Deshalb haben alle Instanzen bei mir nach wie vor eindeutige Namen, die den initialen „funktionalen Identifikator“ bei der Bearbeitung darstellen. Ebenso darf es je Instanz-Kategorie Variablennamen nur einmal geben.

Kategorien können das nicht ersetzen, weil es keine ideale 1:1-Abbildung gibt (zB. mehrere Fenster oder Schalter je Raum). Kategorien verwende ich aber nun, um ein wenig Ordnung zu schaffen. Geografisch (Etage/Raum; Aussen/Garten, ~/Pool, ~/Tore usw.), als auch funktional (Tools/ISDN, ~/TV, ~/IPwatch, ~/Android, ~/Datenbank, ~/CAMcontrol; Wetter/Station usw.)

Gruß Gerd

Nun will ich als Starter des Threads auch meine Struktur darlegen - hatte den Thread schon fast vergessen …

Grundsätzlich benutze ich sehr stark Kategorien und Unterkategorien, um den Baum zu strukturieren. Ferner arbeite ich meist mit Namenskonventionen (auch innerhalb von Scripten).

Strukturiert habe ich den Baum zunächst organisatorisch:

  • Globales (Bibliotheken, Includes, Semaphoren & Variablen etc.)
  • Setup & Admin (Configurations-Infos und Scripte, die dem Setup, dem Nachvollzeiehen, Dokumentieren, Finden und dem schnellen Ändern/Ein-Ausschalten, Debugging Level setzen etc. dienen)
  • Hardware (dort sind die Instanzen sowie den diesen direkt zugeordneten Scripte etc. drin). Dieser Teil ist unterteilt in Aktoren und Sensoren, danach per Notation z.B. der Instanzen die räumliche Zuordnung wobei es je Stockwerk zunächst noch eine Kategorie gibt. Übergreifende Dinge wie Netzwerk etc. haben dort eine eigene Kategorie
  • Software (Scripte)
  • Entwiclungsbereich (da sind alle Testscripte und sonstiger unfertiger Unfug drin)
  • UI (für Webfront und andere), worin i.d.R. nur Kategorien und Links anzutreffen sind.

Bei den Namen von Objekten arbeite ich mit Kurznamen sowie Funktionalen Erweiterungen und einem oder mehreren Alias Namen, über die ich ein Objekt in meinen PHP’s anspreche.

Dazu gibt’s ein „Sammelscript“, welches infach den ganzen Baum abarbeitet und ein Array erstellt, das die Aliasse und die ID’s in Korrellation setzt. Dieses Array wird immer includiert und der Zugriff auf ein Objekt erfolgt dann im Prinzip (macht bei mir ne Funktion mit Typenprüfung, um sicher zu sein, dass das gesuchte Objekt auch das richtige ist) per


$id = $alias['<aliasname des objekts>'];

Mit den Aliassen vermeide ich, dass ich Scripte anpasen muss, wennsich Objekte ändern oder z.B. mal eins gelöscht wurde und ich es wieder einsetzen will. Selbes gilt bei der „Portierung“ zu anderen IPS-Systemen.

Auch das Suchen eines Objekts kann ich so mittels eines Scripts (oder durch reingucken in das Array) sehr einfach machen, denn das Alias Array stellt natürlich auch eine gut lesbare Cross-Referenz der wensentlichen Objekte zu deren ID’s dar.

jwka