Verwendungsstellen von Datenpunkten anzeigen
-
@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:
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"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@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/AdapterRequestsIch 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.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
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
Support us
430
Online32.7k
Users82.5k
Topics1.3m
Posts