CCU: Namenskonvention für Geräte

Damit Du Deine Geräte intuitiver in der Anwendung wiederfindest, hast Du Dir sicher eine Namenskonvention ausgedacht oder eine der zahlreichen Vorschläge benutzt. Bei einem Test von „smartha home“ der EASY SmartHome GmbH kam mir meine Namenskonvention, die sich auch bereits in FHEM bewährt hat, bei der Einordnung und Suche der Geräte sehr entgegen. Diese möchte ich Dir im Nachfolgenden vorstellen.

Beim Anlernen neuer Geräte in der CCU*, hast Du direkt im Posteingang die Chance, einen Namen zu vergeben. Dieser wird leider nicht gleich für alle Kanäle benutzt. Mit einer aktuellen RaspberryMatic können die Kanäle auch en bloc im Nachhinein umbenannt werden, mit der Option, bereits von der CCU vergebene Namen zu überschreiben.

Namenskonvention

Als brauchbar hat sich bei mir folgende Namenskonvention erwiesen.

Allgemeine Regeln

• Alle Namen sind in lower Camelcase-Schreibweise geschrieben: das erste Wort klein, jedes weitere Wort folgt mit großem Anfangsbuchstaben direkt, ohne Leerzeichen, dahinter.
  Beispiel: „terrassenRollo„
• Die Namen enthalten keine Umlaute und Leerzeichen. Das ist besonders in Skripten und bei der Kommunikation zwischen verschiedenen Systemen wichtig, da Umlaute auf dem anderen System möglichweise anders kodiert sind (utf8/latin1/cp1256/…).
  Beispiel: „terrassenTuer„
• Trenner zwischen den Bestandteilen ist der Unterstrich „_„. Es kann jedoch genauso gut ein Punkt o.ä. sein. Ich finde, dass der Unterstrich eine gute optische Trennung bietet und somit am Besten lesbar ist.

Bestandteile

• Der erste Teil besteht aus dem Stockwerk, ich verwende eine Abkürzung hierfür.
  Beispiele: „eg“ (Erdgeschoss), „aussen„, „kg“ (Kellergeschoss)
• Im zweiten Teil wird der Raum oder Ort angegeben. Wo möglich und für mich intuitiv, verwende ich auch hier Abkürzungen. Sollten die Räume in dem Stockwerk nicht eindeutig sein, so hänge ich in camelcase noch einen näheren Bezeichner an. Dieser sollte dann möglichst sprechend sein.
  Beispiele: „eg_wozi„, „aussen_terrasse„, „dg_azi„, „og_kiziAndre„
• Als letzten Teil führe ich den Gerätetyp auf. Das ist in Skripten hilfreich, als dass ich alle Geräte eines Typs leicht mit einem Ausdruck wie „*_tuer“ erfassen kann.
  Beispiele: „og_kiziAndre_hzgThermostat„, „dg_azi_pir„, „dg_azi_taster„, „aussen_terrasse_tuer„, „eg_wozi_rm„
• Sollte noch eine nähere Bezeichnung oder Nummerierung notwendig sein, wie es bei Lampen oder Thermostaten der Fall sein kann, so füge ich vor dem letzten Teil noch einen Bestandteil hinzu.

NodeRED

In NodeRED nutze ich pro Raum einen Flow und somit einen Tab. Auch hier wende ich die Namenskonvention für die Geräte-IDs, bspw. bei den ZigBee-Geräten, an.

Topics

Die Topics, welche bei MQTT und auch in den NodeRED-Nachrichtenobjekten Verwendung finden, lasse ich auch diesem Schema folgen. Unterschied ist hier jedoch, dass der Trenner ein Schrägstrich „/“ ist und statt Camelcase eine hierarchische Abbildung erfolgt.
Beispiel: „eg/terrasse/tuer/links„

Für MQTT gibt es noch eine weitere Besonderheit: es wird ein Präfix angegeben, der den Nachrichtentyp kategorisiert.

• cmnd: für die Ausführung von Kommandos, bspw. Schalten eines Aktors
• stat: der Wert enthält einen Status, bspw. ob ein Fenster offen ist oder wie voll die Batterie noch ist
• tele: für Daten, die wiederkehrend übertragen werden, bspw. Temperaturen oder Verbräuche

Fazit

Ich hoffe, damit konnte ich Dir eine Anregung geben oder auch nur einen Einblick, warum ich meine Namen in den Artikel so seltsam vergebe 🙂

Gerade wenn man mehrere Systeme hat, die miteinander kommunizieren, ist eine Namenskonvention hilfreich. Oder auch, wenn man später auf ein anderes System umzieht oder nur testet, lernt man ein einheitliches Vorgehen bei den Namen schätzen.