FHEM und UNICODE, first aid

[Adimarantis]

Nochmal probiert: Attribut geändert -> automatischer Neustart -> Attribut hat alten Wert

Aktuell habe ich eigentlich nur noch das Problem mit dem alten FTUI - dort sind sämtiche Icons/Bilder kaputt.
Ich habe folgendes definiert:

Code: [Auswählen]

defmod TabletUI HTTPSRV frontend/ ./www/tablet TabletWenn ich jetzt ganz einfach ein Bild via HTTPSRV hole:

Code: [Auswählen]

http://x.x.x.x:8083/fhem/frontend/cam3.jpgDann wird die Binärdatei anscheinend konvertiert und ist kaputt.
Gehe ich direkt auf die URL

Code: [Auswählen]

http://x.x.x.x:8083/fhem/www/tablet/cam3.jpgdann wird das Bild korrekt angezeigt.

Edit: Ich verwende fhem.cfg und habe diese mit Notepad++ nach UTF8+BOM konvertiert was gut funktioniert hat

[Adimarantis]

Und leider noch ein Problem (ist mir mit den DOIF cards aufgefallen lässt sich aber auch so nachstellen):
Für ein beliebiges Device das stateFormat Attribut editieren (so dass man den Editor bekommt) und mehrzeiligen Perlcode eingeben, z.B.

Code: [Auswählen]

{my $abc=1;
print $abc;
}Beim Speichern kommt der Fehler:

Code: [Auswählen]

ERROR evaluating my $name=   $evalSpecials->{'%name'};{return undef; {my $abc=1;␤print $abc;␤}␤}: Unrecognized character \x{2424}; marked by <-- HERE after my $abc=1;<-- HERE near column 64 at (eval 15241) line 1.
Liegt nachvollziehbar an den Newlines die nach Unicode 0x2424 gewandelt werden.
Mit dem Editor bei einem DEF (z.B. wieder DOIF) passiert das nicht.

[betateilchen]

verwendest Du configDB?
Wenn ja: das funktioniert noch nicht.
Wenn nicht: kannst Du mir was zum Nachstellen zeigen?
Ich habe save gestern eigentlich getestet. Meine ich jedenfalls

@Rudi: wenn Du hier die Meinung vertrittst, dass "das" (was eigentlich?) bei configDB "noch nicht funktioniert", solltest Du mir bitte was zum Nachstellen geben, damit ich ein eventuell vorhandenes Problem beheben kann.

Du erwartest ja auch immer ein Beispiel zum Nachstellen.

[betateilchen]

Nochmal probiert: Attribut geändert -> automatischer Neustart -> Attribut hat alten Wert

Edit: Ich verwende fhem.cfg

Das Speichern des Attributes funktioniert nicht nur bei fhem.cfg nicht, sondern auch bei configDB nicht.
Der Neustart wird aber durchgeführt.


Edit:

Das Problem beim Speichern liegt vermutlich im Zusammenspiel mit dem globalen Attribut "autosave".
Bei mir stand das auf 0. Nachdem ich das Attribut gelöscht habe, wird beim Setzen des Attributes "encoding" das Speichern ausgeführt und ist nach dem anschließenden automatischen Neustart auch wieder vorhanden.

[herrmannj]

Stimmt, value kann auch binary sein.
Das macht mich aber ratlos, da mAn die Konvertierung im JSON-Parser falsch ist: woher soll mein Parser wissen, woher die Daten kommen? Sie koennen intern erzeugt sein oder ueber HTTP/HTML kommen, wo die Kodierung festgelegt  und durchgefuehrt ist.
Ich bin auch sicher, dass etliche Gadgets in "einfachen" MQTT-Values (nicht Json-kodiert) UTF-8 verschicken.
Faellt Dir eine generische Loesung fuer die Konvertierung in MQTT ein?

Du läufst zu weit Den topic zu decodieren_ist_ deine Aufgabe. Den playload zu dekodieren _ist  nicht_ deine Aufgabe. Falls es sich um JSON handelt (gefühlt 2/3 der Fälle) ist das die Aufgabe des JSON decoders. Das verbleibende  geschätzte 1/3, da bleibt es so wie es heute ist. Ob dort konvertiert werden muss (überhaupt nur wenn utf8 _und_ Sonderzeichen) bestimmt nur der Kontext. Dafür soll der user eine Funktion utf8_to_text haben.

Ich bin zunehmend von meiner urpruenglichen "bytestream" Loesung begeistert.

Das fühlt sich nur im Umbruch so an.

[Benni]

Ich habe mein Testsystem jetzt auch mal auf unicode umgestellt.

Fürs erste scheint alles erst mal zu funktionieren, wobei mein Testsystem jetzt auch nicht so umfangreich ist.

Das einzige was mir spontan aufgefallen ist: Egal in welchem Bereich ich in FHEMWEB bin (Menüauswahl/Räume) Wird mir im Titel vom Menü das "ü" falsch dargestellt. Einzig wenn ich auf den Menüeintrag "Logfile" gehe, dann wird es korrekt angezeigt.

gb#

[betateilchen]

Das einzige was mir spontan aufgefallen ist: Egal in welchem Bereich ich in FHEMWEB bin (Menüauswahl/Räume) Wird mir im Titel vom Menü das "ü" falsch dargestellt. Einzig wenn ich auf den Menüeintrag "Logfile" gehe, dann wird es korrekt angezeigt.

So einen ähnlichen Effekt habe ich an einer einzigen Stelle mit stateFormat, da soll eine Temperatur mit °C angezeigt werden.

Code: [Auswählen]

<td informId="owo">
   <div id="owo" title="5.4 °C / 94 %" class="col2">5.4 °C / 94 %</div>
</td>

Ansonsten konnte ich nach der Umstellung auf unicode noch keine weiteren Anzeigeprobleme feststellen.

[Benni]

Ich habe gerade festgestellt, dass es mir inzwischen auch bei der Anzeige des LogFile nicht mehr korrekt angezeigt wird.

Edit:

Jetzt habe ich mal nachgeschaut, wo das "Menü" eigentlich herkommt.

Das kommt bei mir aus dem Css-Attribut vom FHEMWEB-Device, bzw. dem AdditionalCss des, dem FHEMWEB zugeordneten F18 Styles:

Code: [Auswählen]

div#menu > .col_header:before {
    content: "Menü";
}

Dort steht es also nach der Umstellung auf unicode auch falsch drin.
Nach nun erneuter Eingabe des "ü" ist die Anzeige nun wieder korrekt.


gb#

[betateilchen]

Ich bekomme das Problem im Attribut stateFormat nicht gelöst, gerade habe ich ein ähnliches Problem bei der Darstellung des € Zeichens im Attributwert festgestellt.
Wenn ich mit dem vorgeschlagenen Weg zu encoding bzw. decoding experimentiere, wird die Sache nur noch schlimmer.
Im Moment wird der Attributwert komplett verhunzt.

Könnte man GetDefAndAttr() in fhem.pl so gestalten, dass die Funktion bereits korrekt konvertierte Daten liefert?
Dann wäre die Konvertierung einheitlich für fhem.cfg und configDB gelöst und der Kram müsste einfach nur noch weggeschrieben werden.

[herrmannj]

schau mal bitte wo das Problem liegt (Eingabe oder Ausgabe).

Richtiges Verhalten: innerhalb fhem ist das € text. Wenn Du dort irgendwo length($x) einbaust muss das Ergebnis 1 für € lauten. In diesem Fall wäre das Problem die Ausgabe. GetDefAndAttr() sollte Deiner Meinung nach text oder utf8 liefern?

[betateilchen]

Richtiges Verhalten: innerhalb fhem ist das € text.

Es wird aber schon in telnet falsch dargestellt:


Attributes:
   reading01Name state
   reading01OExpr $val=~s/,//g;$val=~s/\./,/;"$val â¬";
   reading01Regex <title>(.*).\(


Eigentlich sollte da "$val €" stehen.

GetDefAndAttr() sollte Deiner Meinung nach text oder utf8 liefern?

woher soll ich das wissen?

GetDefAndAttr() liefert mir ein array mit Textzeilen, die ich in die Datenbank schreibe.
Genau so wie sie weggeschrieben werden, werden sie später wieder eingelesen und per AnalyzeCommandChain() verarbeitet.

Mehr habe ich damit eigentlich nicht zu tun.

[herrmannj]

wenn du in die DB schreibst, dann ist das Dein job dort richtig reinzuschreiben. Sprich, Du bekommst die Daten von fhem als text und schreibst die dann in der Kodierung in die DB welche die DB benötigt. Woher soll fhem denn wissen welche Kodierung die DB gern hätte? Rückwärts dito, alles was von Außen kommt wird von X nach text gewandelt.

[betateilchen]

Inzwischen habe ich sämtliche Konvertierungskombinationen beim Schreiben und Lesen durchgetestet - ohne Erfolg.
Bisher hat die Kodierung beim Schreiben und Lesen "einfach so" gepasst, es gab bezüglich Zeichenkodierung noch keine Fehlermeldung hier im Forum.

Warum wird das jetzt alles so viel komplizierter gemacht und absichtlich potenzelle Fehler- und Problemstellen geschaffen?

An einigen Stellen kann ich überhaupt keine Konvertierung einbauen, weil die Mechanismen in configDB durchaus auch dafür vorgesehen sind, binäre Daten (z.B. bei Bilddateien) abzuspeichern. Eigentlich will ich mich einfach darauf verlassen können, dass ich mich um den Sinn und Zweck der Daten, die in der Datenbank landen, überhaupt nicht kümmern muss. Jeder andere Ansatz zerstört die bisher vollständig transparente Implementierung der Konfigurationsdatenbank.

[betateilchen]

Gar nicht so einfach, dieses Schei... Attribut "encoding" wieder loszuwerden.

Nachdem ich das aber geschafft habe, werde ich mich jetzt erstmal darum kümmern, warum meine mqtt Verbindungen in FHEM nicht mehr funktionieren...

[herrmannj]

wenn du zickst kann ich dir nicht helfen. Das binäre Daten gespeichert werden können ist absolut in Ordnung. Jeder webbrowser kann sowohl Text mit Sonderzeichen als auch Bilder darstellen. Attribute und Readings sind doch aber wohl text, die gehören passend zum Ausgabekanal kodiert. Wenn Du in der DB keine Unterscheidung durchführst (also alles raw ist), dann muss vor dem schreiben von text nach utf8 konvertiert werden.