Neues Modul: expandJSON

[dev0]

Das expandJSON Modul dient dazu einen JSON String aus einem Reading in einzelne Readings zu konvertieren.
Ab morgen über das FHEM Update verfügbar.

Support Board: Unterstützende Dienste



expandJSON

  Expand a JSON string from a reading into individual readings

  Requirement: perl module JSON

  Define

    define <name> expandJSON <source_regex> [<target_regex>]

      <name>
      A name of your choice.

      <source_regex>
      Regexp that must match your devices, readings and values that contain
      the JSON strings. Regexp syntax is the same as used by notify and must not
      contain spaces.

      <target_regex>
      Optional: This regexp is used to determine whether the target reading is
      converted or not at all. If not set then all readings will be used. If set
      then only matching readings will be used. Regexp syntax is the same as
      used by notify and must not contain spaces.

Set

•     N/A
  

Get

•     N/A
  

Attributes

•     addReadingsPrefix
        Add source reading as prefix to new generated readings. Useful if you have
        more than one reading with a JSON string that should be converted.
  
  
•     do_not_notify
        Do not generate events for converted readings at all. Think twice before
        using this attribute. In most cases, it is more appropriate to use
        event-on-change-reading in target devices.
  
  
•     addStateEvent
  
•     disable
  
•     disabledForIntervals
  

[rudolfkoenig]

Und wozu kann man das benutzen?

[dev0]

Es wird genutzt um Sensordaten, die als JSON String in einem (MQTT/ESPEasy/TASMOTA) Device landen, in einzelne Readings zu zerlegen: https://wiki.fhem.de/wiki/Sonoff#MQTT_in_FHEM_einrichten

[betateilchen]

So langsam wird es hier in FHEM aber völlig absurd.

Da wird ein Modul gebaut, das als Anforderung hat:

Code Auswählen Erweitern


  Requirement: perl module JSON


Lebensaufgabe dieses zusätzlich benötigten Moduls ist es, JSON Strings zu verarbeiten.

Wofür um alles in der Welt braucht man dann noch ein extra FHEM Modul, um auf Methoden eines zusätzlichen perl-Moduls zuzugreifen? Dann kann ich doch auch die Methoden des perl Moduls selbst verwenden. Notfalls schreibt man sich einen 3-Zeiler in die 99_myUtils, um die Nutzung zu vereinfachen.

Irgendwann scheibt noch jemand ein FHEM-Modul, um FHEM zu benutzen...

[Thorsten Pferdekaemper]

Hi,
mir scheint hier eher MQTT das Problem zu sein. Anscheinend wird MQTT als irgendwie hilfreich in der Automatisierung angesehen und dadurch könnte man denken, dass man für Geräte, die MQTT sprechen, kein eigenes Modul mehr braucht. Dummerweise ist MQTT aber gar kein vollständiges Protokoll und man muss noch einen draufsetzen, um die verschiedenen Message-Formate zu dekodieren. Wäre das nicht MQTT sondern z.B. einfach TCP/IP, dann würde kaum jemand auf die Idee kommen, ein allgemeines TCP/IP-Modul zu schreiben und dann darauf irgendwelche Readings-Extraktions-Module zu setzen.
Meiner Meinung nach müsste es für Geräte, die MQTT sprechen, in der Regel auch echte eigene Module geben. Z.B. hier wäre das ein SONOFF-Modul, welches alles nötige enthält. Dann müsste man auch nicht drei Module für MQTT und nochmal eins für Json->Reading sowie einen MQTT-Broker bemühen.
Natürlich kann es sinnvoll sein, gemeinsame Sachen in eine eigene "Library" auszulagern, ähnlich wie HttpUtils.pm oder TcpServerUtils.pm.
Gruß,
   Thorsten

[betateilchen]

Natürlich kann es sinnvoll sein, gemeinsame Sachen in eine eigene "Library" auszulagern, ähnlich wie HttpUtils.pm oder TcpServerUtils.pm.

Unbestritten. Aber die Verarbeitung von JSON Daten ist originäre Aufgabe des perl Moduls JSON. Da muss man nicht krampfhaft noch einen Wrapper drumrumbauen.

[Thorsten Pferdekaemper]

Unbestritten. Aber die Verarbeitung von JSON Daten ist originäre Aufgabe des perl Moduls JSON. Da muss man nicht krampfhaft noch einen Wrapper drumrumbauen.

Darum ging's mir auch gar nicht...

[dev0]

Aber die Verarbeitung von JSON Daten ist originäre Aufgabe des perl Moduls JSON. Da muss man nicht krampfhaft noch einen Wrapper drumrumbauen.

Sehen andere Entwickler das auch so? Dann entferne ich das Modul natürlich wieder.

[Thorsten Pferdekaemper]

Hi,
also ich sehe es zumindest nicht so absolut (streng? verbissen?) wie Udo. Wenn man Json in Readings umwandeln will, dann ist das ja ein bisschen mehr als einfach nur JSON::XS::decode_json oder so. Man muss ja immer noch entscheiden, wie man z.B. verschachtelte Objekte auflösen will oder was man gar mit Arrays macht. Allerdings kann ich mir wieder vorstellen, dass auch das gerätespezifisch ist. Zumindest habe ich dazu noch keinen "Standard" gesehen.
Ich habe mir das Modul nicht angesehen. Ich weiß also nicht, wie viel es wirklich leistet. Ich denke aber, wie schon gesagt: Als richtiges Modul wahrscheinlich wirklich unnötig, aber als "Library" unter Umständen nützlich.

Daran könnte man jetzt eine weitere Diskussion anschließen: Was sollte man prinzipiell mit Funktionen tun, die man sozusagen als Standard für Modulentwickler (oder auch myUtils-Entwickler) anbieten will? Es gibt da ja schon ein paar Sachen wie HttpUtils und DevIo. Gibt es dazu so etwas wie ein normales FHEM-Vorgehen?

Gruß,
   Thorsten

[betateilchen]

Man muss ja immer noch entscheiden, wie man z.B. verschachtelte Objekte auflösen will oder was man gar mit Arrays macht. Allerdings kann ich mir wieder vorstellen, dass auch das gerätespezifisch ist.

Genau so ist es.

Und genau deshalb hat bisher jeder Modulentwickler, der in einem Modul mit JSON umgehen muss, entsprechende Funktionen in das Modul eingebaut, die dafür eine Standard-Library von perl verwenden. Es gibt inzwischen eine Vielzahl von FHEM-Modulen, die json verarbeiten. Wenn nun jeder Entwickler seine json-Funktionen in ein eigenes Modul auslagerte - na dann gute Nacht.

Immerhin ist ja inzwischen lib-json-perl als "erforderlich" für FHEM klassifiziert und wird bei der Installation des .deb Paketes auf Existenz geprüft. (Bei apt-get install fhem wird json automatisch mit installiert).

[betateilchen]

Sehen andere Entwickler das auch so? Dann entferne ich das Modul natürlich wieder.

Vorschlag: checke es doch in contrib ein. Dort habe ich auch schon das eine oder andere Modul "deponiert", das ich als Entwickler anfangs für notwendig/gut/brauchbar hielt und dann doch zu einer anderen Erkenntnis kam.

[dev0]

Wenn man Json in Readings umwandeln will, dann ist das ja ein bisschen mehr als einfach nur JSON::XS::decode_json oder so. Man muss ja immer noch entscheiden, wie man z.B. verschachtelte Objekte auflösen will oder was man gar mit Arrays macht.
...
Ich habe mir das Modul nicht angesehen.

Schade, dass Du Dir das Modul nicht angesehen hast, denn dann hättest Du gesehen, dass verschachtelte Objekte und Array bereits verarbeitet werden. Wobei ich leider sagen muss, dass mir gerade noch ein Fehler in der Arrayverarbeitung aufgefallen ist, der dazu führt, dass Arrays im Moment nicht in Readings geschrieben werden.
Ob ich den Fix aber überhaupt noch einchecke oder das Modul aus dem Repo entferne mache ich davon abhängig, ob sich noch ein weiterer Entwickler hier meldet, der das Modul, wie Betateilchen, für einen Witz hält.

Vorschlag: checke es doch in contrib ein

Solange contrib nicht über das FHEM Update verteilt wird, ist das für mich keine Alternative. Dann ist es, wie bisher, auf Github besser aufgehoben.

[betateilchen]

Ob ich den Fix aber überhaupt noch einchecke oder das Modul aus dem Repo entferne mache ich davon abhängig, ob sich noch ein weiterer Entwickler hier meldet, der das Modul, wie Betateilchen, für einen Witz hält.

Nur um das klarzustellen: ich halte das Modul nicht für einen Witz, sondern schlicht für eine Verteilung per main-Update ungeeignet, da wenig nützlich und nicht überall verwendbar, wo es tatsächlich darum geht, mit JSON Daten zu arbeiten.

Solange contrib nicht über das FHEM Update verteilt wird, ist das für mich keine Alternative.

Da z.B. bei mir ein FHEM update per cmdalias direkt aus SVN erfolgt, hat das den Vorteil, dass auch contrib mit aktualisiert wird. Dafür kann ich dann github nicht nutzen. Aber ich muss/will eben auch nicht mehrere Quellen anzapfen, um ein "vollständiges" FHEM zu haben.

Für mich macht die in letzter Zeit um sich greifende Unsitte, immer mehr Teile in externe repositories zu verlagern, auf Dauer wenig Sinn.

(Genau so wenig Sinn wie die steigende Anzahl von Blogs ausserhalb von FHEM, auf die dann von ihren Erstellern hier im Forum immer wieder verlinkt wird. Aber das ist ein anderes Thema.)

[Thorsten Pferdekaemper]

Schade, dass Du Dir das Modul nicht angesehen hast,

Das wollte ich jetzt nachholen, aber ich habe es nicht gefunden. Wo finde ich es denn?

denn dann hättest Du gesehen, dass verschachtelte Objekte und Array bereits verarbeitet werden.

Wie geht denn das auf eine allgemein sinnvolle Weise? Ich habe das so gelöst, dass ich bei Arrays einfach wieder in JSON gewandelt habe. Array-Elemente in Reading-Namen nummerieren bringt's ja auch nicht gerade.

der das Modul, wie Betateilchen, für einen Witz hält.

Wie schon gesagt: Ich halte es als Library oder so für möglicherweise sinnvoll, aber nicht unbedingt als Modul.

Für mich macht die in letzter Zeit um sich greifende Unsitte, immer mehr Teile in externe repositories zu verlagern, auf Dauer wenig Sinn.

Dazu muss ich als Git-Modul-Autor jetzt auch noch etwas sagen...
Ich wollte den HM485-Kram schon ins FHEM-SVN bringen, aber Rudi waren es zu viele Dateien. Da ich das ganze aber nicht sinnvoll in eine Datei pro Modul stopfen kann habe ich es bleiben lassen. Inzwischen bin ich ganz froh darüber, da ich dadurch zumindest mal nichts kaputt machen kann.
Das "Zerlegen" von FHEM ist meiner Meinung nach auch gar nicht so unsinnig, da man dann tatsächlich nur das installieren muss, was man auch braucht. Ich finde sogar, dass das in Zukunft der Normalfall sein sollte und nicht die Ausnahme. Außerdem würde sich dann auch die Diskussion "SVN oder Git" erübrigen.
...und die zwei bis drei Leute, die für ein update nicht "update" verwenden, sind bestimmt so versiert, dass sie sich den Kram auch von github ziehen können, wenn es denn sein muss.
Gruß,
   Thorsten

[betateilchen]

Das "Zerlegen" von FHEM ist meiner Meinung nach auch gar nicht so unsinnig, da man dann tatsächlich nur das installieren muss, was man auch braucht. Ich finde sogar, dass das in Zukunft der Normalfall sein sollte und nicht die Ausnahme. Außerdem würde sich dann auch die Diskussion "SVN oder Git" erübrigen.

Die Probleme, die sich daraus in Folge ergeben, sind schon jetzt in mehreren Problem-Threads nachzulesen.

[Thorsten Pferdekaemper]

Die Probleme, die sich daraus in Folge ergeben, sind schon jetzt in mehreren Problem-Threads nachzulesen.

Aha. Ich kann mich zumindest für HM485 an keinen erinnern, zumindest seit ich das per "update add..." mache. Kannst Du mal einen solchen Thread zeigen?
Gruß,
   Thorsten

[dev0]

Das wollte ich jetzt nachholen, aber ich habe es nicht gefunden. Wo finde ich es denn?

Das Modul ist zZ. ganz normal eingecheckt: Nach einem Update im ./FHEM Ordner
Die korrigierte Version, die ich noch nicht eingecheckt habe findest Du hier: https://github.com/ddtlabs/expandJSON/

dass ich bei Arrays einfach wieder in JSON gewandelt habe. Array-Elemente in Reading-Namen nummerieren bringt's ja auch nicht gerade.

Ich bin tatsächlich den Weg gegangen und nummeriere bei Arrays durch, etwas besseres ist mir bisher noch nicht eingefallen. Allerdings ist dieser Fall bei den bisherigen Sesoren auch nicht aufgetreten. In Objekten ist es ja eindeutig.

Für mich macht die in letzter Zeit um sich greifende Unsitte, immer mehr Teile in externe repositories zu verlagern, auf Dauer wenig Sinn.

Bitte dieses Thema in einem eigenen Thread diskutieren.

[Thorsten Pferdekaemper]

Das Modul ist zZ. ganz normal eingecheckt: Nach einem Update im ./FHEM Ordner

Ah, jetzt hab ichs auch gefunden...

Ich bin tatsächlich den Weg gegangen und nummeriere bei Arrays durch, etwas besseres ist mir bisher noch nicht eingefallen. Allerdings ist dieser Fall bei den bisherigen Sesoren auch nicht aufgetreten. In Objekten ist es ja eindeutig.

Naja, bei meinem Staubsauger habe ich das ganze schon etwas verschachtelt, da würde es schon etwas hässlich werden. Ich denke immer noch, dass man das ganze gerätespezifisch lösen sollte.
Gruß,
   Thorsten

[dev0]

Ich denke immer noch, dass man das ganze gerätespezifisch lösen sollte.

Das sehe ich auch so und mache es zB. im ESPEasy Modul auch so.

Ich würde es auch begrüßen, wenn die Funktion zB. auch in die MQTT/KeyValue/... einfließen würde, wenn die erhaltenen Werte in dem Modul weiterverwarbeitet werden. Dann macht das mMn Sinn. Das weiß man aber eben nicht, wie bei average und dem statistics Modul auch, um Beispiele zu nennen. Aber ist zB. ein average oder statistics Modul deshalb überflüssig? Die Funktion könnte man auch in jedes x-beliebige Modul implementieren.

[Thorsten Pferdekaemper]

Ich würde es auch begrüßen, wenn die Funktion zB. auch in die MQTT/KeyValue/... einfließen würde, wenn die erhaltenen Werte in dem Modul weiterverwarbeitet werden.

Ich weiß zwar nicht genau, was Du meinst, aber wenn Du das bei den MQTT-Modulen mit einbauen willst, dann fände ich das wiederum nicht so gut. MQTT macht ja keine Aussage darüber, wie die Payload aussieht. Natürlich könnten wir da auch einen FHEM-Standard schaffen, aber das dürfte man dann nicht MQTT nennen, sondern vielleicht ESPdev0...

Dann macht das mMn Sinn. Das weiß man aber eben nicht, wie bei average und dem statistics Modul auch, um Beispiele zu nennen. Aber ist zB. ein average oder statistics Modul deshalb überflüssig? Die Funktion könnte man auch in jedes x-beliebige Modul implementieren.

Da hast Du schon irgendwie Recht, aber diese Hilfsmodule, die anderen Modulen Readings verpassen gefallen mir nicht ganz so gut. Ich fände es besser, wenn man eine Art Library hätte, die man im Gerät selbst aufrufen kann. Das wäre meiner Meinung nach klarer strukturiert.

Gruß,
   Thorsten