Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[DJMarc75]

@danny_v1 sagte in Verwendungsstellen von Datenpunkten anzeigen:

wie funktioniert das mit der Suche im Javascript

na ganz einfach - die Lupe links oben anklicken und dann nach dem DP suchen

[Homoran]

@djmarc75 sagte in Verwendungsstellen von Datenpunkten anzeigen:

die Lupe links oben anklicken und dann nach dem DP suchen

und da ist sie ganz rechts :joy:

im Skripte Explorer

EDIT:

alter Editeur ;-)

[danny_v1]

Super danke!

Aber global also im Objektbaum vom iobroker gibts sowas nicht oder?

[dodi666]

@danny_v1 nein, leider nicht. Aber das wäre ein Traum :-)

[oFbEQnpoLKKl6mbY5e13]

@dodi666

Dafür kann man ja filtern, wozu bräuchte man da eine Suche?

[Homoran]

@danny_v1 sagte in Verwendungsstellen von Datenpunkten anzeigen:

Aber global also im Objektbaum vom iobroker gibts sowas nicht oder?

???

was willst du da nach Datenpunkten suchen?
Die ID ist doch unique.

[dodi666]

@ofbeqnpolkkl6mby5e13 ich fände es schon sehr komfortabel, wenn man einem Datenpunkt "ansehen" könnte, an welchen Stellen (Skripte/Szenen/Visualisierungen/Adaptern usw.) dieser Verwendung findet. Natürlich bekommt man das alles irgendwie raus, aber komfortabel und übersichtlich sind die Möglichkeiten in meinen Augen nicht...

[oFbEQnpoLKKl6mbY5e13]

@dodi666

Das ist natürlich noch mal eine andere Aufgabenstellung. Dazu müsste jeder Adapter bei der Verwendung eines Datenpunktes außerhalb seines eigenen Namensraums im Datenpunkt vermerken, dass er diesen verwendet und an welcher Stelle. Vielleicht könnte man auch eine Art Index erstellen. Aber dazu müsste vermutlich ein (Core)Entwickler ( @foxriver76 @apollon77 ) was sagen, welche Möglichkeiten es da gäbe.

Edit:
Der Javaskript-Adapter abonniert doch alle States. Somit sollte er doch auch die Quelle für den Zugriff auf einen Datenpunkt kennen.

Edit2:
Aber der bekommt das ja auch nur mit, wenn der State zumindest aktualisiert wird. Lesenden Zugriff wohl eher nicht.

[Homoran]

@dodi666 sagte in Verwendungsstellen von Datenpunkten anzeigen:

wenn man einem Datenpunkt "ansehen" könnte, an welchen Stellen (Skripte/Szenen/Visualisierungen/Adaptern usw.) dieser Verwendung findet.

Selbst wenn das technisch machbar sein würde, ergäbe das IMHO keinen Sinn.
Die Objektansicht würde dermaßen aufgebläht, dass die Übersicht verloren ginge und -viel schlimmer- wahrscheinlich die Ansicht einfrieren würde, wie es jetzt schon der Fall ist, wenn zu viele Knoten geöffnet sind.

Ich skripte nicht wirklich viel, aber alle verwendeten (auch mehrfach) States noch in den Objekten aufzulisten würde gefühlt mehrere Seiten benötigen

[dodi666]

@homoran also der "Sinn" ist meiner Meinung nach schon gegeben. Das man damit ganzheitlich vielleicht an technische Grenzen stößt ist in meinen Augen etwas ganz anderes. Vorstellbar wäre ja auch ein Prozess, der einem die Möglichkeit gibt, auf Anforderung alle Verwendungen eines Datenpunktes auszulesen und in ein Textfile zu schreiben. Nur so eine Idee...

[Homoran]

@dodi666 sagte in Verwendungsstellen von Datenpunkten anzeigen:

Das man damit ganzheitlich vielleicht an technische Grenzen stößt

das ist ein ganz anderes Thema (s.u.)

@dodi666 sagte in Verwendungsstellen von Datenpunkten anzeigen:

der "Sinn"

des Admin ist es übersichtlich zu bleiben.
zu jedem State noch alle Stellen in Skripten und Konfigurationen anzuzeigen ist dazu kontraproduktiv.

Wenn ich alleine shuttercontrol ansehe, wo für die Steuerung von nur 7 Rollläden jeweils der zugehörige Innen- und Außentemperatur sensor, der Türsensor, Drehgriffsensor und Helligkeitssensor dowie Azimut und Elevation angegeben wird, so sind das alleine 49 zusätzliche Zeilen.

Fundstellen in Skripten übersteigen dies um ein Vielfaches.

Technisch gesehen müsste jetzt auch noch beim State "Außentemperatur vorne" angegeben werden, bei welchem Rollladen in der Konfiguration dieser State verwendet wird.

[dodi666]

@homoran deswegen ja der Vorschlag, das Ergebnis der Abfrage eines Datenpunktes in eine externe Datei zu schreiben. Der Admin bleibt doch dann davon komplett unberührt.

[danny_v1]

Der Sinn ist finde ich schon gegeben, manchmal baut man eben mal was um oder ein Sensor wird ausgetauscht, entfällt oder sonst was, oder irgendwelche Hilfsdatenpunkte die man sich erstellt hat wo man nicht mehr genau weiß wer greift alles darauf zu. So könnte man überprüfen wo werden die Datenpunkte verwendet bevor man sie löscht. Einfach um das System sauber zu halten.
Die schönste Lösung wäre das über die Eigenschaften im Objektbaum zu machen aber sicher auch die aufwendigste. Ich könnte mir auch vorstellen das es vielleicht über einen Adapter geht, wo man den Datenpunkt oder Ordner prüfen lassen kann.

[mcm1957]

Die Frage ist da zuerst mal was unter "Verwendung eines States" zu verstehen ist.

Wenn die Id im javascript Adapter in einem Skript verwendet wird, dann ist das via Textsuche schon jetzt (halbwegs) eruierbar. Zentral wäre eine gesicherte Suche (- die Id kann ja auch nur in einem Kommentar oder log text stehen - aufwändig. Wenn der Text zur Laufzeit dynamisch zusammengesetzt wird nutzt eine Testsuche nichts - da müsste dann bei alle Zugriffe getracked werden ...

ABER die Verwendung in einem Adapter lässt sich nicht trivial tracken. Der Adapter kann einen State gezielt durch Angabe der Id lesen - das wäre prinzipiell trackbar aber erst nach dem ersten Zugriff. Der Adapter kann aber auch States subscriben und wird dann über Änderungen informiert. Je nach Anzahl subscribed ein Adapter einzelne States (- wäre trackbar -) oder auch eine Auswahl durch eine Wildcard. Da dabei der core nicht weiß welche konkreten States der Adapter dann beachtet und welche er ignoriert ist das nicht (sinnvoll) trackbar.

Insgesammt steht meiner Ansicht nach der Aufwand - sofern er überhaupt sinnvoll machbar ist - in keiner Relation zu Erfolg.

Du kannst aber jederzeit einen Feature Issue erstellen. Ich möchte einer allfälligen Diskussion hier keinesfalls final vorgreifen.

Bezüglich Gerätetausch verweise ich auf das Thema ALIAS.

[Homoran]

@mcm1957 sagte in Verwendungsstellen von Datenpunkten anzeigen:

in keiner Relation

Bei 90.000 Usern kommt diese Frage zum allerersten Mal auf.
Wenn es ein sooo wichtiges Feature wäre, hätte sich bestimmt schon mal der ein odere andere dies gewünscht.

Natürlich wäre es nice to have, jetzt wo darüber gesprochen wird.

[dodi666]

@homoran Ich glaube die Frage ist immer, welche Erfahrungen man mit ähnlich gearteten Systemen hat. Im Bereich der Industrieautomatisierung gibt es solche Funktionen besispielsweise bei Prozeßleitsystemen oder SPSen durchaus. Bei der Benutzung des iobrokers im Bereich der Heimautomatisierung habe ich mir die Frage schon relativ früh gestellt bzw. die Funktion gewünscht, allerdings benutzt man dann halt die bekannten "workarounds" und kann damit auch leben... Sinvoll ist eine solche Funktion in meinen Augen definitiv, ob aber die Machbarkeit bzw. das Aufwand/Nutzen Verhältnis okay sind, das kann ich überhaupt nicht bewerten.

[Homoran]

@dodi666 sagte in Verwendungsstellen von Datenpunkten anzeigen:

Im Bereich der Industrieautomatisierung gibt es solche Funktionen besispielsweise bei Prozeßleitsystemen oder SPSen durchaus

das glaube ich dir, aber das sind auch keine offenen Systeme mit 500 möglichen Zusatzmodulen.

und eben keine
@dodi666 sagte in Verwendungsstellen von Datenpunkten anzeigen:

die Frage ist immer, welche Erfahrungen man mit ähnlich gearteten Systemen hat

ich kenne das auch bei geschlossenen Systemen, deren Struktur anders aufgebaut ist, als die von iobroker.

Und wie viele User von SPSen hier aufschlagen sieht man schön an der anderen Denkweise als bei Javascript.
Die eventbasierte Aktion ist dort weitestgehend unbekannt.

[Codierknecht]

@dodi666 sagte in Verwendungsstellen von Datenpunkten anzeigen:

ob aber die Machbarkeit bzw. das Aufwand/Nutzen Verhältnis okay sind

Ich denke, @mcm1957 hat gut dargelegt, welche Schwierigkeiten da zu berücksichtigen sind.
Das wird ganz schnell ein Fass ohne Boden.

Es steht Dir natürlich frei, eine Art "Such-Adapter" anzufragen.
https://github.com/ioBroker/AdapterRequests

[mcm1957]

@codierknecht

Ich seh keine Möglichkeit wie ein Adapter das suchen könnte.
Wenn dann ginge das nur wenn man (ggF. optionell einschaltbar) das im core (=js-controller) einbaut. Nur dort kommen alle expliziten getState Aufrufe vorbei. Und nur dort gibt es prinzipiell mal die Liste der Subscriptions.

Die theoretische Möglichkeit, dass Adapter das selbts wo registrieren würd ich mal gleich verwerfen. Das machen sicher keine 5% der Adapter devs :-)

Mir fehlt noch ein wenig der Anwendungsfall. Im Primzip kann es ja eigentlich nur um States im 0_user_0 Bereich gehen. States eines Adapters werden ja mit diesem erstellt / gelöscht. Da stellt sich m.E. selten die Frage ob man den State noch braucht - denn ob man den Adapter noch braucht (bzw. seine Daten) sollte man ja eher wissen. Und wenn man den Adapter löscht weil man ihn nicht mehr will, dann melden sich Verwender eh via Fehlermeldung. Ob man die betreffenden Scrips vor oder nach dem Löschen des Adapters kübelt ist da eher egal. Man könnte sogar die Instanz stoppen und die States probeweise löschen. Wenn dann was essentielles nicht mehr geht sollte ein Startend es Adapters ja seine States wieder anlegen.

Bezüglich 0_userdata_0 gilt das natürlich nicht. Da kann man nur mit einer gewissen Struktur und ggF Doku arbeiten. Diese States stehen aber zu einem hohen Prozentsatz in Verbindung mit Skripts - und dageht wieder die Textsuche.

[Homoran]

@mcm1957 sagte in Verwendungsstellen von Datenpunkten anzeigen:

Im Primzip kann es ja eigentlich nur um States im 0_user_0 Bereich gehen.

nein!
wenn es um Fälle die ein alias abfangen könnte, geht, nämlich z.B. Geräteaustausch, müssten alle Stellen in denen der Türkontaxt x verwendet wird (z.b. in shuttercontrol) ebenfalls angezeigt werden.
Oder irgendwelche Power-Daten von irgendwelchen Geräten oder Adaptern (sourceanalytix) die z. B. in Energiefluss verwendet werden....

Um das wirklich allumfassend für alle momentanen und zukünftigen Anforderungen umzusetzen wird das ein Fass ohne Boden.
Dabei meine ich noch nicht mal die Umsetzbarkeit