FHEM und UNICODE, first aid

Begonnen von herrmannj, 08 Februar 2022, 19:28:02

Vorheriges Thema - Nächstes Thema

Adimarantis

#45
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:
defmod TabletUI HTTPSRV frontend/ ./www/tablet Tablet
Wenn ich jetzt ganz einfach ein Bild via HTTPSRV hole:
http://x.x.x.x:8083/fhem/frontend/cam3.jpg
Dann wird die Binärdatei anscheinend konvertiert und ist kaputt.
Gehe ich direkt auf die URL
http://x.x.x.x:8083/fhem/www/tablet/cam3.jpg
dann wird das Bild korrekt angezeigt.

Edit: Ich verwende fhem.cfg und habe diese mit Notepad++ nach UTF8+BOM konvertiert was gut funktioniert hat
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

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.
{my $abc=1;
print $abc;
}

Beim Speichern kommt der Fehler:
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.
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

betateilchen

Zitat von: rudolfkoenig am 19 Februar 2022, 10:56:24
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#48
Zitat von: Adimarantis am 19 Februar 2022, 12:18:56
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

herrmannj

Zitat von: rudolfkoenig
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.
ZitatIch 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

Zitat von: Benni am 19 Februar 2022, 21:17:52
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.


<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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Benni

#52
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:


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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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

#55
Zitat von: herrmannj am 20 Februar 2022, 14:45:10
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.

Zitat von: herrmannj am 20 Februar 2022, 14:45:10
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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

#57
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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.