FHEM und UNICODE, first aid

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

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Ja, ein aktuelles vi (bzw. vim) liest die Datei durch, und stellt automatisch ein Encoding ein.
Besonders lustig bei Dateien mit gemischten Encoding, wie bei einem FHEM Logfile, was Umlaeute enthaelt vor und nach Umstellen des encoding Attributes. Ich bin auch staendig mit xxd unterwegs, um den eigentlichen Inhalt festzustellen.

Damit node latin1 als Befehlsinput akzeptiert, muesste man per Kommandozeile oder Befehl das Encoding parametirisieren, ala "encoding latin1" in FHEM telnet. Ich habe aber nichts Vergleichbares gefunden.

betateilchen

Zitat von: rudolfkoenig am 20 Februar 2022, 19:39:28
diese Aufgabe wird dem Benutzer (bzw. attrTemplate) ueberlassen. Ich habe meinen Zweifel, dass das weniger Support bedeutet.
...
Sowas kann ich aber nicht dem durchschnittlichen FHEM-Benutzer ueberlassen, noch dazu, dass das bisher nicht notwendig war.

Protokollerklärung: Es soll durchaus Anwender geben, die MQTT2 verwenden, aber nicht mit attrTemplate arbeiten, weil dabei auch nicht immer zwingend die Ergebnisse rauskommen, die man als Anwender haben möchte.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitatden satz verstehe ich nicht.
Ich meinte JSON.parse nimmt kein UTF-8 bytestream (aka Buffer, das was bei MQTT als payload ankommt), sondern ein Javascript String. D.h. wenn man im Node ueber MQTT JSON empfaengt, dann muss man vor dem Aufruf von JSON.parse() die Daten mit buffer.toString('utf8') oder Vergleichbares explizit konvertieren.
Diesen Schritt will ich dem FHEM-Benutzer nicht aufzwingen.

herrmannj

JSON:PP #111
sub decode_json { # decode
    ($JSON ||= __PACKAGE__->new->utf8)->decode(@_);
}

JSON:PP #729
        if ( $utf8 ) {
            $encoding = _detect_utf_encoding($text);
            if ($encoding ne 'UTF-8' and $encoding ne 'unknown') {
                require Encode;
                Encode::from_to($text, $encoding, 'utf-8');
            } else {
                utf8::downgrade( $text, 1 ) or Carp::croak("Wide character in subroutine entry");
            }
        }
        else {
            utf8::upgrade( $text );
            utf8::encode( $text );
        }

Die professionellen JSON Decoder können das. Kein user muss da was tun. Bitte nimm doch das $lval = Encode::encode('UTF-8', $val); wieder raus. Wichtig ist, dass json2nameValue das konvertieren richtig macht.

rudolfkoenig

ZitatDie professionellen JSON Decoder können das.
Dann bin ich sicher, dass sie auch mit Unicode umgehen koennen, nicht nur mit Bytestreams.

Ich habe jetzt fuer beide MQTT2 IO-Module das Attribut binaryTopicRegexp eingefuehrt, damit kann man Ausnahmen definieren.

herrmannj

es fällt mir schwer angesichts der Ignoranz den Fakten gegenüber neutral zu sein: Du hast gesagt das eine Umstellung problematisch ist, und ich sehe Du findest Wege genau diesen Zustand zielsicher aktiv herbeizuführen.

Unter dem Vorwand der user würde nicht wissen welche Daten mqtt bringt führst Du ein Attribut ein wo er das einstellen muss. Btw, ich habe eine deutlich bessere Meinung über die Benutzer. Unter dem Vorwand "weniger Supportaufwand" machst Du genau das Gegenteil: ab jetzt muss man den user also im Fehlerfall fragen ob das attribut gesetzt ist, falls ja wie. Nebenbei bemerkt, alles irrelevant denn auf mqtt Values gabs (bisher) kaum Probleme. Jetzt schon.

Der ursprüngliche Post hier, ist als Hilfe für Modulautoren gedacht.

Adimarantis

Das "save" bei Attributwechsel hängt tatsächlich davon ab ob man autosave=1 gesetzt hat.
Mehrzeile Attribute funktionieren jetzt.

Für meine Konfiguration gibt es eigentlich nur noch zwei Blocking Points:

1. HTTPSRV macht Binärdateien kaputt (z.B. Icons, JPGs)
2. UPD bricht ab sobald ein Modul mit Sonderzeichen dabei ist, weil die Prüfung der Länge fehlschlägt, zum Beispiel:

UPD FHEM/37_echodevice.pm
Got 252067 bytes for FHEM/37_echodevice.pm, expected 252243
Raspberry 4 + HM-MOD-RPI-PCB (pivCCU) + RfxTrx433XL + 2xRaspberry 1
Module: 50_Signalbot, 52_I2C_ADS1x1x , 58_RPI_1Wire, (50_SPI_MAX31865)

Beta-User

Zitat von: herrmannj am 10 Februar 2022, 18:57:11
ich wollte dir nicht zu Nahe treten, das war kein Vorwurf. Du bist gerade dass Beispiel dass man unicode Support benötigt und es keinesfalls nur darum geht ob ein smiley 1 oder 4 Zeichen lang ist. Der mangelnde support im framework ist das Problem. Zu Deiner Frage: es gibt keine einfache Antwort. Solange fhem das nicht unterstützt kannst Du die Workarounds nicht beseitigen sondern musst immer mehr davon einbauen.
Hatte ich auch nicht als solchen aufgefasst, und ich habe auch keine allzugroßen Probleme damit, den "DAM" zu mimen, anscheinend bin ich mit den Verständnisproblemen ja nicht alleine...

Zwei Anmerkungen vom DAM:
- Ihr habt mich weiter ziemlich verwirrt zurückgelassen; nachdem ich verstanden zu haben glaubte, dass es sinnvoll ist, die in meinen Fällen relevanten JSON-Daten einfach ohne Änderung des encodings durchzuschleusen (so ist der aktuelle RHASSPY-Code jetzt auch gestrickt), muss man jetzt die neue globale Variable beachten und wenn ja, doch was umcoden. OK, vermutlich halbwegs "gefressen", auch wenn mir das jetzt unnötig kompliziert vorkommt...
- Was attrTemplate angeht, sprechen wir doch vorrangig von mqtt2.template. Auch wenn es lästig sein wird, ggf. irgendwas auf "Einzeldevice-Ebene" zu fixen: Lieber eine Lösung, die "richtig" ist und ggf. eine 2. Variante von json2nameValue() braucht oder irgendwelche Fallunterscheidungen, wie ewige Flickschusterei. Im Zweifel werden sich kompetente User finden, die die notwendigen Fixes beisteuern, im Zweifel ist das eine harte Hauruck-Aktion, aber das bekommen wir notfalls hin...

(OT: Wer Verbesserungsbedarf sieht, kann den gerne im Klartext an passender Stelle benennen. Vieles ist "halt so no wora" und auch aus meiner Sicht nicht unbedingt immer perfekt oder voll "ausentwickelt", und ich finde auch immer mal wieder noch irgendeinen "Klopper" und/oder Dinge, die man heute anders lösen würde (bzw. erst heute anders lösen könnte). Ist halt so... Der Ist- Zustand ist jedenfalls m.E. deutlich besser wie vieles, was mir im Lauf der Zeit zu MQTT-alt an "Lösungen" über den Weg gelaufen ist.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Zitat von: herrmannj am 21 Februar 2022, 11:50:06
es fällt mir schwer angesichts der Ignoranz den Fakten gegenüber neutral zu sein: Du hast gesagt das eine Umstellung problematisch ist, und ich sehe Du findest Wege genau diesen Zustand zielsicher aktiv herbeizuführen.

Unter dem Vorwand der user würde nicht wissen welche Daten mqtt bringt führst Du ein Attribut ein wo er das einstellen muss.
...

Danke für diesen wertvollen Beitrag! Ich sehe das weitgehend genau so.
Sowohl als user wie auch als developer.

Zitat von: Beta-User am 21 Februar 2022, 13:45:46
anscheinend bin ich mit den Verständnisproblemen ja nicht alleine...

Nein, bist Du nicht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: herrmannj am 20 Februar 2022, 13:59:12
da der TE das file einliest, ist der TE dafür verantwortlich dass die Daten korrekt eingelesen werden. Generell: attr UNICODE setzen. Beim einlesen: wenn die Daten utf8 kodiert sind (hier der fall), als utf8 einlesen (dann wandelt perl selber das in text), oder als binary einlesen und nach dem einlesen von manuell von utf8 nach text umwandeln.

Den wenigen (weniger als eine Handvoll!) Leuten, die sich hier gerade beim Thema Zeichencodierung austoben, ist hoffentlich bewusst, dass es durchaus eine Vielzahl von FHEM Anwendern gibt, die (aus welchen Gründen auch immer, sei es altersbedingt oder weil nicht jeder beruflich mit Programmierung und EDV zu tun hat) mit solch einer Antwort wenig anfangen können?

Es fängt schon damit an:

Zitat von: herrmannj am 20 Februar 2022, 13:59:12
Generell: attr UNICODE setzen.

Der arme Benutzer ist wahrscheinlich jetzt immer noch erfolglos auf der Suche, wo er das genannte Attribut findet.
Es sei denn, er hat inzwischen aufgegeben...

Auch wenn "Cloud" im Moment in aller Munde ist - könnt Ihr bitte mal wieder von Eurer Wolke runterkommen und eine solch tiefgreifende Änderung in FHEM so dokumentieren und kommunizieren, dass auch ein Normaluser versteht, was er künftig tun muss, wenn er beispielsweise irgendwelche Daten, die er per HTTPMOD bekommt, vernünftig angezeigt haben möchte?

FHEM ist nicht (nur) für Entwickler da!
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitat1. HTTPSRV macht Binärdateien kaputt (z.B. Icons, JPGs)
2. UPD bricht ab sobald ein Modul mit Sonderzeichen dabei ist, weil die Prüfung der Länge fehlschlägt, zum Beispiel:
Ich meine beide Probleme behoben zu haben.

@betateilchen: "encoding unicode" ist fuer mich immer noch EXPERIMENTELL.
Ob das jemals die Voreinstellung wird, wird sich zeigen.
Immerhin gibt es jetzt in meinen Modulen eine Menge Spezialbehandlung und zusaetzlichen Code.

ZitatDanke für diesen wertvollen Beitrag! Ich sehe das weitgehend genau so.
Ich gehe davon aus, dass Ihr den Beitrag nicht verstanden habt.
Die Ausnahmen mit dem binaryTopicRegep Attribut sind fuer Binaerdaten notwendig.
Die Alternative ist die manuelle Konvertierung des MQTT-Payloads durch den Benutzer wenn es nicht binaer ist, was mAn die Mehrzahl der Daten ist.
Wenn die weiterverarbeitende Funktion (wie der professionelle JSON Parser) das Raten der Kodierung uebernimmt, dann sind beide Alternativen gleichwertig.

Benni

#86
Zitat von: Benni am 20 Februar 2022, 13:57:36
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.

Die Falschdarstellung ist nach einem FHEM-Neustart wieder da.
Sobald ich das "ü" über den Link AdditionalCss beim F18-Style wieder manuell korrigiere ist alles i.O. bis zum nächsten Neustart (trotz vorherigem Save!)

Wenn ich die Anpassung am FHEMWEB-Device über das Css-Attribut vornehme, zerhagelt es mir das komplette CSS darin, es gehen sämtliche NewLines verloren, bzw. werden durch irgendein Spezial-Zeichen ersetzt (s. CSS-Auszug im Screenshot)

Die Bearbeitung im Attribut erfolgt dabei übrigens mittels Codemirror (könnte ja relevant sein?)

Edit: Codemirror ist hier wohl eher nicht relevant, denn die Spezialzeichen stehen auch schon im normalen Attribut-Eingabe-Feld, also auch schon vor der eigentlichen Bearbeitung mit Codemirror, bzw. auch dann wenn die Codemirror-Bearbeitung mittels Cancel abgebrochen wird.

Gruß Benni

Benni

FHEM-Update funktioniert jetzt bei mir auch nicht mehr:


2022.02.21 20:33:04 1 : Downloading https://fhem.de/fhemupdate/controls_fhem.txt
2022.02.21 20:33:04 1 : UPD ./CHANGED
2022.02.21 20:33:04 1 : Got 377272 bytes for ./CHANGED, expected 377299
2022.02.21 20:33:04 1 : aborting.


gb#

zap

Ich habe ehrlich gesagt komplett den Faden verloren. Keine Ahnung, ob und wenn ja was ich in meinen Modulen ändern muss (oder soll?).

Ich warte also mal ab, ob irgendwann ein kleines Howto für Entwickler und Anwender veröffentlicht wird.

2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

betateilchen

Zitat von: zap am 21 Februar 2022, 20:45:55
Ich warte also mal ab,

Willkommen im Club.
Zum Glück sind im Wartezimmer genug bequeme Sessel vorhanden und Popcorn ist auch genügend da  8)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!