Devices Adapter Alias Namen

[haus-automatisierung]

@codierknecht Generell geht es bei dem Geräte-Adpater darum, dass man bestimmte Geräte-Typen auf den gleichen Nenner bringt. So können alle möglichen Adapter auf dieser Basis aufbauen. Das kann auch eine Visualisierung sein. Siehe z.B. lovelace oder material.

[Codierknecht]

@haus-automatisierung
Das kriegt man aber auch "von Hand" hin.
Du weißt doch: Was man nicht selbst macht, taugt auch nix

[haus-automatisierung]

@codierknecht sagte in Devices Adapter Alias Namen:

Du weißt doch: Was man nicht selbst macht, taugt auch nix

Mit dem Ansatz sind ja 99% der Adapter obsolet und man kann alles im JavaScript-Adpater selbst programmieren

[Armilar]

@warhammer73

Leider bekomme ich aber die Vorgaben "Actual" und "Second" als Namen nicht angepasst.

Exakt das ist der Sinn an virtuellen Devices, dass du es nicht anpassen kannst. Ansonsten kannst du dir ja eine 1:1 Beziehung zwischen einem Datenpunkt und einem Alias bauen. Dann verstehe ich aber nicht, warum du einen Alias brauchst. Dann nimm lieber den Datenpunkt. Alles andere hätte außer Zeitverschwendung dann keinen Sinn.

Wenn du aber eine Lampe hast, die einmal über "on" oder "switch" oder "power" geschaltet wird, dann ist es immer SET oder ACTUAL im Alias und der Code muss nicht mehr angepasst werden, sollte sich ein Device verabschieden oder durch ein anderes mit einem Schaltzustand "XYZ" ersetzt werden...

[warhammer73]

@armilar
Der Code muss aber auch nicht angepasst werden wenn es statt Actual und Second Temperatur und Luftfeuchtigkeit heisst.
Dann ist
a) Der Name wenigstens sprechend
b) Auch dann kann ich physikalisch als Gerät mit dem Alias immer noch jedes Device hängen das Werte für Temperatur und Luftfeuchtigkeit bereitstellt und kann diese auch austauschen wie ich will und muss nichts weiter ausser die Verknüpfung bei Alias anpassen. Die muss ich bei einem Ersatzgerät aber auch für Actual und Second anpassen.

[Armilar]

@warhammer73 sagte in Devices Adapter Alias Namen:

a) Der Name wenigstens sprechend

Aus einem unleserlichen Datenpunkt (in dem Punkt hast du natürlich recht), wie z.B.

deconz.0.Lights.5.on

würde dann z.B. ein

alias.0.schreibtischlampe_buero.ACTUAL 

werden

Jetzt ist er sprechend und kann flexibel ersetzt werden. D.h. deinem Code kann es egal sein, welcher Adapter hinter dem Device steckt.

Aber es würde ja unschön aussehen, wenn der ALIAS als

alias.0.schreibtischlampe_buero.on 

angelegt werden würde und irgendwann ein

AdapterXYZ.0.Lights.XY.switch

den Job übernimmt.

Ganz unsauber wäre es dann, wenn das Device mehrere Eigenschaften besitzt und zunächst nur als

alias.0.schreibtischlampe_buero

angelegt wird.

Ich denke bei der Anzahl an individuellen Adaptern die es gibt (und da ist augenscheinlich nichts standardisiert) und die Adapter die noch kommen werden, würde ich beim TypeScript des NSPanel durchdrehen, wenn ich jeden Datenpunkt von seiner Endung und Abhängigkeit eines Adapters berücksichtigen müsste oder eigene individuelle Nomenklaturen zulassen würde. Ganz zu schweigen von dem Code, da sich ansonsten jeder sein eigenes individuelles Schema baut (das wäre unpflegbar und unsupportbar).

Es werden direkt Aliase (Device oder Channel) mit Rollen abgefragt und verarbeitet.

Der Geräte-Manager bekommt das in der Erstellung super hin. Und was ist so schlimm an der Endung?

Das schlimmste ist dann, wenn jemand mit selbstgebastelten Aliasen erstmals versucht, den Content für die Devices zu erzeugen. Das geht dann zu 100% schief.

Ich sag es mal so. Es gibt da quasi so eine Art "Standard" und der Geräte-Manager hält sich zumindest dran.

[warhammer73]

@armilar

Bleiben wir bei Deinem Beispiel:
alias.0.schreibtischlampe_buero.ACTUAL
... was soll das Aussagen? Zumindest ich weiss garantiert in einem Jahr nicht mehr, was Actual ist.
Der Zustand an/aus?
Der Dimmgrad in Prozent?
Die Leistungsaufnahme?
Der RGB Farbwert?
...

hingegen:
alias.0.schreibtischlampe_buero.on
alias.0.schreibtischlampe_buero.brightness
alias.0.schreibtischlampe_buero.powerconsumption
alias.0.schreibtischlampe_buero.rgb
erklären sich von selbst.

Und wenn da jetzt ein Adapter dahinter sitzt mit:
XY.0.Lights.Power
XY.0.Lights.threshold
XY.0.Lights.consumption
XY.0.Lights.color
Muss mich das nicht interessieren solange ich die Aliase nutze.
Da kann ich den Adapter auch austauschen gegen einen mit:
YY.0.Lights.switch
YY.0.Lights.color
YY.0.Lights.power
YY.0.Lights.mood

Jeder wie er mag. Ich persönlich würde am Rad drehen wenn jeder Alias ein Actual hat und das mal die Temperatur, mal die Ventilstellung, mal an/aus, mal Stromverbrauch... ist.

[Codierknecht]

@warhammer73
Durchaus verständlich, aber konträr zum Vorgehen des Gerätemanagers.
Darum: Eigene Aliase erstellen. Die kann man benennen wie man will und später jederzeit das dahinter liegende Gerät tauschen.
Ist natürlich je nach Umfang 'ne Menge Arbeit.

[crunchip]

@warhammer73 sagte in Devices Adapter Alias Namen:

was soll das Aussagen

@warhammer73 sagte in Devices Adapter Alias Namen:

Zustand an/aus

in dem Fall ja, aber nicht zum schalten, sondern der state der den aktuellen Zustand zeigt
der weitere "selbe" DP der angelegt wird, wäre dann SET, dieser DP ist der zum schalten.

wie HIER schon geschrieben, nimm den alias manager, wenn dich dieses actual stört

EDIT
hier mal ein Beispiel, mit der Datenstruktur

[warhammer73]

@codierknecht
Naja, so konträr zum Gerätemanager ist es ja gar nicht.
Da kann ich auch für jeden Datenpunkt einen eigenen Alias anlegen und benennen wie ich will.
Ich muss halt nur damit leben das ich Actual mit irgendwas füllen muss.
Mit dem Kompromiss kann ich aber nun leben - Und das Gerät tauschen lässt sich damit natürlich auch.

[warhammer73]

@crunchip
Naja, aber auch vom aktuellen Zustand kann es mehrere Werte geben (z.B. Thermometer mit Temperatur, Luftfeuchte, Batteriestand, Empfangsqualität oder Thermostat: Öffnung des Ventils, Temperatur am Thermostat).
Insofern krieg ich halt keine konsistente Nutzung eines so generischen Wertes hin - Macht ja aber nichts.
Wie gerade geschrieben gibt es halt den Alias auf Actual, aber ich nutze ihn nicht weiter.

Ja, den alias manager hatte ich mir auch angesehen - Aber dann doch lieber ganz händisch. Ist irgendwie für mich persönlich nicht so hilfreich.

[crunchip]

@warhammer73 seh dir mein edit oben an

[Andersmacher]

Ich hoffe, ich darf mich hier zu dem Thema Alias-Namen mit einhaken, weil mich das Thema "Benennung" auch beschäftigt:

Unabhängig davon, ob man nun für die Alias-Erstellung manuell vorgeht oder den Device- oder Alias-Manager benutzt, stellt sich für mich die Frage, welche "Anteile" an der (Original)datenpunktbennung "ziehe" ich (schlauerweise) in den Namen des Alias mit hinein und welche lasse ich nur in der Objekt-Hierarchie stehen.
Am Beispiel eines Homematic-Rauchmelders:

Originalname: Rauchmelder_Flur:0.LOWBAT
Aliasstruktur: alias.0.HM_Geräte.Rauchmelder_Flur.LOWBAT

Was ist aus Eurer Sicht schlauer bzw. wo liegen Vor- oder Nachteile (Ich habe noch keine Erfahrungen mit Aliassen, denke aber, daß das irgendwann relevant sein kann)?

Aliasname: LOWBAT

oder besser (wenn ja, warum, denn daß das LOWBAT zum Rauchmelder_Flur gehört erkennt man ja aus dem Objektbaum)

Aliasname: Rauchmelder_Flur.LOWBAT
oder sollte man sogar noch die :0 mit im Namen behalten?

Für Hinweise bin ich dankbar.

[Codierknecht]

@andersmacher
Wenn man sich einfach mal vor Augen führt, wozu die Aliase gedacht sind, wird eigentlich schnell klar wie man die benennen sollte.
Ein Alias dient dazu, den Original-DP zu anonymisieren.
Soll heißen: Egal welcher DP letztlich dahinter steckt - angesprochen wird nur noch der Alias.
Ziel des Ganzen: In Scripten und der VIS spricht man nur noch den Alias an. Ändert sich mal der Original-DP, weil man z.B. den Hersteller wechselt, muss an den Scripten und der VIS nix geändert werden.
Man braucht (und sollte) also im Namen des Alias weder den Hersteller noch die Instanz mit aufzunehmen.

@andersmacher sagte in Devices Adapter Alias Namen:

oder sollte man sogar noch die :0 mit im Namen behalten?

Sollte damit auch beantwortet sein.

Ich würde die Namen auch durchweg klein schreiben. Aber das ist eher Geschmackssache.

[warhammer73]

@andersmacher said in Devices Adapter Alias Namen:

Am Beispiel eines Homematic-Rauchmelders:
Originalname: Rauchmelder_Flur:0.LOWBAT
Aliasstruktur: alias.0.HM_Geräte.Rauchmelder_Flur.LOWBAT

Was ist aus Eurer Sicht schlauer bzw. wo liegen Vor- oder Nachteile (Ich habe noch keine Erfahrungen mit Aliassen, denke aber, daß das irgendwann relevant sein kann)?

Aliasname: LOWBAT

oder besser (wenn ja, warum, denn daß das LOWBAT zum Rauchmelder_Flur gehört erkennt man ja aus dem Objektbaum)

Aliasname: Rauchmelder_Flur.LOWBAT
oder sollte man sogar noch die :0 mit im Namen behalten?

Für Hinweise bin ich dankbar.

Im Endeffekt kann Dir niemand sagen was für Dich der richtige Weg ist.
Beachte aber:
Der Alias sollte eindeutig und sprechend sein (Ist LOWBAT sicher nicht, sowas wie Rauchmelder_Flur.LOWBAT schon eher
Mache Dir am Besten vorher Gedanken wie Dein Maximalausbau aussehen könnte. Wenn die Chance besteht mehr wie einen Rauchmelder im Flur zu haben (oder es mehrere Flure gibt) dann berücksichtige das gleich in der Namensgebung (Also z.B. Rauchmelder_Flur_Erdgeschoss.LOWBAT)
Überlege Dir ob und welche Gruppierungen Du später oder gleich am Ehesten vornehmen könntest. Also eher alle Geräte im Flur zusammengefasst, oder eher alle Rauchmelder? Entsprechend den Aliasbaum aufbauen (Also Flur.Rauchmelder.LOWBAT oder Rauchmelder.Flur.LOWBAT)

Warum nicht nur LOWBAT? Weil Du in Scripten oder Konfigurationen gleich sehen willst was denn LOWBAT aussagt, ohne das Du dann erst in die Konfiguration gehst und schaust wo LOWBAT hinverweist.

[Andersmacher]

@warhammer73 und @Codierknecht Danke für Eure Rückmeldungen und Hinweise!

Den Sinn der Aliasse (für VIS und Skripte im Falle eines Hardwarewechsels nichts ändern zu müssen) hatte ich bereits so interpretiert, wie Ihr es auch erläutert habt. Hatte da allerdings wohl nicht weit genug gedacht, daß man da später vielleicht nicht nur einen defekten HM-Rauchmelder gegen einen neuen tauscht, sondern natürlich auch einen komplett anderen nehmen könnte. Insofern wäre dann ein hersteller- oder gerätespezifischer Namensbestandteil schlecht/verwirrend. Ok, verstanden. Und das mit den etwaigen Gruppenbildungen ist mir auch klar. Mein Beispiel war da etwas vereinfachend.

Meine Haupt"sorge" war, daß ich mir durch ungeschickte Namenshierarchie vielleicht Skriptmöglichenkeiten "verbaue" oder unnötig kompliziert mache (z. B. für die Funktion "IDs vom Selektor"). Da Ihr soetwas nicht angesprochen habt, nehme ich mal an, daß ich mir diesbezüglich aber eher keine Sorgen machen muß.

[paul53]

@andersmacher sagte: für die Funktion "IDs vom Selektor"

Wenn man keine Enums dafür verwenden will - die ja auch erst zugeordnet werden müssen, ist eine einheitliche ID-Struktur erforderlich. Wie diese Einheitlichkeit aussieht, ist letztlich egal.

[Andersmacher]

@paul53 Danke!