Es wird immer für

adapterName.X.blabla

Gesucht. X ist ein Nummer. Blabla kann dann auch mehrere Stufen beinhalten.

Desswegen lass ich in meinen Scripten die Datenpunkte gleich erstellen. Wenn was schiefgeht, machts das Script neu beim restart.

Dann kann ich dort auch die organisation anpassen.

@ykuendig:

Desswegen lass ich in meinen Scripten die Datenpunkte gleich erstellen. `
Mittels createstate(name, 0, {common-attribute}) werden die Datenpunkte unter der Javascript-Instanz angelegt. Durch Verwendung von Punkten im Namen erhält man eine Ordner-Struktur im Reiter "Objekte". Beispiel:

Hallo,

gibt es die Möglichkeit auch bei Blockly, dass im Blockly die Variable mit angelegt wird?

Gruß Sven

Gesendet von iPhone mit Tapatalk

Hallo Sven,

Ja, es gibt das Blockly Create State.

Damit funktioniert es.

Lg

Günther

@Homoran:

Dein Beispiel zeigt mir, dass es mehr als die drei (manuell erzeugbaren) Ebenen Gerät, Kanal, und Datenpunkt gibt. `
Nein, das passiert alles innerhalb der Datenpunkt-Ebene.
@Homoran:

Weisst du auch (welche Frage :oops: ) wie man das manuell macht? `
Das Beispiel hatte ich manuell gemacht: Die Javascript-Instanz (oder jede andere Adapter-Instanz) anwählen und Datenpunkt erzeugen:

@Homoran:

Ich dachte es sei gut, wenn ich diese Struktur auch beim Löschen von Adaptern erhalten will. `
Wenn Du einmal etwas mit Javascript programmiert hast, kannst Du den JS-Adapter nicht mehr löschen, weil dann einiges nicht mehr läuft.

@Homoran:

Danke Paul,

ich weiss nicht ob es eine gute Idee ist, aber ich wollte eine eigene Objektstruktur außerhalb der Adapter erzeugen.

Ich dachte es sei gut, wenn ich diese Struktur auch beim Löschen von Adaptern erhalten will. `
Das stimmt schon; habe mich etwas daran gewöhnt, das das in der JS-Instanz ist. Und ohne Script geht eh kaum was ;-)

@Homoran:

@ykuendig:

Das stimmt schon; habe mich etwas daran gewöhnt, das das in der JS-Instanz ist. Und ohne Script geht eh kaum was ` selbst wenn die Datenpunkte anschließend wieder neu geschrieben werden, sind ja auch die logging infos weg und müssen wieder hinzugefügt werden.

Das hatte mich am meisten geärgert. Deswegen sollten diese Datenpunkte "sicher" sein. `
Das würde ich so nicht unterschreiben. Wenn ich da was weglösche, macht das Script beim restart den DP neu. Das History Dingens fällt zwar raus, wenn ich den aber neu mach, sind die sql Daten noch immer da.

@Homoran:

…aber ich wollte eine eigene Objektstruktur außerhalb der Adapter erzeugen. `
Dann sollte es in dieser Form funktionieren:

@homoran

Schreib dir ein script, z.B. "Variablen anlegen"
filename="bild1.jpg" index="0">~~

Dort alle manuellen Variablen reinschreiben.

Vorteil:

Du kannst so ganz schnell Variablen anlegen.

Und wenn du mal das System neu aufsetzen musst, kannst du einfach das Script aktivieren und deine manuellen Variablen sind wieder angelegt.

Auch das Berichtigen von z.B. einem Schreibfehler geht damit äußerst schnell (einfach Variable bei Objekten löschen und Script wieder laufen lassen).

mfg

@homoran:

super, das du das Problem zur Sprache gebracht hast - das hat mich auch schon genervt…

Meiner Meinung nach ist das ein Bug. Beim Anlegen im 1. Level sollte man entweder darauf hingewiesen werden ".0" (oder eben .n) noch anzuhängen oder ioBroker müsste es selber machen.

Das die Punkte dann verschwinden geht doch einfach nicht...

Zum Anlegen per script:

In node-red geht eben das auch nicht, da alles was man anlegt unterhalb des node-red adapters angelegt wird.

Warum kann man alle Objekte mit js scripts anlegen, aber mit node-red nicht?

Leider eine weitere unschöne Inkonsistenz :(