[Zurückgezogen] - jsonlist2 Parameter für Ausgabe InternalValues

[Benni]

Hallo Rudi,

ich habe aktuell einen Anwendungsfall, wo ich ein jsonlis2 benötige, in dem auch die versteckten InternalValues enthalten sind.
Die Steuerung für jsonlist2 ist, wenn ich es richtig sehe, aktuell nur über das global Attribut showInternalValues möglich.
Ich möchte aber unabhängig vom global Attribut, direkt beim jsonlist2-Aufruf bestimmen können, ob ich die versteckten InternalValues im Ergebnis haben möchte oder nicht.

Von daher Schlage ich mal ein Patch für JsonList2 vor (im Anhang), der das über entsprechende Parameter möglich macht:

Code Auswählen Erweitern

jsonlist2 [-int|-noint] [<devspec>] [<value1> <value2> ...]

gb#

[betateilchen]

Spontan in den patch geschaut, finde ich es einfach gruslig, global schaltbare Verhalten durch modifizierte Einzelaufrufe zu verändern und sogar zu übersteuern. Das kann auf Dauer unsupportbar werden und sollte deshalb m.E. dringend vermieden werden.

[Benni]

Spontan in den patch geschaut, finde ich es einfach gruslig, global schaltbare Verhalten durch modifizierte Einzelaufrufe zu verändern und sogar zu übersteuern. Das kann auf Dauer unsupportbar werden und sollte deshalb m.E. dringend vermieden werden.

Du hast aber auch immer was auszusetzen!

Grundsätzlich gebe ich dir da schon recht!

Bei jsonlist2 ist aber der Anwendungsfall meistens sowieso schon etwas spezieller:
jsonlist2 wird i.d.R. von externen Anwendungen (bspw. alternative UI) für den Abruf von FHEM-Devices verwendet. Ist also sowieso schon Developer-lastig zu sehen und von daher vom Support-Aufwand eher geringer einzuschätzen. Zumal das Standardverhalten von jsonlist2 ja nicht verändert wird.


Mit dem globalen Attribut legt der User fest, ob er die InternalValues im UI (FHEMWEB/telnet) "sehen" möchte oder nicht. Das will ich auch nicht ändern und dem User seine Entscheidung belassen.
Ich als "externer" Abrufer benötige nun aber für bestimmte Devices diese InternalValues zur weiteren Verarbeitung.
Aktuell müsste jetzt ich den User dazu "zwingen" die Anzeige einzuschalten. Um das extern nutzen zu können.

Das kann's aber m.E. erst recht nicht sein.

Übrigens auch für den Abruf der Raw-Definition wird das aktuell "übersteuert", weil da natürlich die InternalValues benötigt werden um einen konistenten Zustand eines Devices zu bekommen.

gb#

Edit: Genau genommen verändere ich nicht mal global schaltbares Verhalten. Ich verändere lediglich das Verhalten von jsonlist2. Dass jsonlist2 das globale Attribut berücksichtigt oder nicht ist "reine Willkür" von jsonlist2 selbst.
Global hat diese Änderung also null Auswirkung!

[betateilchen]

Ich als "externer" Abrufer benötige nun aber für bestimmte Devices diese InternalValues zur weiteren Verarbeitung.
Aktuell müsste jetzt ich den User dazu "zwingen" die Anzeige einzuschalten. Um das extern nutzen zu können.

Du könntest in Deiner Anwendung auch den aktuellen Status des globalen Attributes ermitteln, die Anzeige dann per Attributwert einschalten und nach Deinem Aufruf den vorherigen Zustand wiederherstellen.

[Benni]

Du könntest in Deiner Anwendung auch den aktuellen Status des globalen Attributes ermitteln, die Anzeige dann per Attributwert einschalten und nach Deinem Aufruf den vorherigen Zustand wiederherstellen.

Klar könnte ich das! Damit ändere ich aber die globale Einstellung des Users (Attribute gehören dem User habe ich da im Hinterkopf ), wenn auch nur temporär!
Was aber wenn der User genau in dem Zeitfenster eine Device-Detailseite aufruft und plötzlich von der Anzeige erschlagen wird?

Zugegeben, unwahrscheinlich und konstruiert, aber laut Murphy wir genau sowas passieren.

Und das supporte mal!

gb#
 

[betateilchen]

Damit ändere ich aber die globale Einstellung des Users (Attribute gehören dem User habe ich da im Hinterkopf)

Der User hat ein Verhalten per Attribut vorbestimmt und Du willst das ignorieren, auch wenn Du das als Schalter direkt beim Aufruf machst.

Grundsätzlich ein fragwürdiges Vorhaben. Aber deswegen ein fremdes Modul verändern, nur um Deinen Dickkopf durchzusetzen, kann auch nicht die Lösung sein. Du könntest auch die INTERNAL direkt aus dem device hash übernehmen und zum Ergebnis von jsonlist2 hinzufügen.

[Benni]

Der User hat ein Verhalten per Attribut vorbestimmt und Du willst das ignorieren, auch wenn Du das als Schalter direkt beim Aufruf machst.

Der User hat was anderes vorbestimmt, als das was ich möchte, nämlich, dass er die für ihn i.d.R. nutzlosen versteckten Internals (wohlbemerkt keine INTERNAL sondern die mit Punkt beginnenden versteckten Einstellungen) nicht sehen möchte, eben weil er im normalfall nix damit anfängt und anfangen sollte, von daher ist das Ausblenden auch die Voreinstellung. (So gesehen hat der User auch gar nix vorbestimmt, sondern hat es vorbestimmt bekommen.)

Ich möchte aber von "extern" ein möglichst vollständiges Abbild eines (oder mehrer) Devices aus FHEM bekommen, dazu bemühe ich jsonlist2, weil ich die Daten sowieso als json benötige. Der Aufruf von jsonlist2 erfolgt dabei aus einer komplett anderen Umgebung, per http/XHR-Aufruf an FHEM.

Du könntest auch die INTERNAL direkt aus dem device hash übernehmen und zum Ergebnis von jsonlist2 hinzufügen.

Ich habe von extern keinen Zugriff auf den Device-Hash, ich befinde mich dort nicht in Perl und u.U. nicht mal auf demselben Server.
Geanau deshalb hätte ich doch gerne den Device-Hash als json.
Ich kann also auch nichts aus dem Hash nehmen und zu jsonlist2 hinzufügen, sonst könnte ich mir ja gleich den Hash holen und damit arbeiten.

Grundsätzlich ein fragwürdiges Vorhaben. Aber deswegen ein fremdes Modul verändern, nur um Deinen Dickkopf durchzusetzen, kann auch nicht die Lösung sein.

Ich dachte, auch dazu könnte man dem jeweiligen Modul-Maintainer Patch-Vorschläte machen, um ggf. eine Funktionserweiterung oder Verbesserung herbeizuführen, die man selbst für einen bestimmten Zweck braucht.

Und ansonsten lese ich in deiner Argumentation "fragwürdig" und "gruselig", das sind für mich keine Argumente für oder gegen etwas. Das mit dem Dickkopf habe ich bei dir übrigens auch schon so erlebt.

gb#

[rudolfkoenig]

Die Steuerung für jsonlist2 ist, wenn ich es richtig sehe, aktuell nur über das global Attribut showInternalValues möglich.

Ja, genauso wie bei list, xmllist und FHEMWEB.

 

Ich möchte aber unabhängig vom global Attribut, direkt beim jsonlist2-Aufruf bestimmen können, ob ich die versteckten InternalValues im Ergebnis haben möchte oder nicht.

Warum will ein externes Programm die versteckten Daten unbemerkt an dem Benutzer vorbeischmuggeln?

[rudolfkoenig]

Geanau deshalb hätte ich doch gerne den Device-Hash als json.

{ toJSON($defs{DEVICE}) }

[Benni]

Warum will ein externes Programm die versteckten Daten unbemerkt an dem Benutzer vorbeischmuggeln?

Werden Sie doch sowieso schon in 99% der Fälle!

{ toJSON($defs{DEVICE}) }

Danke! funktioniert! Aber dann fehlen aber immer noch die Attribute.

Aber egal!
Ich ziehe meinen Patch-Vorschlag zurück!

gb#

[rudolfkoenig]

Das mag sein, aber meine Frage ist immer noch unbeantwortet.

[Benni]

Das mag sein, aber meine Frage ist immer noch unbeantwortet.

Das externe Programm (ein UI) speichert/cached in Dot-Readings auf FHEM-seite eigene Daten.