Autor Thema: FHEM und UNICODE, first aid  (Gelesen 11833 mal)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25818
Antw:FHEM und UNICODE, first aid
« Antwort #75 am: 20 Februar 2022, 21:00:16 »
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.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18513
Antw:FHEM und UNICODE, first aid
« Antwort #76 am: 20 Februar 2022, 21:03:43 »
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.
-----------------------
Möchte man beruflich "etwas mit Menschen" machen, ohne etwas mit deren Dummheit zu tun haben zu müssen,
bleibt eigentlich nur der Beruf des Bestatters übrig.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25818
Antw:FHEM und UNICODE, first aid
« Antwort #77 am: 20 Februar 2022, 21:09:28 »
Zitat
den 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.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6131
Antw:FHEM und UNICODE, first aid
« Antwort #78 am: 20 Februar 2022, 22:16:38 »
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.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25818
Antw:FHEM und UNICODE, first aid
« Antwort #79 am: 21 Februar 2022, 10:06:58 »
Zitat
Die 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.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6131
Antw:FHEM und UNICODE, first aid
« Antwort #80 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. 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.
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline Adimarantis

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 801
Antw:FHEM und UNICODE, first aid
« Antwort #81 am: 21 Februar 2022, 13:43:19 »
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)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19310
Antw:FHEM und UNICODE, first aid
« Antwort #82 am: 21 Februar 2022, 13:45:46 »
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-T620@Debian 11, 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

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18513
Antw:FHEM und UNICODE, first aid
« Antwort #83 am: 21 Februar 2022, 14:31:02 »
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.

anscheinend bin ich mit den Verständnisproblemen ja nicht alleine...

Nein, bist Du nicht.
-----------------------
Möchte man beruflich "etwas mit Menschen" machen, ohne etwas mit deren Dummheit zu tun haben zu müssen,
bleibt eigentlich nur der Beruf des Bestatters übrig.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18513
Antw:FHEM und UNICODE, first aid
« Antwort #84 am: 21 Februar 2022, 18:23:35 »
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:

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!
-----------------------
Möchte man beruflich "etwas mit Menschen" machen, ohne etwas mit deren Dummheit zu tun haben zu müssen,
bleibt eigentlich nur der Beruf des Bestatters übrig.
-----------------------
Lesen gefährdet die Unwissenheit!
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25818
Antw:FHEM und UNICODE, first aid
« Antwort #85 am: 21 Februar 2022, 19:28:46 »
Zitat
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:
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.

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

Offline Benni

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2442
  • FHEMinist
Antw:FHEM und UNICODE, first aid
« Antwort #86 am: 21 Februar 2022, 20:19:18 »
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
« Letzte Änderung: 21 Februar 2022, 21:04:42 von Benni »

Offline Benni

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2442
  • FHEMinist
Antw:FHEM und UNICODE, first aid
« Antwort #87 am: 21 Februar 2022, 20:35:28 »
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#

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4358
    • HMCCU
Antw:FHEM und UNICODE, first aid
« Antwort #88 am: 21 Februar 2022, 20:45:55 »
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, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach
Zustimmung Zustimmung x 1 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18513
Antw:FHEM und UNICODE, first aid
« Antwort #89 am: 21 Februar 2022, 20:59:11 »
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)
-----------------------
Möchte man beruflich "etwas mit Menschen" machen, ohne etwas mit deren Dummheit zu tun haben zu müssen,
bleibt eigentlich nur der Beruf des Bestatters übrig.
-----------------------
Lesen gefährdet die Unwissenheit!
Gefällt mir Gefällt mir x 2 Liste anzeigen