Objekte anlegen
-
Der Typ der Datenpunkte ist von gravierender Bedeutung wenn du diese in einer SQL-Db loggen willst!! Und auch wenn du das momentan nicht vorhast - ich würde empfehlen das gleich richtig anzulegen denn irgendwann später holt dich das alles mal wieder ein.
(Gut dass ich mich gar nicht erst mit Blockly beschäftigt habe
) -
Ok,
vielen Dank, dann ändere ich die Datenpunkte per Hand.
Gruß Sven
-
Vielen Dank für diesen Thread und die verschiedenen Möglichkeiten, Datenspuren anzulegen.
Was ist denn nach Eurer Erfahrung die empfehlenswerteste Methode? Unter JavaScript wie dort http://forum.iobroker.net/viewtopic.php?p=54527#p54527 oder als eigene Struktur wie z.B. "Messwerte" wie hier http://forum.iobroker.net/viewtopic.php?p=54567#p54567 und da http://forum.iobroker.net/viewtopic.php?p=54569#p54569 gezeigt.
Ich frage, weil ich die Tiefen des Systems noch nicht durchschaue aber andererseits solche Strukturen dan auch so belasse und selten ändere oder "aufräume". Also sollte eine solche Struktur bei mir tragfähig und zukunftssicher sein.
-
Was ist denn nach Eurer Erfahrung die empfehlenswerteste Methode? `
Ich bevorzuge die Methode, völlig neue Datenpunkte unter javascript.N (parent) im Reiter Objekte zu erzeugen, da kompatibel mit createState(name, init, {…}). Namensvergabe: Raum.Funktion oder bei umfangreicherer Installation Gewerk.Raum.Funktion. Die ID ist dann javascript.N.Gewerk.Raum.Funktion. Aussen sehe ich auch als Raum an.Gleiche Datenpunkte für weitere Räume erzeuge ich per Kopieren mit folgendem Skript
function copyDatapoint(src, dst) { var sid = getIdByName(src); var sdp = getObject(sid).common; createState(dst, sdp.def, { read: sdp.read, write: sdp.write, desc: sdp.desc, type: sdp.type, min: sdp.min, max: sdp.max, def: sdp.def, unit: sdp.unit, states: sdp.states, role: sdp.role }); } copyDatapoint("Klima.Aussen.Feuchtegehalt", "Klima.Bad.Feuchtegehalt");, das ich nur während des Kopierens aktiviere.
-
Ich bin auch gerade dabei ähnliches aus anderen Gründen zu überdenken.
Mein Wunsch an den Weihnachtsmann (den blauen Weihnachtsfuchs) wäre auch gerade in Hinblick auf Noobs, ein standardmäßig existierender Objektbaum für "Systemvariablen". Als Sahnehäubchen on top wäre vielleicht ein Adapter, der diesen Objektbaum verwaltet, ähnlich dem Dateiexplorer im javascript-Adapter, und das alle selbst angelegten Datenpunkte dort angelegt würden.
Und die Kirsche auf der Sahnehaube wäre eine Import/Export-Funktion des Objektbaumes (Ich weiß, geht in Objects auch mit einem Klick).
Usecase: Systemumzug
Bei mir ist es natürlich ganz extrem, da ich viel mit verschiedener Hardware experimentiere. Dazu installiere ich die exakt gleiche Installation auf der zu testenden Hardware. Hier ist es jedesmal ein Aufwand die Datenpunkte für Skripte wieder anzulegen, oder in den Views und charts anzupassen.
Bei einem System, das immer auf die gleichen Objekte im gleichen Objektbaum zugreift wären die notwendigen Anpassungen um einiges weniger.
Im Moment schreibt z.B. node-red neue Objekte in den node-red-Objektbaum, auch wenn ich auf die Objekte in meinem eigenen Baum zugreife, js in den js.0 Baum usw.
(Ich hätte da in Kürze einen eigenen Thread an den Weihnachtsmann aufgemacht, ich habe da nämlich noch ein paar Wünsche
)Gruß
Rainer
-
Ja, vielen Dank für die nützlichen Hinweise.
CreateState kannte ich noch gar nicht.
Das macht natürlich Sinn, sich auf eine eingebaute Funkion abzustützen.
Wenn ich es richtig verstanden habe, werden also keine Datenpunkte erzeugt, sondern Objekte. Diese Objekte tragen nicht nur die Daten, sondern auch Metadaten wie Einheit, Gewerk, Raum. Macht für mich auch Sinn.
Die Objekte werden erstmal händisch erzeugt. Wenn man die Struktur in einen anderen Raum übertragen möchten, kann man das Skript nutzen. Ich nehme an, die unterste Zeile wird angepasst, das Skript gestartet und gestoppt.
Müssen die Objekte zwangsläufig z.B. javascript.0 als parent haben, oder kann das auch die root sein? Dann werden die Ids nicht so lang
Ich möchte die Daten von aussen z.B. von einem ESP32 über http und simple.api Adapter setzen. Geht das mit Objekten auch?
-
Ich nehme an, die unterste Zeile wird angepasst, das Skript gestartet und gestoppt. `
Richtig.
@klassisch:Müssen die Objekte zwangsläufig z.B. javascript.0 als parent haben, oder kann das auch die root sein? Dann werden die Ids nicht so lang `
Nein, aber in der root müssen die Namen mit irgendwas.N. (N = Ziffer) beginnen, da es sonst Probleme geben kann. Außerdem ist das Skript zum Datenpunkt-Kopieren dann so nicht verwendbar. -
Hier ist es jedesmal ein Aufwand die Datenpunkte für Skripte wieder anzulegen, oder in den Views und charts anzupassen.
Bei einem System, das immer auf die gleichen Objekte im gleichen Objektbaum zugreift wären die notwendigen Anpassungen um einiges weniger. `
Beim Anlegen wird das nicht helfen, aber ist dafür nicht der Wrapper-Adapter gedacht? -
IMHO ist der Wrapper für das andere Ende zuständig.
Wenn sich der Datenpunktname z.B. in Homematic ändert.
Ich erstelle ja dauernd neue ioBroker Installationen
Hier ist es z.B. der $System.Host$, der von Installation zu Installation anders heißt.
Oder eben das zweite "Issue" ist, dass die selbst angelegten Variablen auf die die verschieden Adapter (js/node-red/vis/flot) über diverse Objektbäume verstreut sind.
Hier wäre es um ein vielfaches einfacher, wenn ich beim Umzug nur einen Objektbaum hätte und diesen Ex- und importiere und alle DPs wieder vorhanden sind, die in den Skripten usw. benötigt werden.
Gruß
Rainer
-
IMHO ist der Wrapper für das andere Ende zuständig.
Wenn sich der Datenpunktname z.B. in Homematic ändert. `
Dann hab ich dich falsch verstanden, ich dachte du musst die Skripte/etc. anpassen, weil die Datenpunktnamen sich ändern.Zu deinem zweiten Thema:
Du willst zusammengehörende States verschiedener Adapter lieber in einem thematisch eingegrenzten Objektbaum haben? Klingt erst mal logisch.
Die Frage ist nur wie die zahlreichen Adapter damit klar kommen. Viele subscriben ja auf States und das ist per default erstmal eingegrenzt auf den Adapter-Namespace "flot.0" usw. Da müsste die Zugehörigkeit zum Adapter vermutlich irgendwie anders erkannt werden als über den Namen.
-
Ich bin da nicht sooo der Programmierer
Ich habe weder mit Blockly, noch mit node-red das Problem meine "Systemvariablen" aus einem anderen Verzeichnisbaum zu lesen und zu schreiben.
Nur bei node-red ist es mir aufgefallen, dass immer ein weiterer Datenpunkt zusätzlich unter node-red.0 angelegt wird.
Vielleicht habe ich auch hier nicht ganz deutlich gemacht, worum es mir geht (oder was ich vielleicht immer falsch gemacht habe).
In einem Backup sind die selbst angelegten Datenpunkte nicht enthalten. ich muss diese immer wieder manuell anlegen.
Da diese in den Skripten usw. benutzt werden wäre es einfacher zusätzlich zum Backup nur einen Objektbaum zu exportieren und in der neuen Installation wieder zu importieren, als alle selbst angelegten (Teil-) Strukturen einzeln zu sichern.
Gruß
Rainer
-
In einem Backup sind die selbst angelegten Datenpunkte nicht enthalten. `
Wieso das ? In der Datei /opt/iobroker/iobroker-data/objects.json sind alle Objekte enthalten. -
Wieso das ? In der Datei /opt/iobroker/iobroker-data/objects.json sind alle Objekte enthalten. `
Auch wenn ein kompletter Objektbaum erstellt wurde?Oder greift bei mir vielleicht:
@paul53:Nein, aber in der root müssen die Namen mit irgendwas.N (N = Ziffer) beginnen, da es sonst Probleme geben kann. `
Das werde ich mir dann nochmal etwas näher ansehen müssen, aber ich könnte schwören, dass ich diesen selbst erstellten Baum immer wieder neu anlegen musste.
Gruß
Rainer
-
Auch wenn ein kompletter Objektbaum erstellt wurde? `
Ja.
@Homoran:Oder greift bei mir vielleicht:
Nein, aber in der root müssen die Namen mit irgendwas.N (N = Ziffer) beginnen, da es sonst Probleme geben kann. `
Vielleicht ? Ich habe es noch nicht anders probiert oder kann mich nicht mehr daran erinnern. -
Ok, dann sehe ich mir das am Wochenende mal näher an.
Auf dem Rock64 habe ich jetzt (fast) alles neu angelegt.
Mal sehen ob es mit dessen Backup klappt. Ich muss mir nur noch ein Opfer aussuchen, auf dem ich die neue Installation aufsetze
Gruß
Rainer
-
Guten Abend zusammen,
als Neuling fräse ich gerade durch diverse Threads, finde aber nicht die richtigen Infos.
Zum Thema Objekte anlegen: Kann ich auch mittels Javascript neue Objekte in z.B. in FHEM Geräten, sprich im Adapter fhem.0 anlegen?
Gruss
Pfuetze
-
Kann ich auch mittels Javascript neue Objekte in z.B. in FHEM Geräten, sprich im Adapter fhem.0 anlegen? `
Wenn du in den Adapter-Einstellungen setObject aktiviert hast, geht das mit der setObject-Funktion.Ob das ne gute Idee ist, hängt davon ab was du machen willst
-
Ob das ne gute Idee ist, … ` Was meinst Du damit? setObjects aktivieren oder im Datenbereich anderer Adapter herumwirbeln?
Frage deshalb: Ich habe eine eigene Datenspur (NICHT unter javascript.0) für die Daten der ESP32 und meine internen Rechenergebnisse. Darauf möchte ich von Javascript aus schreibend und lesend zugreifen. Derzeit lege ich die Datenspuren noch von Hand an, denke aber auch über einen Satz von Scripts nach, die das über setOjects tun. Man muß ja nur einmal anlegen und in diesem Zeitraum kann man das ja aktivieren.
-
Ne eigene Datenstruktur ist allerdings was anders. In fremden Adaptern rumfummeln ist halt so ein Ding.
Gesendet von iPhone mit Tapatalk
-
O. k., verstanden. Von fremden Adaptern möchte ich auch nur die Daten abholen , also lesen. Deshalb auch einen eigenen Datenbereich, damit der eventuelle Schaden vor der eigenen Haustüre bleibt
Gesendet von meinem ZTE A2016 mit Tapatalk
