Verwendungsstellen von Datenpunkten anzeigen
-
@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...
-
@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.
-
@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.
-
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. -
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.
-
@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.
-
@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.
-
@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. -
@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 -
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.
-
@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
