Hi
folgendes Problem tritt bei mir auf. Sobald ich die den externen RPC laufen habe, ist es mir nicht mehr möglich JSON befehle abzugeben, bzw kommen nur Fehlermeldungen raus. Somit ist HUEBridge nicht funktionsfähig. Den Server deaktivieren und FHEM neustarten hilft dabei. Mit dem internen Server läuft es ohne Probleme. Das geht soweit, dass FHEM nicht mehr startet, nach einem Reboot.
Im hatte mich an den HUEBridge Fred zuerst gewendet (danke an justme1968).
Fhem Eingabe in die Kommandozeile ohne externen RPC:
{ decode_json( '{"name":"Philips hue","datastoreversion":"59","swversion":"01036659","apiversion":"1.16.0","mac":"00:17:88:21:72:ff","bridgeid":"001788FFFE2172FF","factorynew":false,"replacesbridgeid":null,"modelid":"BSB002"}' ) }
HASH(0x559f618707e8)
FHEM Eingabe in die Kommandozeile mit externen RPC:
JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at (eval 565) line 1.
System ist auch dem neustem Stand.
Gruß
Martin
Kann ich nicht nachvollziehen. Habe ebenfalls HMCCURPC und HUEBridge laufen. Die decode_json Funktion liefert bei mir einen Hash zurück. HMCCURPC nutzt kein JSON.
Gibt es weitere Fehlermeldungen im FHEM Log (wenn FHEM nicht startet)?
Welches System verwendest Du (Linux Distri?)
Bei mir läuft Debian 9. Ich habe das System heute morgen komplett neu aufgesetzt, wegen dem genanntem Problem. War aber kein Unterschied zu vermerken.
Mein Gedanke war, das RPC vielleicht etwas blockiert, aber das scheint mit deiner Aussage definitiv nicht so zu sein.
Beim Starten von FHEM war der letzte Eintrag:
hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at ./FHEM/30_HUEBridge.pm line 1039.
Lässt man den externen HMCCURPC nicht automatisch mitstarten, läuft FHEM durch. Entfernt man das Modul HUEBridge geht es logischer weise auch.
Schon merkwürdig
Dann schauen wir uns mal Zeile 1039 in Huebridge.pm an ....
Die Funktion encode_json schlägt fehl, weil der übergebene Parameter keine Referenz auf einen Hash oder ein Array ist.
In Zeile 1036 von 30_HUEBridge.pm ist eine Logzeile auskommentiert. Mach mal den Kommentar raus. Dann dürften beim Start von FHEM mehr Meldungen kommen , v.a. Ein Dump des fraglichen Parameters. Verbose musst du auf 5 stellen oder du ersetzt die 5 in der Zeile durch Dein eingestelltes Loglevel.
doch ist es. jedenfalls normalerweise wenn das decode vorher funktioniert. zeile 1039 ist glaube ich nur ein folgefehler.
das problem das es hier gibt kann man ganz ohne huebridge nachstellen wenn man das decode auf der fhem kommandozeile probiert.
kann es sein das das json modul auf zwei inkompatible arten eingebunden wird?
Ja das könnte sein, allerdings nicht von HMCCURPC. Ich benutze kein JSON.
Efkape sollte mal prüfen, ob er weitere Module verwendet, die JSON einbinden.
Trotzdem wäre es vielleicht gut zu wissen, ob $obj in dem Fall nicht doch ein Skalar ist.
Wie gesagt, ich habe neben HMCCU auch HUEBridge und keine Probleme. Allerdings auch keine weiteren Module mit JSON.
HMCCURPC startet mehrere Threads um RPC Calls der CCU zu bedienen. Thats all
2017.08.02 07:04:43 1: HMCCURPC: Received IN event. RPC server CB2010 running.
2017.08.02 07:04:43 1: HMCCURPC: All RPC servers running
2017.08.02 07:04:43 1: PERL WARNING: Argument "" isn't numeric in numeric eq (==) at (eval 398) line 1.
2017.08.02 07:04:43 3: eval: do_EG_K_Beleuchtung: warning in condition c01
2017.08.02 07:04:43 3: LED_Kitchen RGBW LD382A dim 0 0.5
2017.08.02 07:04:43 3: LED_Kitchen set HSV 50, 50, 0 with ramp: 0.5, flags:
2017.08.02 07:04:43 3: Sending: {
'on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' )
}
hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at ./FHEM/30_HUEBridge.pm line 1039.
Das sind die letzten Lebenszeichen. Danach ist ein neustart fällig und ich muss den externen RPC in der fhemconfig eleminieren bevor ich neustarten kann. Die Perl warnung war ein Fehler meiner seits.
Beim starten wird wohl eine Lampe geschaltet. Das ist zumindest der Fehler, warum FHEM sich dabei aufhängt. Da der RPC erst später gestartet wird, holt HUEBridge sich vorher auch alle Daten aus den Devices und Groups.
z.B:
2017.08.02 07:04:30 4: using HUEBridge_HTTP_Request: GET lights
2017.08.02 07:04:30 5: HUEBridge: id '5' already defined as 'HUEDevice5'
2017.08.02 07:04:30 5: HUEBridge: id '6' already defined as 'HUEDevice6'
2017.08.02 07:04:30 5: HUEBridge: id '2' already defined as 'HUEDevice2'
2017.08.02 07:04:30 5: HUEBridge: id '7' already defined as 'HUEDevice7'
2017.08.02 07:04:30 5: HUEBridge: id '4' already defined as 'HUEDevice4'
2017.08.02 07:04:30 5: HUEBridge: id '3' already defined as 'HUEDevice3'
2017.08.02 07:04:30 5: HUEBridge: id '8' already defined as 'HUEDevice8'
2017.08.02 07:04:30 5: HUEBridge: id '1' already defined as 'HUEDevice1'
2017.08.02 07:04:30 3: Sending: undef
Andere Module mit JSON sind nicht vorhanden.
kannst du mal die reihenfolge vertauschen? also erst rpc starten und dann die hue bridge definieren. zur not von hand.
Das scheint ja in Folge der LED zu passieren. Ein ld382 ist wifilight. Verwendet aber ebenfalls kein json und auch keine hue Bridge?
Ich habe jetzt einmal Ubuntu (Server Variante) ausprobiert. Und siehe da... Keine Probleme mehr. Habe sogar das Backup eingespielt, damit es gut übertragbar ist.
Ich probiere es aber gleich noch einmal mit Debian aus und vertausche die Reihenfolge.
@herrmannj
Die LED Beleuchtung ist es soweit ich das überblicken kann nicht.
Sending: {'on' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' )
wäre der nächste Befehl in der Reihe, welcher eine Osramleuchte über HUE steuern sollte. Dabei geschieht das Unglück.
Edit:
Habe es jetzt nochmal mit Debian 9.1 probiert und dabei kommt das gleiche Ergebnis bei raus.
Distri installiert und nur fhem nach wiki (https://debian.fhem.de/) und hmmcu(https://wiki.fhem.de/wiki/HMCCU) installiert. Mehr läuft auf dem System nicht.
Also scheint es mit der Linux Installation zusammen zu hängen?
Man kann den RPC Server von HMCCU nicht später starten. Der startet als Reaktion auf ein globales Event FHEM initialized.
Das liegt in meinen Augen eindeutig an Debian. Unter Ubuntu habe ich das nicht, obwohl ich alles extakt gleich konfiguriert habe
Ich bleibe erst einmal bei Ubuntu. Da ich mich gerade in das Thema Linux einarbeite, bin ich völlig frei, welche Distribution ich letztendlich verwende.
Auch wenn jetzt kein abschließendes Ergebnis zustande gekommen ist, danke ich euch für die Unterstützung!
Gruß
Martin
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 (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,71968.0.html)
https://forum.fhem.de/index.php/topic,76744.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,76842.0.html)
https://forum.fhem.de/index.php/topic,74943.0.html (https://forum.fhem.de/index.php/topic,74943.0.html)
https://forum.fhem.de/index.php/topic,71737.0.html (https://forum.fhem.de/index.php/topic,71737.0.html)
Habe leider das gleiche Problem und keine Ahnung wie ich das lösen kann :(
Bin FHEM Neuling, und habe zuerst das HUE Modul installiert was einwandrei funktioniert.
Danach habe ich das Modul HMCCU installiert was für sich selbst auch einwandfrei funktioniert, aber offensichtlich nicht im Zusammenspiel
Wenn ich für das Device d_ccu das "rpcserver" attribut auf ON stelle, also den externen RPC Server automatisch starten lassen, funzt HUE nicht mehr und wirft sie JSON Fehlermeldungen im Log.
Den RPC Server stoppen bringt dann auch nichts, nur den kompletten raspberry neu zu starten ohne aktiven RPC Server.
JSON Fehlermeldungen:
2017.10.02 15:07:55 2 : HueBridge1: json error: JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at ./FHEM/30_HUEBridge.pm line 1112. in {"state":{"temperature":2206,"lastupdated":"2017-10-02T13:05:55"},"swupdate":{"state":"noupdates","lastinstall":null},"config":{"on":true,"battery":100,"reachable":true,"alert":"none","ledindication":false,"usertest":false,"pending":[]},"name":"Hue temperature sensor 1","type":"ZLLTemperature","modelid":"SML001","manufacturername":"Philips","swversion":"6.1.0.18912","uniqueid":"00:17:88:01:02:00:fd:47-02-0402"}
2017.10.02 15:07:55 3 : HUEBridge_Call: failed, retrying
2017.10.02 15:07:55 2 : HueBridge1: json error: JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at ./FHEM/30_HUEBridge.pm line 1112. in {"state":{"temperature":2206,"lastupdated":"2017-10-02T13:05:55"},"swupdate":{"state":"noupdates","lastinstall":null},"config":{"on":true,"battery":100,"reachable":true,"alert":"none","ledindication":false,"usertest":false,"pending":[]},"name":"Hue temperature sensor 1","type":"ZLLTemperature","modelid":"SML001","manufacturername":"Philips","swversion":"6.1.0.18912","uniqueid":"00:17:88:01:02:00:fd:47-02-0402"}
2017.10.02 15:07:55 3 : HUEBridge_Call: failed, retrying
2017.10.02 15:07:55 3 : HUEBridge_Call: failed
Frage: welche Netzwerk Ports verwendet HUE Bridge?
@jochenj: es hat nichts mit dem problem zu tun, aber die zeilen der fehlermeldungen passen nicht zur aktuellen HUEBridge modul version. d.h. du hast kein update gemacht.
@zap: die hue bridge selber lauscht auf port 80 wie ein normaler web server.
aber warum sollte das relevant sein?
zum eigentlichen problem: ich verstehe immer noch nicht was hier schief geht. die meldung besagt ja das decode_json einen object oder ein array erwartet. das ist aber doch blödsinn. decode_json bekommt einen string übergeben und macht daraus einen hash.
da ich es mangels ccu nicht selber testen kann tippe ich auf irgendein thread problem mit bestimmten perl versionen. eventuell wenn die perl version selber keine threads kann? fhem ist im übrigen auch nicht thread safe.
Zitat von: justme1968 am 02 Oktober 2017, 18:31:51
@zap: die hue bridge selber lauscht auf port 80 wie ein normaler web server.
Irgendein Portkonflikt ... aber in dem Fall nicht. Alles nur Strohhalme, da das Problem nicht bei jedem auftritt.
Zitat
da ich es mangels ccu nicht selber testen kann tippe ich auf irgendein thread problem mit bestimmten perl versionen. eventuell wenn die perl version selber keine threads kann? fhem ist im übrigen auch nicht thread safe.
Kann sein. Was dagegen spricht: Das Problem haben auch Leute, die gar kein HMCCU einsetzen. Möglicherweise nutzen die aber SONOS, das auch Threads verwendet. Ich nutze HMCCU, HUEBridge und SONOS ohne Probleme.
Die Thread-Funktionen in HMCCURPC sind "vorsichtig" programmiert. Soll heißen, ich verwende dort nur eigenen Code ohne Bezug zu FHEM. Lediglich in Read() werden die Shared-Memory Queues ausgelesen.
Aber vielleicht ist es ja ein Shared-Memory Problem. Vielleicht werden irgendwelche Speicherbereiche überschrieben, sodass sich die Module in die Haare bekommen.
Ggf. sollte man also mal eine andere Version von Thread::Queue verwenden (CPAN oder das fertige Linux-Paket, je nachdem, was nicht funkioniert). Es ist ja auch nicht so, dass Threads in Perl was völlig neues sind, genauso wie Shared Memory Queues. Möglicherweise sind nur neuere Linux / Perl Versionen betroffen. Habe aber gerade weder Zeit noch Nerven, mein System upzudaten.
Seltsam ist, dass das decode-Problem in den Modulen dann behoben zu sein scheint wenn man bei JSON das "allow_nonref"-Attribut setzt. Ich hatte das mal hier beschrieben:
https://forum.fhem.de/index.php/topic,76842.msg687580.html#msg687580
Warum das allerdings abhängig von der Verwendung des RPC-Servers ist, ist mir auch unklar.
Außer Module zu aktualisieren habe ich keine Idee mehr.
@justme1968: Weist Du, wann im JSON Modul allow_nonref eingeführt wurde? Es scheint zu helfen, wenn man da enabled.
Weiß aber nicht, ob das nur die Symptome oder die Ursache behebt. Wäre auch ein ziemlicher Aufwand, das bei allen Modulen zu ändern, die JSON verwenden.
ich habe keine idee was hier schief läuft. zumal die perl doku zu decode_json explizit sagt das ein string erwartet wird.
Habe überlegt, einen neuen Thread zu starten. Da es aber so viele gibt zu dem Thema, nehme ich jetzt einfach mal den hier.
@justme1986: Schau Dir bitte mal die Doku zu JSON::XS an. Verstehst Du das auch so wie ich? (s. Auszug unten).
Ich habe nun einen neuen Raspi mit Debian Stretch aufgesetzt. Die JSON Fehlermeldung kann ich nachvollziehen, d.h. sie tritt bei mir auch auf. Der Fehler kommt bei der nächsten HUEBridge-Interaktion, die JSON nutzt (decode). Aber nur dann, wenn der externe RPC-Server von HMCCURPC läuft, d.h. die Threads gestartet sind. Die Definition des Device HMCCURPC alleine führt zu keinem JSON Fehler.
Soweit so gut bzw. schlecht.
Die Fehlermeldung lautet konkret:
"json error: JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at ./FHEM/30_HUEBridge.pm line 1122."
JSON beschwert sich also, dass an decode_json() ein String übergeben wurde. Das könnte in Zusammenhang mit JSON::XS stehen, das zur Beschleunigung der Dekodierung verwendet wird, sofern es vorhanden ist. Bei diesem Modul wurde aus Sicherheitsgründen das Verhalten geändert. Es muss nun explizit allow_nonref eingeschaltet werden, damit man an decode_json einen String übergeben kann. Warum der Fehler nur auftritt, wenn die Threads von HMCCURPC gestartet werden kann ich nur vermuten. Vielleicht wird in dem Moment die XS.so Shared Library nachgeladen und ab diesem Zeitpunkt von JSON verwendet.
Workaround: Man muss also verhindern, dass JSON zur Beschleunigung JSON::XS verwendet. Am einfachsten erreicht man das, indem man das Paket deinstalliert:
dpkg --purge libjson-xs-perl
Danach tritt der Fehler nicht mehr auf :)
Alternative ist, dass alle Modulautoren ihre Module mit JSON anpassen und allow_nonref einschalten. Das wäre mittelfristig die besserer Lösung. Irgendwann wird das Problem auch ohne HMCCURPC auftauchen.
Im Beispiel zu JSON::XS auf CPAN:
use JSON::XS;
# exported functions, they croak on error
# and expect/generate UTF-8
$utf8_encoded_json_text = encode_json $perl_hash_or_arrayref;
$perl_hash_or_arrayref = decode_json $utf8_encoded_json_text;
# OO-interface
$coder = JSON::XS->new->ascii->pretty->allow_nonref;
$pretty_printed_unencoded = $coder->encode ($perl_scalar);
$perl_scalar = $coder->decode ($unicode_json_text);
# Note that JSON version 2.0 and above will automatically use JSON::XS
# if available, at virtually no speed overhead either, so you should
# be able to just:
use JSON;
Im Nicht-OO Interface scheint man weiterhin einen String übergeben zu können. Im OO-Interface muss man allow_nonref einschalten.
Hier der Auszug aus der Doku von JSON::XS:
"OLD" VS. "NEW" JSON (RFC 4627 VS. RFC 7159)
Due to security concerns, JSON::XS will not allow scalar data in JSON texts by default - you need to create your own JSON::XS object and enable allow_nonref:
my $json = JSON::XS->new->allow_nonref;
$text = $json->encode ($data);
$data = $json->decode ($text);
The long version: JSON being an important and supposedly stable format, the IETF standardised it as RFC 4627 in 2006. Unfortunately, the inventor of JSON, Dougles Crockford, unilaterally changed the definition of JSON in javascript. Rather than create a fork, the IETF decided to standardise the new syntax (apparently, so Iw as told, without finding it very amusing).
The biggest difference between thed original JSON and the new JSON is that the new JSON supports scalars (anything other than arrays and objects) at the toplevel of a JSON text. While this is strictly backwards compatible to older versions, it breaks a number of protocols that relied on sending JSON back-to-back, and is a minor security concern.
For example, imagine you have two banks communicating, and on one side, trhe JSON coder gets upgraded. Two messages, such as 10 and 1000 might then be confused to mean 101000, something that couldn't happen in the original JSON, because niether of these messages would be valid JSON.
If one side accepts these messages, then an upgrade in the coder on either side could result in this becoming exploitable.
This module has always allowed these messages as an optional extension, by default disabled. The security concerns are the reason why the default is still disabled, but future versions might/will likely upgrade to the newer RFC as default format, so you are advised to check your implementation and/or override the default with ->allow_nonref (0) to ensure that future versions are safe.
ich hab an der Diagnose Zweifel.
non_ref beschäftigt sich mit der Tatsache das JSON streams, Toplevel, nicht aus Objekten oder Arrays bestehen müssen: supports scalars (anything other than arrays and objects) at the toplevel of a JSON text.
Meine vermute wäre eher das JSON::XS nicht thread sicher ist.
Die Umstellung aller Module oder die De-installation des XS (auf Verdacht) ist in meinen Augen kein guter Weg.
Hast Du mal versucht JSON::PP als Alternative zu verwenden (ab 5.14 core modul) ?
Dazu reicht es im head das "use JSON ;" bzw "use JSON::XS;" durch ein "use JSON:PP" zu ersetzen. Die meiden sind weitestgehend kompatibel und das PP steht für "pure perl".
vg
joerg
ich glaube der text bezieht sich nicht darauf ob ein perl string oder perl hash/array übergeben wird sondern das die json daten auf oberster ebene keinen skala enthalten dürfen. das tun sie im hue beispiel auch nicht.
um das problem einkreisen ist es eigentlich garnicht schlecht JSON::XS mal zu deinstallieren.
eigentlich soll man ja PP oder XS garnicht direkt selber einbinden sondern nur JSON und das system kümmert sich dann darum die 'passende' bzw. vorhandene variante einzubinden. XS ist auf der fritzbox z.b. nicht vorhanden.
Ich verwende JSON ja gar nicht in HMCCU. Andere Module wie HUEBridge benutzen es. Dort steht aber nur ein
use JSON;
Das Modul JSON.pm prüft dann eigenständig, ob JSON::XS bzw. XS.so installiert ist und nutzt die schnelleren Routinen von XS.so zur Dekodierung. Das lässt sich nicht verhindern, außer man sorgt dafür, dass JSON::XS verschwindet. Möglicherweise nutzt JSON dann JSON::PP.
Für meine Theorie spricht auch, dass der Fehler nach Deinstallation von JSON::XS nicht mehr auftritt. Ein User hat eigenständig HUEBridge modifiziert und allow_nonref enabled. Auch dann tritt der Fehler nicht mehr auf.
ja. JSON nimmt automatisch PP wenn XS nicht vorhanden ist.
edit: wenn man sucht findet man viele hinweise das perl thread 'discouraged' sind. sogar direkt in der thread doku, das es probleme mit XS modulen gibt wenn man nicht aufpasst und in der XS doku steht explizit das XS nicht thread save ist und sich das auch nicht ändern wird.
und noch etwas: vielleicht hilft das hier: http://alvar.a-blast.org/vortraege/perl-workshop/forks.pdf (http://alvar.a-blast.org/vortraege/perl-workshop/forks.pdf)
@justme: sag ich doch :)
bei "use JSON" kann man das backend explizit auswählen, muss man also nix deinstallieren ;)
wenn jetzt aber HMCCU gar kein JSON verwendet wirds komplizierter. Dann entsteht das prob durch die Verwendung der threads.
Kleiner Ausflug: perl threads sind nicht "wie sonst" threads die vom OS nebenläufig gestartet werden. Für Perl threads wird der komplette Speicher einmal kopiert und dann ein ein neuer Interpreter gestartet. Das hat mich bei WifiLight auch "zurückgeworfen". Da hatte ich die schon implementiert und dann festgestellt das sich mit jedem thread der RAM Verbrauch direkt verdoppelt (1). JSON:XS wird auch mit jedem thread einmal alle internen Strukturen kopieren.
Für threads lautet die "allgemeine" Empfehlung beim Start vom pl einen pool zu erzeugen (BEGIN { .. }). Das funktioniert im Context fhem aber nicht (weil die module ja später geladen werden). Als Alternative starte ich derzeit einen zweiten perl Prozess der dann die threads bei Bedarf erzeugt (2). Dadurch wir allerdings auch die Kommunikation viel anspruchsvoller. Lese also mit Interesse hier mit :)
edit, Fußnoten
1: aus 200MB gleich mal 400MB usw
2: 2MB pro thread
naja, so schlimm sind threads auch wieder nicht. Fork hat auch seine Eigenheiten ...
eigenheiten vielleicht. aber prozesse sind leichter zu debuggen, stabiler, portabler, ... :) ich kann mir im fhem umfeld eigentlich kein problem vorstellen das mit prozessen nicht zu lösen ist und bei dem es auf den vielleicht vorhandenen effizienzvorteil der threads ankommt. erst recht weil die perl threads ja gerade nicht besonders effizient sind. aber das ist eine andere diskussion...
Zitat von: herrmannj am 06 Oktober 2017, 16:57:32
bei "use JSON" kann man das backend explizit auswählen, muss man also nix deinstallieren ;)
Ist in den Modulen die JSON verwenden aber leider nicht ausgewählt.
Zitat
wenn jetzt aber HMCCU gar kein JSON verwendet wirds komplizierter. Dann entsteht das prob durch die Verwendung der threads.
Sehr wahrscheinlich. Vielleicht aber auch durch die Verwendung von Shared Memory Queues (Thread::Queue).
Zitat
Kleiner Ausflug: perl threads sind nicht "wie sonst" threads die vom OS nebenläufig gestartet werden. Für Perl threads wird der komplette Speicher einmal kopiert und dann ein ein neuer Interpreter gestartet. Das hat mich bei WifiLight auch "zurückgeworfen". Da hatte ich die schon implementiert und dann festgestellt das sich mit jedem thread der RAM Verbrauch direkt verdoppelt (1). JSON:XS wird auch mit jedem thread einmal alle internen Strukturen kopieren.
Das ist bei forks nicht anders. Auch da wird der Parent mitsamt seinem Speicher geklont.
Zitat
Für threads lautet die "allgemeine" Empfehlung beim Start vom pl einen pool zu erzeugen (BEGIN { .. }). Das funktioniert im Context fhem aber nicht (weil die module ja später geladen werden). Als Alternative starte ich derzeit einen zweiten perl Prozess der dann die threads bei Bedarf erzeugt (2). Dadurch wir allerdings auch die Kommunikation viel anspruchsvoller. Lese also mit Interesse hier mit :)
Ich erzeuge in HMCCURPC nicht ständig Threads und beende sie wieder. Die Threads werden beim Start des RPC-Servers einmalig alle gestartet (quasi wie ein Pool). Ein Thread zur Datenverarbeitung und zusätzlich ein Thread je CCU-Protokoll/Schnittstelle (in Summe 2-5 Threads). Die Daten werden von den Threads in Shared Memory Queues an FHEM übergeben. Ein Thread informiert FHEM per Socket-Pair, dass Daten in den Queues anstehen und FHEM liest in Read() die Daten aus den Queues.
Die reine Kommunikation über die Socket-Pairs funktioniert nicht, da FHEM die Daten nicht schnell genug verarbeiten kann und dann in den Threads Write-Errors bei Schreiben in die Sockets entstehen. Mein erster Ansatz waren geforkte Prozesse. Ich habe es aber nie geschafft, die Shared-Memory Queues mit geforkten Prozessen zum Laufen zu bekommen. Daher bin ich auf Threads umgestiegen.
@justme: Mich "discouragen" nicht die Threads sondern eher die Antiquiertheit von Perl ;-)
Fork verwendet copy on write. Das ist was anderes.
Shared memory läuft nicht mit fork.
Das mit den Write errors bei sockets verstehe ich nicht. Non blocking socket, select, bei e would block in einen Puffer schreiben.
Yeah!
JSON::XS deinstallieren hat tatsächlich geklappt. Obwohl es mit einem einfachen
sudo apt remove libjson-xs-perl
bei mit nicht geklappt hat, da ich das Modul auch noch mit CPAN installiert bzw aktualisiert hatte.
Aber mit cpanminus konnte ich dann auch das mit CPAN installierte Modul JSON::XS entfernen:
sudo cpanm --uninstall JSON::XS
Danach wieder auf den externen RPC gewechselt und fhem neu gestartet, et voila! Keine JSON-Probleme mehr und alle fhem-Module laufen trotzdem noch. :D
Auch wenn das "nur" ein Workaround ist: Solange kein anderes Programm JSON::XS benötigt kann ich damit gut leben.
Danke zap, dass du da dran geblieben bist!
shared memory geht auch zwischen prozessen. mit den gleichen problemen bezüglich locking und semaphoren wie sonst auch.
warum sockets nciht schnell genug sind verstehe ich auch nicht. wenn man non blocking arbeitetet und auf der schreibenden seite buffer sollte das eigentlich funktionieren.
Zitat von: herrmannj am 06 Oktober 2017, 18:33:18
Fork verwendet copy on write. Das ist was anderes.
Shared memory läuft nicht mit fork.
Das mit den Write errors bei sockets verstehe ich nicht. Non blocking socket, select, bei e would block in einen Puffer schreiben.
Bei Fork wird der komplette Prozess geklont inkl. Memory. Bei Threads wird der Speicher innerhalb des Parent-Prozesses gedoppelt (also im gleichen Speicherraum). So zumindest die Erklärung im Perl Thread Tutorial.
Ja das mit den Write Errors hat mich auch ziemlich viele Nerven gekostet. Ich habe gemeinsam mit Boris mit dem SubProcess.pm experimentiert. Die Abfrage auf Would Block hat auch in den meisten Fällen funktioniert. Aber nicht immer. Manchmal kam kein Would Block und das Schreiben ging trotzdem schief bzw. es wurde Erfolg gemeldet und die Daten kamen nie in Read() an. Insbesondere, wenn bei der Initialisierung der Verbindung zur CCU diese ihre ganze Konfiguration schickt (>300 Kb).
Ich möchte da keinen Aufwand mehr reinstecken und bei Threads bleiben. Bevor ich nochmal mit Fork rumfrickle wechsle ich eher zu OpenHab oder IOBroker. Ich habe schon einige ähnliche Programme in C/C++ geschrieben. Da hatte ich nie diese Probleme wie mit Perl.
Aber Deine Idee, zunächst einen speichermäßig kleinen Prozess zu starten und von dort dann die Threads werde ich mir nochmal anschauen.
@Barit: Aus eigenem Interesse. Nachdem ich das neue Raspbian installiert hatte, wollte ich das Ding auch in Betrieb nehmen.
jede 'moderne' fork implementierung arbeitet mit copy on write damit z.b. bei einem direkt nachfolgenden exec nicht umsonst kopiert wird.
@zap:
Da 50+ offizielle FHEM Module decode_json() verwenden und (teilweise?) von dem "Bug" betroffen sind, möchte ich Dich bitten das Problem zu lösen.
Im Wiki zu beschreiben, dass es zu Problemen kommen kann, ist mAn nicht die Lösung, wenn andere Module davon in Mitleidenschaft gezogen werden und gar nicht mehr funktionieren. Das wirft zum einen kein gutes Licht auf FHEM im Allgemeinen und verursacht zum anderen Supportaufwand bei weiteren Maintainern.
Wenn dieses Problem, das augenscheinlich durch Dein externes HMCCU RPC Modul ausgelöst wird, erst einmal nicht zu lösen ist, dann wäre es aus meiner Sicht angebracht, dass Du solange Dein Modul nur noch mit dem internen RPC Server anbietest und die Nutzung des externen RPC Servers unterbindest (zumindest würde ich so handeln). Auch die Empfehlung aus dem HMCCU Wiki (https://wiki.fhem.de/wiki/HMCCU#RPC_Server_konfigurieren), JSON::XS zu deinstallieren, empfinde ich als nicht angemessen, da dadurch dann 50+ andere Module langsamer arbeiten, mit dem einzigen Ziel Dein HMCCU Modul zu beschleunigen. Abgesehen davon, dass ein Anwender das Problem erst einmal erkenen muss...
Aktueller Anlass für mein Posting: https://forum.fhem.de/index.php/topic,81840
Lies bitte mal diesen Post von mir:
https://forum.fhem.de/index.php/topic,74943.msg695487.html#msg695487
In neueren Versionen von Json::xs wurde etwas geändert. Dies bedingt, dass eine bestimmte Option gesetzt werden muss. Wann Json::xs verwendet wird, ist nicht klar dokumentiert. Man kann das nur erzwingen, wenn man das Modul deinstalliert.
Es ist kein Problem meines Moduls sondern ein Problem, das in der Konstellation Json, Threads, shared Memory auftritt.
Das heißt im Umkehrschluss, dass aus Deiner Sicht für die korrekte Funktion von FHEM, JSON::XS nicht installiert sein darf oder Entwickler aller anderen Module nur noch die OO Variante von JSON verwenden dürfen.
Würdest Du das dann bitte in der Developer Area verkünden, damit nicht noch andere Entwickler auf die absurde Idee kommen, JSON "einfach so" zu verwenden und die, die es verwenden, es ändern können?
@zap
Ich befürchte so einfach wird das nicht zu lösen sein.
Die User sehen immer gerne nur das Offensichtliche. Lass mich Dir kurz das Offensichtliche erklären. Ein User hat Probleme mit 2-3 Modulen wegen Fehlermeldungen. Er meldet sich bei den Autoren und bekommt als Antwort von jedem Autor gleich, schalte den internen RPC Server ein. Und oh siehe da, es geht wieder. Also kommt der User zurück zu Dir und fragt was da los sei. Er habe nur bei Deinem Modul etwas geändert und schon geht alles wieder. Es muss also an Deinem Modul liegen. So sehen User das Offensichtliche.
Also lass uns doch einfach zusammen versuchen eine für alle brauchbare Lösung zu finden. Hier sind so viele gute Perlexperten, da kann es ja nicht so schwer sein.
Ansonsten befürchte ich das Du im schlimmsten Fall gebeten wirst Deine Module nach Contrib zu verlegen und sie somit nicht mehr offiziellen Status haben, da sie zu anderen offiziellen Modulen inkompatibel sind.
Grüße
Leon
Die auftretenden Fehler in der Kombi Json::xs und Threads sind mE nur der Anfang. Zunächst werden jetzt mal alle Module auf die schwarze Liste gesetzt, die Threads verwenden. Das wäre dann HMCCURPC, SONOS und vielleicht noch das eine oder andere. Wenn dann weitere Probleme auftreten, werden dann noch andere Module ,,gebannt". Und alles nur, weil sich Entwickler nicht damit abfinden wollen, dass sich das Verhalten bzw die Anwendung der JSON Module in Perl geändert hat. Was kann ich denn dafür? Ich nutze Threads gemäß der Spezifikation.
Ich habe jedenfalls weder Lust noch Zeit, einen Fehler zu beheben, der keiner ist sondern nur die Änderung eines APIs.
@cooltux: bist du der Svn Verantwortliche, der diese Entscheidung für/gegen SVN/contrib trifft? Dachte eigentlich, das wären andere. Wenn dem also nicht so ist, kannst du dir die Drohungen bitte schenken. Falls es wirklich soweit kommen sollte, richte och eben eine github Update Source ein und gut. Und gezwungen HMCCURPC zu verwenden, wird ja jetzt auch keiner.
Mal langsam. Ich habe hier mit gar nichts gedroht. Ich habe meine persönliche Befürchtung zum Ausdruck gebracht. Das war alles.
Das das selbe Problem bei Sonos auch auf tritt ist mir persönlich neu, habe da noch gar nichts von gehört.
Alles was ich wollte ist eine Lösung anstreben. Wegen meiner können wir das auch so belassen wie es ist. Passt schon.
Was wäre Deiner Meinung nach denn zu tun? Also von den Developer deren Module nun Fehler werfen wenn HMCCURPC extern geladen wird.
Nochmal, das Zitat aus der offiziellen JSON Doku zu diesem Thema:
... but future versions might/will likely upgrade to the newer RFC as default format, so you are advised to check your implementation and/or override the default with ->allow_nonref (0) to ensure that future versions are safe.
Eigentlich unmissverständlich: das Todo liegt auf Seiten der Anwender der Json Module.
Also sollte ich in meinen Modulen in Zukunft JSON so einbinden?
my $json = JSON::XS->new->allow_nonref;
$text = $json->encode ($data);
$data = $json->decode ($text);
immer wieder auf allow_nonref zu verweisen geht leider am thema vorbei.
zum einen:
das
ZitatDue to security concerns, JSON::XS will not allow scalar data in JSON texts by default - you need to create your own JSON::XS object and enable allow_nonref:
bezieht sich auf so etwas:
encode_json("Hello, World!"); hier wird direkt ein string übergeben statt einer hash ref bzw. ode array ref. diesen fall kann man mit allow_nonref erlauben. entsprechend bei decode. korrekt wäre z.b.
encode_json(["Hello World!"]);und das muss nach wie vor ohne allow_nonref gehen.
zum anderen:
die json doku sagt ganz klar:
Zitatdecode
The opposite of encode_json: expects an UTF-8 (binary) string and tries to parse that as an UTF-8 encoded JSON text, returning the resulting reference. Croaks on error.
Zitatdecode_json
The opposite of encode_json: expects an UTF-8 (binary) string and tries to parse that as an UTF-8
encoded JSON text, returning the resulting reference. Croaks on error.
d.h. beide erwarten einen string und liefern eine referenz zurück. der sinn von encode und decode ist doch genau zwischen einer perl hash oder array ref und einem string den man dann verschickt hin und her zu übersetzen. und genau das geht nicht mehr sobald die externe rpc version verwendet wird.
um es noch mal zusammen zu fassen:
- der fall der mit allow_nonref erlaubt wird ist für unser problem nicht relevant.
- das problem ist das korrekter code plötzlich nicht mehr geht sobald der externe rpc server verwendet wird
d.h. das problem ist nicht auf seiten der 50 module die funktionieren so lange der externe rpc server nicht mit im spiel ist.
mehr details gibt es auch hier: https://forum.fhem.de/index.php/topic,74943.msg693395.html#msg693395 (https://forum.fhem.de/index.php/topic,74943.msg693395.html#msg693395) noch mal.
ganz unabhängig davon: auf andere module zu verweisen die threads verwenden geht auch am thema vorbei zumindest so lange wie diese keine probleme machen.
es geht hier doch garnicht ums drohen sondern darum eine lösung für ein problem zu finden das tatsächlich immer wieder hier im forum aufschlägt.und auch wenn wir noch nicht wissen wie und warum der externe rpc server dazu führt ist er definitiv beteiligt. vermutlich sogar ursächlich. ganz ohne schuld hin und her zu schieben. auch wenn die meisten die doku nicht lesen wäre es vielleicht hilfreich dort und im log eine meldung unterzubringen die auf die json probleme hinweist.
Danke Andre,
Alles was ich wollte war ja nur eine gemeinsame Lösung anstreben. Nach dem ich mir nun mehrere Meinungen durch gelesen habe und mir mehr Infos in einem persönlichen Telefonat geholt habe, bin ich zu einem persönlichen Entschluss zu diesem Thema gekommen.
Ich werde diesen hier nicht mitteilen. Für mich hat sich das bis auf weiteres hier erstmal erledigt. Sollte die Mehrheit beschließen das die Anwendung von JSON geändert werden muss, so habe ich kein Problem damit das in meinen Modulen um zu setzen.
Grüße
Leon
Zitat von: justme1968 am 01 Januar 2018, 15:43:03
immer wieder auf allow_nonref zu verweisen geht leider am thema vorbei.
Beim OO Call eigentlich nicht. Weil das geht zwar nicht:
my $json = JSON->new;
my $text = $json->encode(["Hello World!"]);
aber das:
my $json = JSON->new->allow_nonref;
my $text = $json->encode(["Hello World!"]);
Zitat
zum anderen:
die json doku sagt ganz klar:
d.h. beide erwarten einen string und liefern eine referenz zurück.
Stimmt teilweise. Im Beispiel zu encode steht ganz open bei CPAN, dass eine Hash- oder Array-Ref erwartet wird. Bei decode hingegen ein string. In besagtem Beispiel wird auch bei OO allow_nonref verwendet. Bei nicht OO müsste es aber zumindest bei decode wie von Dir beschrieben funktionieren. Witzigerweise kommt die Fehlermeldung sogar, wenn man der encode Funktion wie in der Fehlermeldung gewünscht eine Hash- oder Array-Ref übergibt.
Mittlerweile gibt es mit mit Cpanel::JSON::XS einen Fork von JSON::XS wegen der vielen Bugs in JSON::XS und weil der Maintainer von JSON::XS anscheinend beratungsresistent ist. Wird halt (bis jetzt) nur verwendet, wenn man es explizit einbindet. JSON selbst verwendet nach wie vor JSON::XS, sofern es da ist.
Hier mal noch ein Testprogramm, das den Fehler provoziert, sofern man die Create Thread Zeile auskommentiert. Das Problem ist damit leicht auf das Erzeugen eines Threads zurückzuführen:
#!/usr/bin/perl
use strict;
use warnings;
use JSON;
use threads;
use threads::shared;
sub th { }
# Naechste Zeile provoziert JSON-Fehlermeldung
# threads->create(\&th)->join();
# Naechste Zeile verhindert JSON-Fehlermeldung auch bei erzeugtem Thread
# my $json = JSON->new->allow_nonref;
my $json = JSON->new;
my $text = $json->encode(["Hello World!"]);
print "$text\n";
Interessant ist, dass bei Einbindung von threads.pm mit use der Fehler nicht auftritt. Erst das Erzeugen eines Threads führt dazu. Nun verwendet SONOS zwar auch Threads, diese werden jedoch aus einem geforkten Subprozess heraus gestartet. Daher tritt der Fehler dort nicht auf (s. testprog unten). Es gibt noch ein paar andere Module, die Threads verwenden. Je nach Art des Thread-Starts müsste der Fehler dort auch auftreten.
Hier ein Beispiel, bei dem der Thread in einem Subprozess gestartet wird. Der JSON Fehler tritt (auch ohne allow_nonref) nicht auf:
#!/usr/bin/perl
use strict;
use warnings;
use JSON;
use threads;
use threads::shared;
sub th { print "Thread!\n"; }
my $pid = fork ();
if (!defined ($pid)) {
print "Can't fork\n";
}
elsif ($pid == 0) {
threads->create(\&th)->join();
exit (0);
}
my $json = JSON->new;
my $text = $json->encode(["Hello World!"]);
print "$text\n";
Fazit: JSON::XS und Threads tun nicht zusammen. Mögliche Lösungen:
- Keine FHEM-Module verwenden, die Threads nutzen und diese im Hauptprozess starten
- JSON::XS deinstallieren
- In FHEM-Modulen, die JSON verwenden, die OO-Version verwenden und allow_nonref setzen
- In FHEM-Modulen, die JSON verwenden, statt JSON::XS explizit Cpanel::JSON::XS verwenden (nicht getestet, löst aber angeblich das Problem auch)
- Hoffen, dass irgendwann JSON::XS durch Cpanel::JSON::XS ersetzt wird
JSON::XS ist nicht thread safe !
Explizit JSON::PP verwenden löst das Problem.
JSON::XS erst laden _nachdem_ der thread gestartet ist reicht auch (ist aber praktisch nicht umsetzbar)
Threads aus dem fhem Hauptprozess heraus starten ist aber ohnehin eine Sünde da (perl) threads eine _komplette_ Kopie des Speichers erzeugen. Da wird komplett alles kopiert, ohne copy on write.
allow_non_ref ist ein Symptom, nicht die Ursache.
Zitat von: herrmannj am 02 Januar 2018, 12:12:27
JSON::XS ist nicht thread safe !
Explizit JSON::PP verwenden löst das Problem.
JSON::XS erst laden _nachdem_ der thread gestartet ist reicht auch (ist aber praktisch nicht umsetzbar)
Threads aus dem fhem Hauptprozess heraus starten ist aber ohnehin eine Sünde da (perl) threads eine _komplette_ Kopie des Speichers erzeugen. Da wird komplett alles kopiert, ohne copy on write.
allow_non_ref ist ein Symptom, nicht die Ursache.
Unterschreibe ich Dir alles. Die möglichen Lösungen sind alles Workarounds.
Ursache ist für mich die Art und Weise, wie in den letzten Jahren bei Perl alle neueren Features "dran gefrickelt" wurden. Ob das Threads sind oder eben die Beschleunigung XS für JSON. Viele Perl Module sind irgendwo bei Version 0.x stehen geblieben und werden nicht mehr weiter entwickelt. Deshalb habe ich auch keine Hoffnung, dass die Threads/JSON::XS Problematik gelöst wird. Es besteht einfach kein Bedarf dafür. Alle neuen Sachen werden in Python, Nodejs oder ... entwickelt.
Das Starten der Threads aus einem Subprozess hatte ich schon mal. Aber dann macht eben FHEM die Grätsche, wenn die CCU bei der Initialisierung Massen von Daten schickt. Hatte ich aber schon mal beschrieben. Puffern würde zwar gehen, allerdings verzögert das die Initialisierung der Schnittstelle ins Endlose.
Nur wieso ist allow_nonref ein Symptom? Es gibt den alten JSON Standard (RFC 4627) und den neuen (RFC 7159). Und der neue besagt eben "Due to security concerns, JSON::XS will not allow scalar data in JSON texts by default - you need to create your own JSON::XS object and enable allow_nonref". Ist halt so, kann man akzeptieren, ignorieren oder was auch immer. In der Doku steht zwar, dass man Strings übergeben kann, aber das bezieht sich eben auf den alten Standard. Und mit Debian Stretch wurde nun anscheinend etwas geändert, denn vor dem Update auf Stretch ist der Fehler nicht aufgetreten.
Mit der neuen HMCCU Version sollte das Thema erledigt sein:
https://forum.fhem.de/index.php/topic,83544.0.html
HMCCURPC mit Threads war zwar irgendwie eleganter, aber HMCCURPCPROC nutzt nun fork() statt Threads und hat daher kein Problem mit JSON::XS.
Memory-Verbrauch ist wie bei Threads. Performance auch. Ich musste nur ein paar Klimmzüge machen, wenn der I/O Loop in FHEM die Events der CCU nicht schnell genug verarbeiten kann. Dann wird halt eine Queue bemüht und es kommt zu einer Verzögerung von bis zu 1 Sekunde.
Also liebe Thread/JSON::XS Geplagte: Morgen Updaten und umstellen auf HMCCURPCPROC.