Hauptmenü

FHEM stürzt ab

Begonnen von Dr. Jörg Licher, 04 Dezember 2014, 00:17:27

Vorheriges Thema - Nächstes Thema

Dr. Jörg Licher

Hallo zusammen,

bei mir stürzt seit neuestem FHEM mit folgender Meldung auf der Konsole ab:

Wide character in memGzip at ./FHEM/01_FHEMWEB.pm line 402

Woran kann das liegen? Im logfile erscheint nichts.

Danke...

Jörg

betateilchen

Zu wenige Informationen...

Welcher Browser?
Attribut fwcompress schonmal probiert?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Jörg Licher

Das Symptom ist unabhängig vom Browser und tritt nach 5 bis 10 Minuten spontan auf, auch wenn der Webzugriff gerade nicht benutzt wird. Deswegen kann ich auch nicht mehr dazu sagen. Der Webzugriff funktioniert dann erst wieder nach einem Neustart.

Jörg

mariuswhv

Hi,

bei mir genau das gleiche:
Argument "" isn't numeric in addition (+) at ./FHEM/59_Weather.pm line 173, <$fh> line 479.
Wide character in memGzip at ./FHEM/01_FHEMWEB.pm line 402
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 135.

Habe gestern ein Update druchgeführt und nun ist Fhem unbrauchbar. Ich muss es immer neu starten

LG

rudolfkoenig

Irgendetwas, was FHEMWEB zum Browser senden will, wird als Unicode-String markiert.
Da die Stelle, die man modifizieren muss, sehr viele Leute betrifft, die bisher keine Probleme hatten, moechte ich das Problem nachstellen, und nicht nur blind ein Workaround einbauen.
Desegen bitte die Zeile 402 durch folgenden Code ersetzen:
    eval { $FW_RET = Compress::Zlib::memGzip($FW_RET); };
Log 1, "$@: $FW_RET" if($@);

und die Ausgabe uns mitteilen.

mariuswhv

Erstmal danke für die schnelle Antwort.

Die Ausgabe:
Wide character in syswrite at fhem.pl line 614.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 135.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 135.

rudolfkoenig

Meine Antwort war eigentlich an "Dr. Jörg Licher" gerichtet, und ich meinte natuerlich die Ausgabe von meinem "Patch". Die Blocking Geschichte bitte in einem separaten Thread ansprechen.

mariuswhv

Ich will jetzt auch nicht weiter stören, aber ich hatte die gleiche Fehlermeldung, und nachdem ich in die Zeile (614) geschaut habe, ist mir aufgefallen, dass es mit den Raumnamen zu tun hat.
(Meine Ausgabe war die Ausgabe des Patches)

Meine Frage bezog sich nicht auf Blocking.pm.
Ich habe Unterstriche in die Raumnamen eingefügt. Ich habe sie wieder raus genommen und nun scheint es wieder zu laufen.

Vielleicht kann das noch helfen.

rudolfkoenig

Zitat(Meine Ausgabe war die Ausgabe des Patches)
Das kann ich mir nicht vorstellen.

ZitatIch habe Unterstriche in die Raumnamen eingefügt.
War das ein ASCII _  (Hex 5f) oder ein Unicode-Lookalike?

mariuswhv

ganz kurz:

zu erst war es die Meldung:
Wide character in memGzip at ./FHEM/01_FHEMWEB.pm line 402

nachdem ich die Zeile 402 in 01_FHEMWEB.pm durch:
    eval { $FW_RET = Compress::Zlib::memGzip($FW_RET); };
Log 1, "$@: $FW_RET" if($@);

ersetzt habe, war es die Meldung:
Wide character in syswrite at fhem.pl line 614.

Es ist ein normaler Unterstrich den ich über Firefox unter Ubuntu über das Webinterface eingefügt habe. Vorher habe ich es unter gedit vorgeschrieben.

Aber an dieser Stelle bin ich mal raus. Bei mir funktioniert es nach 4 Stunden Kampf wieder nachdem ich die Zeichen rausgenommen habe.

bis dann

Alex85

#10
Habe auch dieses Problem ...

Ich kann FHEM nachvollziehbar zum Absturz bringen indem ich einfach nur die details-Seite meiner HueBridge aufrufen will.


2014.12.05 09:04:41 4: /fhem?room=HUEDevice / RL:2136 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63345 GET /fhem/pgm2/style.css
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63422 GET /fhem/pgm2/jquery.min.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63346 GET /fhem/jscolor/jscolor.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63347 GET /fhem/pgm2/jquery-ui.min.js
2014.12.05 09:04:41 4: Connection accepted from FHEMWEB:192.168.2.66:63429
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63345 GET /fhem/pgm2/dashboard.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63429 GET /fhem/pgm2/svg.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63422 GET /fhem/pgm2/fhemweb.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63429 GET /fhem/pgm2/fhemweb_noArg.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63346 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63347 GET /fhem/pgm2/fhemweb_multiple.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63345 GET /fhem/pgm2/darkCommon.css
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63429 GET /fhem/pgm2/fhemweb_slider.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63422 GET /fhem/pgm2/fhemweb_readingsHistory.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63346 GET /fhem/pgm2/fhemweb_svg.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63429 GET /fhem/images/dark/icoEverything.png
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63422 GET /fhem/pgm2/dashboard_darkstyle.css
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63346 GET /fhem/images/dark/off.png
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63347 GET /fhem/pgm2/fhemweb_textField.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63345 GET /fhem/pgm2/fhemweb_time.js
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63345 GET /fhem/images/default/fhemicon_dark.png
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63345 GET /fhem/jscolor/hs.png
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63346 GET /fhem/jscolor/arrow.gif
2014.12.05 09:04:41 4: HTTP FHEMWEB:192.168.2.66:63347 GET /fhem/jscolor/cross.gif
2014.12.05 09:04:42 4: HTTP FHEMWEB:192.168.2.66:63347 GET /fhem?XHR=1&inform=type=status;filter=room=HUEDevice&timestamp=1417766682010
2014.12.05 09:04:44 4: Connection closed for FHEMWEB:192.168.2.66:63349
2014.12.05 09:04:44 4: HTTP FHEMWEB:192.168.2.66:63346 GET /fhem?detail=HueBridge


danach: crash

Restart vom FHEM erforderlich, da keine connection mehr übers Webinterface möglich ist.

MartinMuc

Selbes Problem gestern bei mir, ich nutze Chrome und Safari auf Ipad und iphone
Cubietruck mit CUL und HM USB

rudolfkoenig

Da es reproduzierbar ist: koennt ihr mir bitte eine minimale fhem.cfg bauen, mit dem ich es nachstellen kann? Wichtig: es soll auch ohne zusaetzliche Geraete funktionieren (wie fhem.cfg.demo).

pattex

#13
Hallo Zusammen, nutzt ihr Philips hue? Immer wenn ich das Modul aktiviere, kommt es zu dem beschriebenen Problem.

Nachtrag: Meine Hue Android App sagte mir, das ein Update bereit steht. Nachdem ich dieses installiert habe, sind nun die Abstürze beim Abfragen der xmllist weg.
Bei mir war auch 98_gcmsend in line 107 betroffen.

Alex85

Ja ich schon. Bei mir tritt der Fehler auch nur dann auf, wenn ich wie oben beschrieben auf die Detailansicht der HueBridge wechseln will...

pattex

@Alex85
Hast du ein Update für deine HueBridge anstehen? Spiel das mal ein und versuche es noch mal.

Alex85

Ja, tatsächlich. Hatte ich noch nicht gemerkt ...
Werds mal versuchen...
Danke für den Tipp!

justme1968

auf welcher platform ist dein fhem installiert? verwendest du irgendwelche umlaute oder sonstigen 'seltsamen' zeichen für die namen der lampe oder der bridge?

was gibt ein list auf deine bridge?

was ist auf der console zu sehen wenn du fhem von hand startest?

gruss
  andre

ps: meine detail ansicht geht. auch ohne update. so weit ich das sehe ist das aktuelle update auch nicht für die bridge selber sonder für die bulbs.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

Alex85

#18
Naja, da wäre die Glühbirne ...  :)
Das ging aber alles wunderbar vor dem heutigen Update.
Und ich fands auch ganz schön, dass das Ding net Gluehbirne heissen muss...

Achja, meine FHEM-Installation läuft auf einem Raspberry PI, ebenfalls heute alle installierten Pakete (Debian Wheezy) auf den neusten Stand gebracht ...

pattex

@justme1968
ich habe fhem auf einer debian vm unter esxi.
Ich habe Umlaute bei den Namen meiner Hue Komponenten.
Bsp.: Eßtisch
Bis vor 2 Tagen lief alles ohne Probleme mit Umlauten. Dann, plötzlich OHNE Konfigurationsänderung hatte ich folgende Meldung :
HTTP::Message content must be bytes at ./FHEM/98_gcmsend.pm line 107
ich habe das Modul temporär entfernt und die FHEM blieb oben. Als ich dann allerdings über andfhem die xmllist abgefragt habe, hat sich FHEM mit der in diesem Thread genannten Meldung verabschiedet.
Nach dem Hue Update läuft nun wieder alles.
Allerdings sehe ich das so, das die beiden Module gcmsend und fhemweb, egal was da durchgeschleust wird, auch ohne Absturz kodieren sollten.

justme1968

auf der fritzbox gibt es probleme mit den umlauten. das ist aber eine andere geschichte. es sollte auch nicht die detail ansicht der bridge betreffen.

am hue modul gab es in letzter zeit kein update. vor zwei tagen ist aber das firmware update rausgekommen und das taucht dann in einem reading in der bridge auf. eventuell ist hier ein zeichen in der nachricht das probleme macht. nach dem update sollte das reading aber immer noch da stehen.

keiner von euch hat mir das list für die bridge gezeigt.

ich kann auf meinem system sowohl in die detail ansicht gehen und xmllist verwenden ohne das update gemacht zu haben.

irgendetwas ist hier komisch...
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

pattex

#21
Mit dieser Zeile im Bridge Segment: <STATE key="swupdate" value="HUE0103 – 66013452" measured="2014-12-05 16:42:38"/>
ist die fhem abgestürzt.
Nun wo wieder alles OK ist, steht in dem Segement folgender Eintrag:
<STATE key="swupdate" value="HUE0100 lamp 66013452 " measured="2014-12-05 17:16:52"/>

Wie gesagt. Egal was in dem Segment steht, die Module müssen richtig kodieren.

Nachtrag:
Hex steht in der Problematischen Zeile:
48 55 45 30 31 30 33 20 E2 80 93 20 36 36 30 31 33 34 35 32
was in etwa so aussieht: HUE0103 â€" 66013452

rudolfkoenig

#22
Man kann das Problem relativ einfach reproduzieren mit:
{ $attr{XX}{room} = "Hello \x{263A}!" }
Siehe auch http://ahinea.com/en/tech/perl-unicode-struggle.html

FHEM konvertiert z.Zt.keine Daten beim Einlesen/Ausgeben, es nimmt an, es sei alles utf-8, und wer was anderes macht ist selber Schuld. Intern wird alles als Bytefolge behandelt, und wenn ein ä zwei Zeichen lang ist, stoert keinen.

Leider habe ich diese Rechnung ohne einige Perl-Modulautoren gemacht, die der Ansicht sind, ein ä ist ein Zeichen lang, mit der Folge, dass alles bei der Kommunikation mit der Aussenwelt penibel konvertiert werden muss. Jedes print/syswrite muss erst nach einem encode erfolgen, genauso wie nach jedem read etc ein decode noetig ist. Intern wird dann alles als multibyte (==Wide Character) gespeichert, und alle Ausgaberoutinen (print/gzip) beschweren sich, falls man das encode vergessen hat (Wide character und so).

Ich habe gerade versucht FHEMWEB auf encoding/decoding umzustellen, habe aber kein glueckliches Haendchen, und das in FHEMWEB eingegebene äöü wird zu Murks. Dafuer sieht man den Smiley von oben (☺), wenn man es via telnet eingibt (den ich auch umgestellt habe). Ich habe die Befuerchtung, dass es noch etliche andere FHEM-Module sind, die ein encode/decode benoetigen werden, was erst nach meiner Umstellung auffallen wuerde.

Ich wuerde also erstmal weiter die Strategie fahren, dass FHEM-intern alles als Bytefolge gespeichert wird, und wer ein Wide-Character einliest, der moege es fuer FHEM-intern nach utf-8 encoden. Damit bleibt nur das Problem des abstuerzenden perl, und dafuer habe ich bisher keine Loesung gefunden.

Weitere Meinungen?

betateilchen

irgendwie fällt mir da grade wieder mein - immer noch bestehendes - Problem mit falsch dargestellten Umlauten im Logitech Harmony Modul ein...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Jörg Licher

Hallo zusammen,

leider kann ich erst jetzt reagieren, da ich auf einer Tagung war. Nach den Einspielen des HUE-Updates läuft bei mir auch wieder alles ohne Probleme. Das HUE-Modul in Verbindung mit dem Update-Hinweis war die Ursache für die Abstürze.

Danke für die Antworten.

Bis dann...

Jörg

justme1968

#25
@rudi: achtung. das problem ist nicht die länge eines zweichens (ein utf-8 ä ist auch zwei zeichen lang, siehe unten) sondern hat mit dem encoding zu tun. es hilft auch nicht das nachträglich irgendwo zu 'reparieren' wenn an dieser stelle gar nicht bekannt ist in welchem encoding der text denn überhaupt vorliegt. das weiss nur das modul.

die einzige lösung ist festzulegen das fhem intern alles utf-8 ist und jedes modul die daten die rein kommen nach utf-8 wandeln muss bzw. beim raus geben gegebenfalls von utf-8 in das ziel encoding wandeln muss.


zu den encodings und der länge eines zeichens: bei latin1 und co. sind das fest 1 byte pro zeichen, utf-8 ist ein encoding mit einer variablen anzahl von bytes pro zeichen. alles was < 127 ist braucht nur 1 zeichen, das meiste das in latin1&co zwischen 127 und 256 ist braucht zwei byte. es gibt zeichen die drei oder vier byte brauchen. wchar ist nicht utf-8. unicode ist gar kein encoding.

\x{263A} ist nur eine möglichkeit direkt einen hex wert in eine string zu stecken und sagt nichts über das encoding. wenn der hex wert nicht zum encoding passt das für diesen string angenommen wird kommt müll dabei raus.

dein link ist interessant weil er genau das gegenteil von dem zeigt was du rausliest. laut beispiel machtmy $ustring1 = "Hello \x{263A}!\n"; im perl code keine probleme aber die zweite variante sehr wohl. wenn du jetzt genauer hin schaust ist es in fhem genau umgekehrt: { $attr{XX}{room} = "Hello \x{263A}!" } macht probleme, obwohl es das gar nicht dürfte. die version die direkt den smilie im text hat kann man aber problemlos ins telnet fenster pasten:{ $attr{XX}{room} = "Hello ☺!"}und wird dann per list und web korrekt angezeigt.

es kracht übrigens nicht bei der eingabe sondern auch in diesem beispiel bei der ausgabe.

ich denke das hier zeigt nicht ein problem mit telnet, das ist so weit sauber. der string "Hello \x{263A}!" ist übrigens reinstes ascii. da kommt kein utf-8 oder wchar zeichen vor.  und wenn hier utf-8 eingegeben wird kommt auch utf-8 an und wird anschliessend in der web ansicht auch angezeigt. im telnet modul ist kein encode/decode nötig.

das problem ist die auswertung des {...} ausdrucks. hier geht an irgendeiner stelle beim eval die information über das encoding verloren und es wird etwas nach intern übernommen das nicht mit dem korrekten encoding markiert ist.

ein{ $attr{XX}{room} = encode_utf8("Hello \x{263A}!") } geht übrigens. generell ein encode nach dem eval einzubauen funktioniert aber nicht weil es schief geht einen 'echten' per telnet eingebenen utf-8 string zwei mal zu encoden. -> das alte probem wenn das encoding nicht bekannt ist und ein falsches angenommen wird kommt müll raus.


warum gzip sich beschwert ist mir nicht ganz klar. das arbeitet eigentlich nur auf byte ebene und hat überhaupt keine ahnung von strings und encodings. gzip sollte nur eine bytefolge bekommen und keinen string von dem perl denkt das er noch mal konvertiert werden muss.


@betateilchen: ich habe dein problem nicht vergessen aber absolut keine idee. es ist auch kein wchar/utf8 problem bei dir sondern ein latin1/utf8 problem. also nicht ganz das gleiche. du bist scheinbar auch der einzige den es trifft.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

justme1968

das hue modul geht davon aus das der text der ankommt utf-8 codiert ist und das json modul macht (normalerweise) das richtige diesen utf-8 string korrekt an fhem weiterzugeben (siehe z.b. die umlaute in den lampen namen).

es kann aber passieren das von extern die json daten zwar als utf-8 gekennzeichnet sind aber ungültige zeichen drin stecken. normalerweise strüzt das json modul dann mit einem entsprechenden hinweis ab.

vielleicht ist so ein zeichen durchgerutscht oder wurde doppelt encoded so das dies zu müll geführt hat. ich versuche das weiter zu beobachten.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

rudolfkoenig

@andre: \x{263A} ist zwar reinstes ASCII, erzeugt intern aber einen Wide-Character, die Laenge ist also 1
perl -e 'print length("\x{263A}"),"\n"'
1


print/gzip/syswrite moegen solche Wide-Characters nicht, und wollen die Daten vorher nach "binaer" (d.h. 1Byte / Character) convertiert haben:
perl -e 'use Encode; print length(encode("utf-8", "\x{263A}")),"\n"'
3

justme1968

"Hello \x{263A}!\n"; ist für das telnet modul ascii. deshalb gehört hier kein encode hin.

es wird erst durch das eval zu etwas anderem. welches encoding dieses andere aber intern hat hat kannst du nicht wirklich sagen. das hängt unter anderem von der perl version ab. wenn es utf-8 ist dann sind es intern sogar 3 byte und nicht nur 2.

die zwei byte 26h 31h sind kein gültiger utf-8 string und werden auch intern nicht als 2 byte gespeichert.

die unterscheidung zischen dem unicode codepoint (2631) und der utf-8 repräsentation des zeichens (3 byte: e2 98 ba) ist wichtig.


das length im ersten fall 1 zurück liefert hat nichts mit wchar zu tun sondern damit das perl das encoding des strings kennt und zeichenweise arbeitet. die 1 kommt für jedes intern verwendete encoding zurück. du kannst du zeichenweise verarbeitung auch mit einem 'use bytes' abschalten und length liefert dann ganz ohne encode 3 zurück.


perl strings sind immer character strings und keine byte strings.

das encode in deinem beispiel 'konvertiert' nicht wirklich etwas sondern kopiert die 3 byte 1:1 in den neuen string und markiert diesen mit dem encoding binary. d.h. er wird jetzt byteweise verarbeitet und hat kein echtes encoding mehr.

print und syswirte haben kein problem mit dem internen encoding wenn es bekannt ist und der descriptor als utf8 stream markiert ist. wenn er das nicht ist hilft ein {use bytes; syswrite...;} damit wird die interne 3 byte utf-8 binär ausgegeben.

fehler:
my $txt = "\x{263A}";
print "txt: $txt\n";
syswrite STDOUT, "txt: $txt\n";


geht:my $txt = "\x{263A}";
print "txt: $txt\n";
{
  use bytes;
  syswrite STDOUT, "txt: $txt\n";
}


oder mit binmode:my $txt = "\x{263A}"; 
print "txt: $txt\n";   
binmode STDOUT, ':utf8';
syswrite STDOUT, "txt: $txt\n";
binmode STDOUT, ':bytes';



gzip ist das encoding egal. aber wenn perl einen string mit falschem encoding an gzip weiterreicht geht es schief weil versucht wird das interne encoding in einen stream zu stecken der kein encoding hat. eventuell hilft hier auch den aufruf in ein { use bytes; ... } zu klammern.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

justme1968

#29
ich habe inzwischen die genaue nachricht die probleme macht. der bindestrich in "HUE0103 – 66013452" kein normaler bindestrich wie vermutet ein utf-8 endash.

ich schaue nachher mal wo es damit genau schief geht.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

justme1968

ich habe noch etwas weiter getestet und habe zwei lösungsansätze. das problem ist zwar eigentlich tiefergreifend aber ich denke ich habe eine lösung die mit der aktuellen fhem version funktioniert.

@betatteilchen: ich kann inszwischen auch dein problem nachstellen und die lösung funktioniert auch dafür. ich poste im harmony thread eine version zum testen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

krannich

Hallo Andre,

gibt es schon einen Fix?
Bei mir stürzt FHEM auch immer ab. Und zwar immer wenn ich mit Fhemobile oder FHEM Remote zugreifen möchte (diese Apps führen einen XML-Request durch).
Deaktiviere ich das HUE-Plugin, stürzt FHEM nicht mehr ab.
Hier noch ein Auszug aus meinem Log (Loglevel 5), falls es hilft.

2014.12.07 23:17:26 5: SET: Unknown argument ?, choose one of off:noArg on:noArg  blink toggle on-for-timer on-till off-for-timer intervals off-till
Unknown argument ?, choose one of clear:readings,trigger,register,rssi,msgEvents,all getConfig getRegRaw getSerial getVersion inhibit:on,off off on on-for-timer on-till pair peerBulk peerIODev press raw regBulk regSet reset sign:on,off statusRequest toggle unpair


Viele Grüße,
Dennis

justme1968

die version hier: http://forum.fhem.de/index.php/topic,11020.msg227264.html#msg227264 sollte helfen. ich habe leider noch kein ferdback bekommen.

ansonsten hilf der firmware update.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

justme1968

die meldung schaut nicht hue aus sondern eventuell nach homematic.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

krannich

Hi Andre,

Danke, ich werde das mal ausprobieren.
Es kann sein, dass meine Fehlermeldung gar nichts mit HUE zu tun hat, das ist richtig.
Dennoch stürzt das System ab, wenn ich HUE aktiviert habe und es läuft super, wenn es nicht aktiv ist.
Ich gebe Dir Feedback zu Deiner aktualisierten Version.

Viele Grüße,
Dennis

krannich

Hi Andre,

Deine neue Version hat funktioniert.
Ich habe bis jetzt nur die 30_HUEBridge.pm ausprobiert, da dann kein Absturz kam.
Habe auch die neuste HUE-Firmware drauf.

Viele Grüße,
Dennis

Thorsten Pferdekaemper

Hi,
gibt es eigentlich zu dem ursprünglichen Problem eine Lösung? Ich meine das mit dem "Wide character in memGzip". Ich hatte das Problem jetzt gerade mit "°C", kodiert als x2103.
Gruß,
   Thorsten 
FUIP

rudolfkoenig

Liegt vmtl. weiterhin daran, das ein Modul nicht erlaubte Zeichen nach FHEM einschleust, da muss es gefixt werden.

Thorsten Pferdekaemper

Hi,
ok, das kann man vielleicht auch machen. Bei mir ist das bei den FHEM-Wired Sachen passiert. Da wird sowieso noch daran herumentwickelt. Etwas hässlich ist dabei, dass ein Modul FHEM komplett zum Abschmieren bringen kann. Mir ist klar, dass sich das wahrscheinlich nicht zu 100% vermeiden lässt, aber es wäre schon schöner, wenn man bekannte Schwachstellen wegbekommen würde. Könntest Du den Fehler nicht wenigstens abfangen und statt dessen eine Fehlermeldung auf's Frontend schicken? Dazu vielleicht noch einen deutlichen Log-Eintrag?
Gruß,
   Thorsten
FUIP

rudolfkoenig

Wenn du mir sagst, wie ichs machen soll, gerne.
eval reicht schon mal nicht.

Thorsten Pferdekaemper

Zitat von: rudolfkoenig am 23 März 2015, 11:02:50
Wenn du mir sagst, wie ichs machen soll, gerne.
Ich kann mich ja mal daran versuchen. Mal sehen, vielleicht komme ich heute Abend mal dazu, mir das näher zu betrachten.
Gruß,
   Thorsten
FUIP

rudolfkoenig

Korrektur: eval schuetzt sehr wohl, allerdings stuerzt FHEM dann im zentralen syswrite ab.

Ich habe memGzip jetzt mit eval abgefangen, im Fehlerfall werden die Rueckgabewerte geloescht, d.h. im Browser sieht man nur eine weisse Seite. Ob damit alle Faelle erschlagen werden, weiss ich nicht.

Thorsten Pferdekaemper

Hi,
das ist doch schonmal besser als vorher.
Danke&Gruß,
   Thorsten
FUIP

plin

Zitat von: Dr. Jörg Licher am 05 Dezember 2014, 20:48:10
leider kann ich erst jetzt reagieren, da ich auf einer Tagung war. Nach den Einspielen des HUE-Updates läuft bei mir auch wieder alles ohne Probleme. Das HUE-Modul in Verbindung mit dem Update-Hinweis war die Ursache für die Abstürze.
tja, das so ein Fehler auch nach 3,5 Jahren noch FHEM runterreißen kann ...
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB