Parameter setzen bei ism7mqtt

[fhem024]

Hallo Beta-User,
meinst Du den Trace im MQTT2-Server? Da lese ich schon lange mit

Sieht so aus:
10:35:25.055 SENT  Wolf/192.168.3.117/DHK_BM-2_0x35/set/Normaussentemperatur_Heizkurve   -12
10:36:34.258 Wolf_1921683117 Wolf/192.168.3.117/DHK_BM-2_0x35 {"Normau\u00DFentemperatur Heizkurve":-12}

Wobei, wenn man auf das Json klickt, bekommt man eine korrekt codierte Anzeige - wobei es besser ist, die nicht korrekt codierte Anzeige zu bekommen - weil das ja am Ende das ist, was dann auch in der DB steht bzw. ansonsten zu nutzen ist.

Code Auswählen Erweitern

{
  "Normaußentemperatur Heizkurve": -12
}


[Beta-User]

Hmmm, eigentlich sollte das passen; wie sind die Events dazu?

(Grummel, ich hasse diesen unicode-Mist in MQTT)

[fhem024]

Ja, kann ich nachvollziehen. Ich bin zeitlich gerade aber etwas unter Druck. Ich debugge das Ganze später mal und gebe Dir hier Bescheid, sobald ich was gefunden habe bzw. mehr weiß. Ist das ok für Dich?

[Beta-User]

Kein Ding, ist ja "dein Problem"  .

[fhem024]

Ich habe mir das jetzt mal genauer angeschaut (verbose 5 in global). Habe ich aber auch keine brauchbaren Infos dazu gesehen. Der Mappingmechanismus scheint nicht geloggt zu werden. Ich habe testweise mal den Originalnamen (statt HK_NormAussen) als "sprechenden" Namen verwendet, der auch Teil der URL ist: DHK_BM-2_0x35_Normaussentemperatur_Heizkurve. Hat aber auch nichts gebracht. Ist bei mir aber auch der einzige set - Parameter, der mit negativen Werten belegt werden muss - das sollte ja aber nicht das Problem darstellen.
Vielleicht magst Du mir mal die Stelle im Code verraten, wo das Mapping stattfinden sollte, dann kann ich da ja mal selbst schauen, wie ich das entsprechen debuggt bekomme.


Danke
fhem024

[Beta-User]

Mappingmechanismus scheint nicht geloggt

Er ist Teil von json2nameValue() (aus fhem.pl) und wird über MQTT2_DEVICE (dort: MQTT2_DEVICE_Parse, der Teil um AnalyzePerlCommand() herum) aufgerufen.

[fhem024]

Danke Beta-User,

ich habe jetzt mal Zeit gefunden, mir das näher anzusehen. Ich habe mir eine neue FHEM-Instanz angelegt (die Demo-Config) und da den MQTT2-Server aktiviert. Mit mqttcli habe ich eine nachgestellte Message geschickt:

Code Auswählen Erweitern

mqtt pub -i Wolf_1921683117 --message-file mqtt.file -V 3 -t "Wolf/192.168.3.117/BM-2_0x35" -h 127.0.0.1

Das message file enthält in utf8-Kodierung:

Code Auswählen Erweitern

{"Rücklauftemperatur":"15"}

file mqtt.file
mqtt.file: UTF-8 Unicode text, with no line terminators


Das kommt im FHEM-Server jetzt komplett anders an:

Im MQTT-Trace:

Code Auswählen Erweitern

{
  "R(195)(188)cklauftemperatur": "15"
}

In der Readinglist:
BM-2_0x35_R__cklauftemperatur


Der Datensatz aus ism7mqtt sieht aber so aus (im mqtt-Trace):

Code Auswählen Erweitern

{"R\u00FCcklauftemperatur":24}

Warum wird das Unicode-Zeichen einmal im unicode code point angezeigt und einmal in utf8 dec?

Danke
Gruß
fhem024

[Beta-User]

Warum wird das Unicode-Zeichen einmal im unicode code point angezeigt und einmal in utf8 dec?

Keine (wirkliche) Ahnung, vielleicht hilft dir https://forum.fhem.de/index.php?topic=126088.0 weiter?

M.E. solltest du versuchen, den ganzen Sonderzeichen-Mist bereits auf der ism7mqtt-Seite zu beseitigen, wie auch immer das ggf. gehen mag.

[fhem024]

Moin Beta-User,

mal ein Zwischenstand.

M.E. solltest du versuchen, den ganzen Sonderzeichen-Mist bereits auf der ism7mqtt-Seite zu beseitigen

Ja, wenn das kein C# Code wäre, würde ich das tatsächlich machen. Ich habe aber keine entsprechende Umgebung auf Linux, um das ganze zu übersetzen. Außerdem scheint mir da im Source auch der Build-Part zu fehlen.

Ich habe mir daher mal den Perlcode von fhem angeschaut (ist für mich der deutlich geringere Aufwand), um zu lokalisieren, wo das ganze nicht so läuft, wie erwartet.
Dabei ist mir aufgefallen, dass in makeReadingName Umlaute ersetzt werden durch ae, ... - ich habe das mal für Großbuchstaben noch ergänzt:

Code Auswählen Erweitern

diff --git a/fhem.pl b/fhem.pl
index c75d22b..5c8686e 100755
--- a/fhem.pl
+++ b/fhem.pl
@@ -6198,8 +6216,11 @@ makeReadingName($) # Convert non-valid characters to _
    return $name;
  }
  my %umlaut = ( '\xc3\xa4'=>'ae',
+                '\xc3\x84'=>'Ae',
                  '\xc3\xb6'=>'oe',
+                '\xc3\x96'=>'Oe',
                  '\xc3\xbc'=>'ue',
+                '\xc3\x9c'=>'Ue',
                  '\xc3\x9f'=>'ss');
  map { $name =~ s/$_/$umlaut{$_}/g } keys %umlaut;
  $name =~ s/[^a-z0-9._\-\/]/_/gi;

Das Problem ist aber, dass in meinem konkreten Fall diese Umsetzung nicht stattfindet, weil in der Funktion json2nameValue (ich habe hier ein json als Input) davor alle Umlaute rausgeschmissen werden und durch _ ersetzt werden. Wenn man das wie unten vorgeschlagen anpasst, kommen die Umlaute tatsächlich bis makeReadingName und können dort umgeschrieben werden (genauso wie nicht json-basierte ReadingNames nehme ich mal an - sonst gäbe es ja die Funktion makeReadingName nicht). Das habe ich auch noch für Großbuchstaben und das HTML-Gedöns(?) ergänzt:

Code Auswählen Erweitern

diff --git a/fhem.pl b/fhem.pl
index c75d22b..5c8686e 100755
--- a/fhem.pl
+++ b/fhem.pl
@@ -5455,7 +5465,16 @@ json2nameValue($;$$$$)
      my $in2 = $val;
      while($in2 =~ m/^\s*"([^"]*)"\s*:\s*(.*)$/s) { # 125340
        my ($name,$val) = ($1,$2);
-        $name =~ s/[^a-z0-9._\-\/]/_/gsi;
+
+        $name =~ s/\\u00FC/ü/gsi;
+        $name =~ s/\\u0308/ö/gsi;
+        $name =~ s/\\u00E4/ä/gsi;
+        $name =~ s/\\u00DC/Ü/gsi;
+        $name =~ s/\\u00C4/Ä/gsi;
+        $name =~ s/\\u00D6/Ö/gsi;
+        $name =~ s/\\u00DF/ß/gsi;
+
+        $name =~ s/[^a-z0-9äöüßÄÖÜ._\-\/]/_/gsi;
        ($err,$in2) = eObj(\%r2, $name, $val, $in2, $prefix);
        return ($err,undef) if($err);
        $in2 =~ s/^\s*,\s*//;

Durch Anpassen von json2nameValue wäre das ganze Handling zumindest mal konsistenter aus meiner Sicht. Die ganzen jsonMappings sind dann auch nicht mehr nötig, weil das ja dann schon intern abgefackelt wird und gleich behandelt wird, wie die nicht Json basierten Readings. Quasi eine Normierung auf den gleichen Stand. Das funktioniert auch (erfolgreich getestet ohne die jsonMappings).

Bis zu dem Punkt json2nameValue laufen die utf8 Strings eigentlich sauber durch. Ich habe spaßeshalber mal die ganzen Mappings rausgenommen (auch aus makeRedaingName). Das hat eigentlich problemlos funktioniert (getestet bis zur Anzeige natürlich nur). Ich würde mal davon ausgehen, dass die dann auch an anderer Stelle sauber laufen.

Leider fixt das das Problem mit dem "ß" im ursprünglichen Namen immer noch nicht (beim Setter). Beim Ändern der Normaussentemperatur wird zwar das Reading

Code Auswählen Erweitern

HK_NormAussen  set -12

korrekt angelegt. Aber die Vorbelegung in

Code Auswählen Erweitern

HK_NormAussen:slider,0,1,-24 Wolf/192.168.3.117/DHK_BM-2_0x35/set/Normaussentemperatur_Heizkurve
funktioniert immer noch nicht (obwohl der Wert im Zielsystem korrekt gesetzt wurde). Da muss ich mal noch weitersuchen.

Danke
Gruß
fhem024

[fhem024]

Weiteres Update:

Das Vorbelegungsthema (HK_Normaussen:slider,0,1,-24) hat sich erledigt. Nachdem ich gesehen habe, dass der vorbelegte Wert korrekt abgerufen wird zur Laufzeit, musste das Problem ja woanders liegen. War wie üblich: kaum macht man es richtig, schon funktioniert es:

HK_Normaussen:slider,0,1,-24 -> HK_Normaussen:slider,-24,1,0

Abgesehen von der Vorbelegung hat der einwandfrei funktioniert. Grrrr.


Danke
Gruß
fhem024

[rudolfkoenig]

Warum wird das Unicode-Zeichen einmal im unicode code point angezeigt und einmal in utf8 dec?

Die (..) Notation kommt vom MQTT2_SERVER/CLIENT, ich habe da diese Notation verwendet, als ich die Rohdaten der MQTT-Nachricht ausgegeben habe.
Bin unsicher, ob es im Monitor sinnvoll ist. Ich koennte es ausbauen, falls gewuenscht.
Die \u... Notation kommt genau so von ism7mqtt, wobei \u00FC eine gueltige JSON-Kodierung von Unicode Zeichen ist.

Dabei ist mir aufgefallen, dass in makeReadingName Umlaute ersetzt werden durch ae, ... - ich habe das mal für Großbuchstaben noch ergänzt:

Das habe ich jetzt uebernommen.

Wenn man das wie unten vorgeschlagen anpasst, kommen die Umlaute tatsächlich bis makeReadingName und können dort umgeschrieben werden

Das geht nicht so einfach, erstens ist das zu selektiv, zweitens ignoriert das encoding Attribut.
json2nameValue hat bisher die Schluessel in einem JSON nicht korrekt dekodiert, aber die Strings.
Ich habe jetzt die String-Dekodierung fuer die Schluessel angewendet.

Mit

Code Auswählen Erweitern

mosquitto_pub -i hallo -t test -m '{"\u00FC":"\u00FC"}'
sehe ich im neu angelegten Geraet hallo ein Reading mit dem Namen ue und dem Wert ü.

[fhem024]

Hallo Rudolf,

Die (..) Notation kommt vom MQTT2_SERVER/CLIENT, ich habe da diese Notation verwendet, als ich die Rohdaten der MQTT-Nachricht ausgegeben habe.
Bin unsicher, ob es im Monitor sinnvoll ist. Ich koennte es ausbauen, falls gewuenscht.

Nein - lass es drin. Es geht ja gerade darum, dass man das ungeschminkte Original zu Gesicht bekommt (für Debug-Zwecke ist das relevant). Ich wünsche jedenfalls nicht, dass es rauskommt .

json2nameValue hat bisher die Schluessel in einem JSON nicht korrekt dekodiert, aber die Strings.

Das ist mir auch schon aufgefallen. Ich wollte da aber nicht zu tief eingreifen. Könnte ja einen Grund gehabt haben. Wenn Du die Dekodierung der Schlüssel jetzt identisch machst ist das lediglich konsequent.

Bedeutet das, dass von nun an auch die Schlüssel nicht mehr umgeschrieben werden von ü -> ue z.B. (wie bei den Werten ja schon heute)? Das wäre zumindest für mich blöd, weil ich jetzt schon alle Schlüssel auf ue, ... habe und dann alles wieder anpassen müsste.

Update 1.12.24:
Ich habe den Change mal getestet. Funktioniert schön. Die Umsetzung der Umlaute im Key zu z.B. ae erfolgt, im Value bleiben sie erhalten - letzteres wie vorher auch - da hat sich ja auch nichts geändert.



Danke!
Gruß
fhem024

[rudolfkoenig]

Ich musste json2nameValue wegen dem Problem, was hier: https://forum.fhem.de/index.php?topic=139923.msg1326861#msg1326861 beschrieben wurde nochmal anfassen.
Ich hoffe, dass es trotzdem noch richtig funktioniert, bitte (wenn moeglich) um Feedback/Bestaetigung.

[cryptik]

Dein Update funktioniert und behebt die Problematik, welche ich angesprochen hatte.
Sollte mir noch etwas andere negatives (Side Effekte) auffallen, werde ich natürlich direkt eine Rückmeldung geben.

[fhem024]

Ich hoffe, dass es trotzdem noch richtig funktioniert, bitte (wenn moeglich) um Feedback/Bestaetigung.

Mir ist (in meiner Testumgebung) auch nichts aufgefallen. Passt soweit!

Danke
Gruß
fhem024