Es ist also so, das auch Knoten existieren, die nicht im Namensraum beim browsen auftauchen?
das hast du genau richtig erkannt. Browsen kann man "Symbole" (und Alias Namen, ein Relikt aus früheren Tagen, gibt es bei UA nicht mehr). Wenn man die NodeID kennt braucht man nicht browsen. Es kann NodeIDs geben, die nicht browsbar sind bzw. die nicht im Adressraum auftauchen.
Ich konnte die bisherigen Knoten, mit denen ich getestet habe bisher über zwei Möglichkeiten ansprechen
das ist nicht ganz richtig, es gibt nur EINE Möglichkeit eine Node anzusprechen sie besteht immer aus "NameSpace + Typ + ID", die ID ist im Namespace eindeutig, der Typ kann "String" ODER "Numeric" sein (oder GUID oder Opaque, allerdings nicht bei Siemens).
Also es gibt einen durch OPC Foundation definierten Namensraum (namespace index 0) in dem sind numeric IDs eindeutig durch die OPCF spezifiziert, alle UA Server dieser Welt MÜSSEN diesen namespace 0 haben, die ID darin sind FEST und können nicht verändert werden:
ns=0; i(numeric)=2212
und dann gibt es von Siemens definierte/konfigurierte NodeIDs, die sind vom Typ "String" und folgen einer Syntax, die vom Namespace abhängt in dem sie existieren.
ns=3(S7); s(string)="S7:[Verb1]DB1.0,b"
ns=4(S7Com); s(string)="S7:[Verb1]DB1,b0,1"
ns=5(SYM); s(string)="MeinSymbol"
Wobei "SYM" die Symbolik ist und (relativ) frei gestaltbar in ihrer Syntax (einige Soderzeichen sind nicht erlaubt). SYM wird "normalerweise" automatisch von Step7 erzeugt und enthält die symbolischen Namen, die bei der Programmierung der SPS in Step7 verwendet wurden.
Nur DU musst die Symbole nun händisch anlegen, weil du keine SPS hast, sondern einen "internen" DB verwendetst.
Warum macht das Sinn nicht alle Knoten über einen identifiziertyp anzusprechen? Zum Beispiel alle über eine numerische ID?
NEIN, das macht überhaupt keinen Sinn, das Konzept mit Namespaces ist das EINZIGE das Sinn macht (flexibel und erweiterbar), und deshalb wurde es auch so umgesetzt.
