FHEM stürzt ab

[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.

[Alex85]

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...

[pattex]

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]

Man kann das Problem relativ einfach reproduzieren mit:

Code Auswählen Erweitern

{ $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...

[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]

@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 macht

Code Auswählen Erweitern

my $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:

Code Auswählen Erweitern

{ $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:

Code Auswählen Erweitern

{ $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

Code Auswählen Erweitern

{ $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.

[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

[rudolfkoenig]

@andre: \x{263A} ist zwar reinstes ASCII, erzeugt intern aber einen Wide-Character, die Laenge ist also 1

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

geht:

Code Auswählen Erweitern

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

oder mit binmode:

Code Auswählen Erweitern

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.

[justme1968]

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.