JSON Problem

Begonnen von Barit, 18 September 2017, 20:49:37

Vorheriges Thema - Nächstes Thema

Barit

Ohne einen Doppelpost aufmachen zu wollen. Aber ich denke das Problem hier: https://forum.fhem.de/index.php/topic,71968.msg687468.html#msg687468
könnte auch andere Module betreffen. Hat sonst wer Erfahrung/Probleme mit den Modulen  bzw JSON?

justme1968

es gibt schon zwei oder drei threads zu diesem problem. es scheint weder mit dem hue noch mit dem hmccu modul direkt zu tun zu haben. es ist auch direkt mit {decode_json(...)} auf der kommandozeile reproduzierbar.

in mindestens zwei fällen hat es geholfen von von debian auf ubuntu zu wechseln. ich tippe also auf ein problem der mitgelieferten perl version oder der json lib.

da ich das problem bei mir nicht reproduzieren kann habe ich aktuell leider keine bessere idee.

vielleicht hilft auch das perl-json paket zu deinstallieren und per cpan zu installieren.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Barit

Ich konnte das Problem erstmal lösen.  Anscheinend hat sich beim JSON-decode Aufruf etwas geändert. Hier mal die Beschreibung auf cpan.org die mir die richtige Richtung gezeigt hat:
Zitatallow_nonref
$json = $json->allow_nonref([$enable])
If $enable is true (or missing), then the "encode" method can convert a non-reference into its corresponding string, number or null JSON value, which is an extension to RFC4627 . Likewise, "decode" will accept those JSON values instead of croaking.

Ich habe dann die Zeile in der der Fehler geworfen wurde nach o.g. Schema geändert. Hier mal am Bespiel des Moduls 70_Pushover.pm:
Zeile 540
540             $return = decode_json( Encode::encode_utf8($data) )
541               if ( !$@ );


wurde geändert in:

540             my $json = JSON->new->allow_nonref;
541             $return = $json->decode(Encode::encode_utf8($data))
542               if ( !$@ );


Ich werde das bei den übrigen Modulen jetzt auch nochmal testen.

Sinnvoll wäre nätürlich wenn der Modul-"Betreuer" die Änderung zentral einpflegen könnte, ansonsten sind beim nächsten Update meine Anpassungen futsch. Weiß jemand wer für die Module verantwortlich ist? Probleme machen bisher die Module
und wahrscheinlich alle weiteren Module die JSON ohne "allow_nonref" verwenden.

JoWiemann

#3
Hallo, die Modulseelsorger sind in der Maintainer.txt hinterlegt. Schau mal im Repository nach.



Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Barit

Alles klar, danke für den Hinweis. Habe den Modulentwickler mal angeschrieben.

Anscheinend gibt es noch einen weitere Lösungsvorschläge für das JSON-Problem: https://forum.fhem.de/index.php/topic,76744.msg686584.html#msg686584
Es könnte wohl auch mit dem Thema HMCCU und RPC Server zusammen hängen. Zumindest habe ich die gleiche Konfiguration.

Das ein Modul Fhem komplett zum Absturz bringt sollte ja eigentlich verhindert werden. Dazu gab es auch schonmal ein Thema das sich mit dem JSON-decode-Problem beschäftigt hat und einen Lösungsvorschlag aufgeschrieben hat: https://forum.fhem.de/index.php/topic,71737.msg632691.html#msg632691

CoolTux

Bitte bedenke das einige Module bei weitem älter sind wie dieser Lösungsvorschlag, der wirklich gut und richtig ist, und daher nicht nachgepflegt sind. Ich könnte beobachten das einige neuere Module bereits die JSON Funktionen in einem eval aufrufen.
Wenn es akut Probleme gibt dann einfach den Maintainer anschreiben (hast Du ja gemacht).



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

dev0

Auch wenn der gezeigte Workaround funktioniert, bin ich mir noch nicht sicher, ob das der richtige Weg ist. Sinnvoller wäre es mAn die Ursache zu finden, das können aber nur die betroffenen Anwender leisten. Es wird auch nicht nur FHEM betroffen sein...
Wie man in dem oben verlinkten Thread auch sieht, hat eine Neuinstallation von Debian Stretch, statt eines Updates, geholfen das Problem zu beseitigen. Bei anderen tritt das Problem wohl auch mit Jessie auf. Aber alles nur sehr sehr vereinzelt.

CoolTux

Das eigentliche Problem ist nicht das aktuelle, sondern das das JSON Perl Modul sagen wir es vorsichtig mit der heißen Nadel gestrickt ist und bei der kleinsten Inkonsistents abstürzt. Somit verabschiedet sich dann auch FHEM.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

dev0

Zitat von: CoolTux am 20 September 2017, 11:03:54
mit der heißen Nadel gestrickt ist und bei der kleinsten Inkonsistents abstürzt
Woran meinst Du das zu erkennen? "Abstürzen heißt "die" aufzurufen?

CoolTux

Sobald Du einen fehlerhaften JSON String an die decode_json übergibst, übergibt sich die Funktion  ;D
Leidvolle Erfahrung. Lass Mal ne Klammer weg oder Gib Mal ein Zeichen ausserhalb des JSON String mit.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

dev0

Zitatübergibt sich die Funktion
"Übergibt" heiss also, dass "die" aufgerufen wird. Das ist normal und machen viele Perl Module und muss deshalb in FHEM mit einem eval abgefangen werden. Hat aber nichts mit dem Problem des Threads zu tun.

CoolTux

Nein es war ein Wortspiel, sorry. Es bedeutet daß sie mit einem Fehler aussteigt und somit keinen sauberen Rückgabewert liefert. Sie stützt ab, könnte man sagen.
Und ja, es hat nicht ganz etwas mit dem hier beschriebenen Problem zu tun, aber es sollte zeigen daß die JSON Routinen unsauber arbeiten und anfällig sind.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

dev0

Zitat von: CoolTux am 20 September 2017, 11:57:55
unsauber arbeiten und anfällig sind.
Das sehe ich nicht so, man sollte es "security feature" nennen. Ernst gemeinst.
Aber lass uns beim lieber beim Thema bleiben, das wird langsam offtopic.

Barit

Nochmal zum Thema: Scheinbar liegt's doch am externen RPC-Server des HMCCU-Moduls:
Das hier hat zumindest bei mir geholfen:
https://forum.fhem.de/index.php/topic,76744.msg686584.html#msg686584

MarkBinary

Ich habe in den letzten Tagen eine andere Strategie verfolgt.


  • Jessie update --> kein erfolg
  • Komplettes CPAN update --> kein erfolg
  • HMCCURPC stoppen und den RPCSERVER im Modul HMCCU auf intern stellen reichte bei mir nicht.
Erst das löschen des devices HMCCURPC und neustarten des Raspberry halfen.

Nun laufen meine restlichen Module wieder.
Betroffen waren https://forum.fhem.de/index.php/topic,71968.msg687729.html#msg687729:
34_ESPEasy.pm
77_UWZ.pm
98_TRAFFIC.pm

Ich weiß leider nicht, wie man die threads zum Thema JSON, HMCCURPC,HUEBridge bündeln kann.
https://forum.fhem.de/index.php/topic,71968.0.html
https://forum.fhem.de/index.php/topic,76744.0.html
https://forum.fhem.de/index.php/topic,76842.0.html
https://forum.fhem.de/index.php/topic,74943.0.html
https://forum.fhem.de/index.php/topic,71737.0.html

dev0

Ist das Problem denn schon mal bei jemanden aufgetreten, der _nicht_ das HMCCURPC Modul nutzt oder ist der vermeintliche Verursacher damit gefunden?

rudolfkoenig

ZitatEs bedeutet daß sie mit einem Fehler aussteigt und somit keinen sauberen Rückgabewert liefert. Sie stützt ab, könnte man sagen.
Das ist eine Philosophie-Frage, und kein Fehler. die() im perl kann man mit throw() in Java vergeleichen, d.h. es wird ein Exception generiert. In Java ist ein Exception mit catch, in perl mit eval abzufangen. Ob das guter oder schlechter Programmierstil ist, darueber kann man stundenlang streiten. Ich bin auf der Seite der "Rueckgabewert statt Exception" Verfechter, weil ich in Java-Umfeld haeufig sehe, dass die Exceptions nur sehr weit entfernt vom Problem abgefangen werden, wo man nicht mehr in der Lage ist, eine richtige Fehlermeldung zu generieren. Im Log sieht man dann neben der Meldung "No such file or directory" den kompletten Callstack, aber man weiss nicht, welche Datei nun fehlt. Man _kann_ auch mit Exceptions sauber programmieren, passiert nur meiner Erfahrung nach seltener. Wie man das in unserem Beispiel auch sieht.