Kein Objekt darf heißen wie ein anderes

[BadenPower]

[EDIT]
Hier habe ich eine Trennung des >> THEADS << vorgenommen.
[/EDIT]

Aber Doppelnamen sind definitiv irgendwann eine Fehler, den Du bereust.

Nicht zwingend, denn eigentlich sind sie kein Problem, auch nicht in Skripten.

Verwendet man natürlich die hier auffindbaren Skripte, dann kann es zum Problem werden, da diese zum größten Teil nicht sauber programmiert sind. (Darunter auch eines von mir.)

Dennoch ist es sinnvoll die Namen eindeutig zu machen. Schon alleine wegen des Überblickes.

[alchy]

Ich weiß zwar nicht, was das schon wieder soll,
aber eine einfache Abfrage (lt. Doku auch so möglich) eines Datenpunktes

Code: Alles auswählen

var myChannel = dom.GetObject("Küche Molke"); 
var dp = myChannel.DPByHssDP("TEMPERATURE");
WriteLine(db.Value());

wird *IMHO* für den TE zum Glückspiel, wenn Geräte und Kanalname gleich sind.
Und was daran unsauber sein soll, kann ich mir auch nicht vorstellen, aber Du wirst es mir sicher mitteilen.

Aber grundsätzlich war das auch nur ein gut gemeinter Hinweis an den TE.
Es ist mir nebenbei nur aufgefallen beim Durchlesen seiner Frage, die ihm keiner beantworten konnte / wollte.
Mein obiges Script sollte eigentlich auch bei seiner Namensvergabe funktionieren und das machen, was ich aus seiner Frage verstanden habe.

Alchy

[BadenPower]

Aber grundsätzlich war das auch nur ein gut gemeinter Hinweis an den TE.

Das war auch richtig so und habe ich ausdrücklich unterstrichen.

Ich weiß zwar nicht, was das schon wieder soll,
aber eine einfache Abfrage (lt. Doku auch so möglich) eines Datenpunktes

Code: Alles auswählen

var myChannel = dom.GetObject("Küche Molke"); 
var dp = myChannel.DPByHssDP("TEMPERATURE");
WriteLine(db.Value());

wird *IMHO* für den TE zum Glückspiel, wenn Geräte und Kanalname gleich sind.
Und was daran unsauber sein soll, kann ich mir auch nicht vorstellen, aber Du wirst es mir sicher mitteilen.

Selbstverständlich werde ich es Dir verraten, denn wir sind ja alle zum Helfen und Lernen da.
Und um zu verhindern, dass Probleme überhaupt entstehen können.

Das ist zwar möglich,

Code: Alles auswählen

var myChannel = dom.GetObject("Küche Molke"); 

aber generell "unsauber", da, wie Du ja selbst schreibst, es ein Glückspiel ist, was mit dom.GetObject() in Verbindung mit einem Namen hervorgezaubert wird.

"Sauber" hingegen wäre:

Code: Alles auswählen

var myChannel = (dom.GetObject(ID_CHANNELS)).Get("Küche Molke"); 

oder gleich über die entspechende vordefinierte systeminterne Variable "channels".

Code: Alles auswählen

var myChannel = channels.Get("Küche Molke"); 

Mit beiden Varianten ist immer gewährleistet, dass das Skript auch tatsächlich (hier eben) den Kanal nimmt und nicht irgendetwas.

Das Gleiche gilt entsprechend eben für Programme, Favoriten, Geräte, Systemvariabeln.

[alchy]

Du hast ags. meine Intention missverstanden.
Mir ist schon bewusst, das man vieles anders machen kann bzw. könnte, aber das weißt du sicher.
Ich komme halbwegs klar mit Scripten, den Internas der CCU, ich habe meine eigenen "Bugumgehungsregeln"
die ich beachte usw.
Nur sehe ich mich nicht in der Pflicht, jeden Fehler der besteht zu umgehen,
denn Andere verdienen damit ihr Geld ! Das macht nämlich der Hersteller noch fauler.

Mmh, obwohl es ist auch eine Umgehung, wenn ich schreibe:
"kein Objekt darf so heissen, wie ein anderes Objekt" .

Egal , um das noch einmal klar zu stellen:

Das Beispiel steht so wie ich es schrieb im Handbuch zur Datenpunktabfrage!
Da ist es ein bisschen flach, wenn du

Das ist zwar möglich, aber generell "unsauber", da...

schreibst, oder?
Nein, das ist vom Hersteller gefälligst so zu machen, das es immer funktioniert.

Denn für mich ist das Problem Folgendes:

Ein unbedarfter User nimmt sich da Handbuch (Ja ich weiß, passiert selten )
und macht alles so wie es dort steht.
Er benennt den Sensor eben so wie der TE, er arbeitet sich durch das Handbuch zur Datenpunktabfrage, macht alles so wie es sein soll und TROTZDEM funktioniert es nicht.
Und warum: weil es möglich war den Kanal wie das Gerät zu benennen!
oder von mir aus auch, das Handbuch den verkehrten Weg zur Datenpunktabfrage propagiert

Weiteres Beispiel dazu:
Ich habe schon zig Mal geschrieben, das ich z.B. die Variante Datenpunktabfrage mit Seriennummer statt Namen bevorzuge und wurde immer wieder deswegen angemacht von Usern, die lieber Namen verwenden, weil.....
Warum wohl schreib ich es trotzdem seit Jahren immer wieder?
Bestimmt nicht weil ich nicht wüsste, wie es anders geht.
Es ist genau dieser Fehler der mich schon seit Jahren dazu treibt.
Ich muss als Mod und Helfender auch mit der "Unwissenheit" (und bitte bloß nicht falsch verstehen) der fragenden, bzw. mitlesenden User rechnen, die eben ihre Namen wie der TE gestaltet haben. Es ist ergo für mich einfacher zu supporten hier im Forum mit Serials.
Ich habe oft genug auf diesen Fehler hingewiesen. Es ist nicht sauber, oder nur halbherzig programmiert.
(z.B. Systemvariable kann man ja nicht doppelt anlegen usw.)

Das obige Beispiel ist (denke ich) für jeden nachvollziehbar, oder ausprobierbar.
Und hier ist eigentlich nicht der Platz für solche Diskussionen. Muss mal überlegen, ob wir das nicht
Abtrennen und zu bekannt Bugs verschieben. Vielleicht liest da mal EQ3 mit.

Alchy

[BadenPower]

(z.B. Systemvariable kann man ja nicht doppelt anlegen usw.)

Auch ein Gerät kann nicht doppelt angelegt werden.
Auch ein Kanal kann nicht doppelt angelegt werden.
Auch ein Datenpunkt-Name kann nicht doppelt angelegt werden.
Auch ein Raum kann nicht doppelt angelegt werden.
Auch ein Favorit kann nicht doppelt angelegt werden.
Auch ein Gewerk kann nicht doppelt angelegt werden.
Auch ein Programm kann nicht doppelt angelegt werden.
(alles unter normalen Umständen)

Ich muss als Mod und Helfender auch mit der "Unwissenheit" (und bitte bloß nicht falsch verstehen) der fragenden, bzw. mitlesenden User rechnen, die eben ihre Namen wie der TE gestaltet haben. Es ist ergo für mich einfacher zu supporten hier im Forum mit Serials.
Ich habe oft genug auf diesen Fehler hingewiesen. Es ist nicht sauber, oder nur halbherzig programmiert.

Ja eben.

Wäre es dann nicht gleich besser auf eine falsche Vorgehensweise zu verzichten, auch wenn sie so in der Anleitung steht?

Sollte es nicht unser Bestreben sein, den "ahnungslosen" Usern eben einen Code zur Hand zu geben, welcher eben immer funktioniert?

Was spricht dagegen in den Beispielen eben statt dem fehlerbehafteten

Code: Alles auswählen

var myChannel = dom.GetObject("Küche Molke");

den in allen Situationen fehlerfrei arbeitenden Code

Code: Alles auswählen

object myChannel = (dom.GetObject(ID_CHANNELS)).Get("Küche Molke");

oder

Code: Alles auswählen

object myChannel = channels.Get("Küche Molke");

auf den Weg mitzugeben, wenn der Hersteller uns diese Möglichkeiten schon gibt?

.

[alchy]

Habe die Diskussion mal aus dem Thread entfernt und ein eigenes Thema aufgemacht um es übersichtlicher zu belassen.

(z.B. Systemvariable kann man ja nicht doppelt anlegen usw.)

Auch ein Gerät kann nicht doppelt angelegt werden.
Auch ein Kanal kann nicht doppelt angelegt werden.
Auch ein Datenpunkt-Name kann nicht doppelt angelegt werden.
Auch ein Raum kann nicht doppelt angelegt werden.
Auch ein Favorit kann nicht doppelt angelegt werden.
Auch ein Gewerk kann nicht doppelt angelegt werden.
Auch ein Programm kann nicht doppelt angelegt werden.
(alles unter normalen Umständen)

jaja, ich weiß, daher ja auch z.B. ..... usw.)
Daran siehst du doch auch, der Programmierer wußte schon, das er doppelte Objektnamen verhindern muss.
Nur hat er eben nicht immer daran gedacht.

Wäre es dann nicht gleich besser auf eine falsche Vorgehensweise zu verzichten, auch wenn sie so in der Anleitung steht?
Sollte es nicht unser Bestreben sein, den "ahnungslosen" Usern eben einen Code zur Hand zu geben, welcher eben immer funktioniert?
Was spricht dagegen in den Beispielen eben statt dem fehlerbehafteten

Code: Alles auswählen

var myChannel = dom.GetObject("Küche Molke");

den in allen Situationen fehlerfrei arbeitenden Code

Code: Alles auswählen

object myChannel = (dom.GetObject(ID_CHANNELS)).Get("Küche Molke");

oder

Code: Alles auswählen

object myChannel = channels.Get("Küche Molke");

auf den Weg mitzugeben,

.

Meine Herrn, du willst es nicht verstehen.
Es spricht doch nichts dagegen. Wer hält dich denn davon ab?
Du kannst auch gerne dem Hersteller mitteilen, das er unsauber programmiert.
Du kannst gerne die Beiträge melden über die Meldefunktion, wo du denkst, das der Code "unsauber" ist
oder besser Kontakt mit dem Veröffentlicher aufnehmen.

Trotzdem ist *IMHO* in erster Linie der Hersteller gefragt, das zu fixen.

Was ändert sich denn für den o.g. User der das Handbuch durchliest, wenn hier irgendwo im Forum ein besserer Code steht, als der Hersteller es sich jemals gedacht und dokumentiert hat?
Nichts, oder genauso wenig, wie wenn wir 20+ mal im Forum darauf hingewiesen haben, das Objektnamen einzigartig sein müssen, was das Problem ebenso umgeht. Man denke nur an die Tipps für Anfänger die leider kaum einer liest, und da steht das auch drin.

..wenn der Hersteller uns diese Möglichkeiten schon gibt??

Na jetzt übertreibst du aber wirklich.
Ich glaube nicht das das dokumentiert ist (weiß es aber auch nicht genau und mag nicht nachlesen).
Du weißt wahrscheinlich mehr über die Internas, als der Hersteller selber.
Nur bedenke auch, das wissen das eben nicht alle User hier, die Scripte veröffentlichen.
Denen nun (für diesen Fall) unsauberes Scripting vorzuwerfen ist *IMHO* falsch.
Es soll wirklich Leute geben, die lesen ein Handbuch und nehmen das dort geschriebene als richtig an.

Alchy
kommt mir vor wie "teddy returns"

[dtp]

Es soll wirklich Leute geben, die lesen ein Handbuch und nehmen das dort geschriebene als richtig an.

Nun ja, es steht ja auch nichts Falsches im Handbuch. Es ist nur leider nicht der eigentlich zu vermeidende Fall abgedeckt, dass ein Kanal denselben Namen trägt, wie das Gerät. Und nur in diesem Fall kommt man dann mit dem entsprechenden Skriptbefehl des Handbuchs nicht zum Ziel. Ich finde den Workaround von BadenPower daher sehr hilfreich.

Übrigens lesen ich in Skripten lieber die Namen als die Seriennummern aus. Warum? Weil man im Falle eines Komponentendefekts in der Regel der die defekte Kompononte ersetzende Komponente denselben Namen gibt. Und dann braucht man sich über die Skripte, in denen der Name der defekten Komponente abgefragt wurde, keine Gedanken zu machen. Kommt zwar glücklicherweise nicht sehr häufig vor, kann aber durchaus mal passieren.

Ich werde jetzt mal in meinen Skripten nachsehen, ob es irgendwo einen Bedarf gibt, die entsprechenden Codezeilen zum direkten Auslesen des Kanalnamens anzupassen. Ich habe nämlich sämtlichen Geräten mit nur einem einzigen Kanal immer identische Geräte- und Kanalnamen verpasst. Wenn ich nun an bestimmten Stellen statt der Seriennummer trotzdem den Kanalnamen verwenden kann, wäre das gar nicht mal so schlecht.

Gruß,

Thorsten

[BadenPower]

Ich werde jetzt mal in meinen Skripten nachsehen, ob es irgendwo einen Bedarf gibt, die entsprechenden Codezeilen zum direkten Auslesen des Kanalnamens anzupassen. Ich habe nämlich sämtlichen Geräten mit nur einem einzigen Kanal immer identische Geräte- und Kanalnamen verpasst. Wenn ich nun an bestimmten Stellen statt der Seriennummer trotzdem den Kanalnamen verwenden kann, wäre das gar nicht mal so schlecht.

Du kannst alle IDs gegen die Namen austauschen, also nicht nur bei den Kanälen.

Wenn Du einen Raum und ein Gewerk mit dem gleichen Namen hast und eben auf ein Gewerk zugreifen möchtest, dann nimm auch hier nicht dom.GetObject("xyz"), sondern eben immer die entsprechende Liste und verwende dann .Get("xyz").

Gleiches eben für alle Objektarten, wie Systemvariablen, Räume, Gewerke, Favoriten, Programme, Geräte, Kanäle, Benutzer...

Dann hast Du es lesbar und greifst auch immer exakt auf das Objekt zu, welches Du haben wolltest.

Diese Vorgehensweise ist eben dem dom.GetObject("xyz") vorzuziehen, da es auch bei doppelten/dreifachen/vierfachen Namen immer das korrekte Objekt liefert und hätte schon Stunden Fehlersuche vermieden.
.