Parameter setzen bei ism7mqtt

[fhem024]

Hallo zusammen,
ich habe ism7mqtt an MQTT2_SERVER angebunden (autocreate=complex). Alle Readings wurden im automatisch angelegten Device MQTT2_Wolf_1921683117 erstellt. Soweit so gut.

Jetzt würde ich gerne die Parameter nicht nur auslesen, sondern auch setzen. Ein angelegtes Reading ist z.B.:
TOB_0x8_Obere_Brennerleistung_Warmwasser

Folgende subscriptions meldet FHEM (im list):
subscriptions: Wolf/192.168.3.117/+/set
subscriptions: Wolf/192.168.3.117/+/set/#

Meine Frage ist nun: wie mache ich einen Wert schreibbar - z.B. den oben genannten TOB_0x8_Obere_Brennerleistung_Warmwasser? Leider habe ich nicht die geringste Idee, wo ich hier ansetzen kann / soll, obwohl ich schon diverse Dokumentationen gelesen habe.

ism7mqtt erwartet zum Setzen ein Json. Auf github wird folgendes Bsp. genannt:

Code Auswählen Erweitern

{
    "Programmwahl": {
        "360051": {
            "value": 0
        }
    }
}
oder
{
    "Programmwahl": {
        "360051": {
            "text": "Standby"
        }
    }
}

incl. Angabe des entsprechenden topics (könnte wohl das subscription in FHEM sein? Wobei das + aus den subscriptions dann wohl durch TOB_0x8 im konkreten Fall ersetzt werden muss?)

Ich wäre für jede Unterstützung dankbar!

Gruß
fhem024

[Beta-User]

Ich wäre für jede Unterstützung dankbar!

https://forum.fhem.de/index.php?topic=112327.0
Ohne (raw-) list (und uU. ohne den konkreten MQTT-Traffic) kann man wenig zu dem Ding sagen, siehe das Beispiel aus github: https://github.com/zivillian/ism7mqtt#example

"complex" ist vermutlich nicht hilfreich, das erzeugt imo in diesem Fall zu lange Readings, die man dann wieder mit jsonMap (siehe Attributhilfe dazu) auf "lesbare" Readings mappen müßte.

Siehe dazu auch https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt

[fhem024]

Hallo Beta-User,

ich bin mittlerweile mit setList weitergekommen:

Code Auswählen Erweitern

Warmwassersolltemperatur:slider,40,1,60 Wolf/192.168.3.117/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009
funktioniert schon mal.
Jetzt wäre noch spannend, wie man den slider (oder sonstige widgets) mit dem aktuellen Wert voreingestellt bekommt.

[Beta-User]

Jetzt wäre noch spannend, wie man den slider (oder sonstige widgets) mit dem aktuellen Wert voreingestellt bekommt.

jsonMap die einhunderste...

[fhem024]

Hallo Beta-User,

sorry, wenn ich scheinbar etwas begriffsstutzig bin. In wie weit mir jsonMap beim Vorbelegen eines Wertes in setList mit dem aktuellen Wert vorausgewählt helfen kann, ist mir nicht klar. Ich habe jsonMap verwendet, um Readings anzupassen (Umlaute rauszuwerfen). Glücklicherweise benötige ich die, soweit ich es sehe, nicht als setter.

Jetzt habe ich aber noch ein anderes Problem: Es gibt das Reading DHK_BM-2_0x35_Winter/Sommer_Umschaltung. Daraus würde der Befehl

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35/set/Winter/Sommer_Umschaltung
Der funktioniert aber nicht, weil FHEM den letzten Slash wohl als Pfadtrenner interpretiert und nicht als Readingname. Wie übergibt man denn so was? Escapen hat jedenfalls nicht geholfen.
Ein anderes Bsp. dafür ist DHK_BM-2_0x35_ECO/ABS.

Leider habe ich noch keine Doku gefunden, die erläutert, wie man die Slashes in den Readings korrekt übergibt. Das Umlautethema wäre ein weiteres, wenn es da setter gäbe ... .

Danke für Deine Geduld,
fhem024

[Beta-User]

Datenpunkte in MQTT sollten für FHEM einen "Kreis" ergeben. Also: Was du als set-Befehl auf ein Reading (Beispiel hier: "Warmwassersolltemperatur") schreibst, sollte dann eine Antwort aus der Gegenstelle erhalten (Kreis bedeutet: anderer Pfad). Und den Datenpunkt mappst du halt auf dein Reading, Fisch geputzt. Ob es funktioniert, sieht man am einfachsten, wenn man setStateList auf irgendwas setzt, z.B. "on off". Dann wird nämlich das "set_xy" ins Reading geschrieben, bis die Antwort da ist (und richtig gemappt).

Es ist übrigens wenig hilfreich, dass du weiter meinst, es ginge ohne raw-list einfacher... So habe ich jedenfalls noch keine konkrete Idee, wie deine jsonMap jetzt aussieht und wie das gewünschte Reading grade  benannt ist.

[fhem024]

Hallo Beta-User,
ich habe Dir hier die rawlist bereitgestellt - ich hoffe, ich habe das korrekt verstanden und dass die Dir weiterhilft.

Danke
Gruß
fhem024

[Beta-User]

Ist das irgendwie geheim? Wenn nein: wie soll ein eventueller Mitleser was daraus lernen?

Also nochmal von vorne: Warum "complex"? Beim Durchsehen der Reading-Liste ist mir zumindest auf die Schnelle nichts aufgefallen, was in irgendeiner Form "wirklich doppelt" wäre und von den "prefix"-Settings profitieren würde. Nur die Außentemperatur scheint auf zwei Datenpunkten zu kommen, die geringe Abweichung kommt vermutlich daher, dass der Messwert einfach zu unterschiedlichen Zeiten gemessen und übertragen wurde.

(anonymisierter) Vorschlag für die Vereinfachung:

Code Auswählen Erweitern

attr DEVICE readingList Wolf/[^/]+/[^/]+:.* { json2nameValue($EVENT, '', $JSONMAP) }

Aber erst mal weiter ohne das. Ergänze jsonMap mit einer weiteren Zeile - ich hoffe, den passenden Datenpunkt für die "Rückmeldung dazu" erwischt zu haben, dann wird vielleich klarer, was ich meine.

Code Auswählen Erweitern

WWSystem_BM-2_0x35_Warmwassersolltemperatur_eingestellt_350009:Warmwassersolltemperatur

Und versuche mal das mit setStateList wie vorgeschlagen.

[fhem024]

Sorry Beta-User,
Du hast mich abgehängt. Mit dem Setzen der Warmwassertemperatur gibt es absolut keine Probleme. Das funktioniert, wie es soll. Das Problem sind die Readings mit / im Namen. Wie soll ich die übergeben?

Wenn ich Dich richtig verstanden habe, soll jsonMap z.B. für die Rückmeldung für die Warmwassersolltemperatur erweitert werden. Leider passt der Wert Warmwassrsolltemperatur nicht, weil das ein anderer Wert ist (das kannst Du nicht wissen). Der Wert ist immer auf 10 (default), solange gerade keine Ladezeiten programmiert sind und die auf die aktuelle Zeit passen.
D.h., das Mapping wäre dann

Code Auswählen Erweitern

WWSystem_BM-2_0x35_Warmwassersolltemperatur_eingestellt_350009:WWSystem_BM-2_0x35_Warmwassersolltemperatur_eingestellt_350009

Muss man das tatsächlich angeben - auch wenn es gleich ist? Nebenbei - ich such nur einen Weg, den aktuellen Wert in der Auswahlliste vorzubelegen. Oder würde das dieses Mapping erreichen?

Oder noch besser wäre es, wenn ich den Wert inplace - also im Reading selbst - ändern könnte. Ist sowas evtl. möglich?

Update:
Mir ist auch absolut nicht klar, was setStateList konkret erreichen soll / macht. Was ich gelesen habe, ist, dass man es verwenden soll, wenn es für ein Device mehrere States gibt (gibt es hier ja pro Setter - eine riesige Menge). Hier würde mir eine ausführliche Doku weiterhelfen, die v.a. auch zeigt, welches Problem mit diesem Attribut konkret gelöst wird (ich muss erst mal das Problem erkennen - ich habe ja an dieser Stelle aus meiner Sicht derzeit gar keines - es funktioniert ja).


Danke
Gruß
fhem024

[Beta-User]

Du hast mich abgehängt. Mit dem Setzen der Warmwassertemperatur gibt es absolut keine Probleme. Das funktioniert, wie es soll.

Und woran siehst du das?

Das Problem sind die Readings mit / im Namen. Wie soll ich die übergeben?

Im list sind keine Readings mit "/" - das wäre auch nicht zulässig, da keine "goodReadingNames()".

Muss man das tatsächlich angeben - auch wenn es gleich ist

Auf dasselbe zu mappen, ist in der Tat sinnlos. Aber wenn du unbedingt diese Bandwurmnamen verwenden willst, kannst du das ja auch in der setList entsprechend ändern.
Also statt

Code Auswählen Erweitern

Warmwassersolltemperatur:slider,40,1,60 Wolf/blub/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009dann eben

Code Auswählen Erweitern

WWSystem_BM-2_0x35_Warmwassersolltemperatur_eingestellt_350009:slider,40,1,60 Wolf/blub/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009
Die "Vorbelegung" kommt aus dem Reading-Wert, und der muss halt vorhanden sein (siehe setStateList-Vorschlag) und meine Hinweise zum "Kreis". Der Änderungsvorschlag oben ist auch nur wieder ein "Kreis", nur halt mit einem anderen Reading-Namen auf der FHEM-set-Seite. Er setzt halt voraus, dass irgendwas zurückkommt und Anweisung und Ergebnis irgendwie inhaltlich zusammenpassen...

[fhem024]

Und woran siehst du das?

Weil der Wert, der kurz danach zurückkommt, der korrekte neue Wert ist.

Im list sind keine Readings mit "/" - das wäre auch nicht zulässig, da keine "goodReadingNames()".

Suche nach ECO/ABS oder Winter/Sommer - Umschaltung. Beides mal sind "/" im Readingnamen. Siehe hier aus meiner raw-List:

Code Auswählen Erweitern

#      DHK_BM-2_0x35_Winter/Sommer_Umschaltung:
#        logdb:
#          TIME      1731752442.84484
#          VALUE      18
Der korrekte Pfad ist hier DHK_BM-2_0x35/[Readingname = Winter/Sommer_Umschaltung]]
Das Problem ist, dass der letzte / zum Namen gehört und nicht zum Pfad.

Zum Thema Vorbelegung in der setList: ich glaube, jetzt wird mir erst klar, welches Mapping hier genau gemeint ist: Hier soll der "sprechende Name" (der erste Parameter), welcher in der setList verwendet wird, an anderer Stelle wieder einem Reading zugeordnet werden. Auf diese Weise wird dann die Vorbelegung erreicht. Der Name in der setList ist daher nur bedingt ein frei wählbarer Name. Wenn ich die Vorbelegung haben möchte, muss dieser Name immer gleich dem (technischen) Reading sein. Mit jsonMap kann ich ja aus dem technischen Namen jeden anderen beliebigen Namen machen - ist dann aber fürs Debugging weniger transparent und wirkt sich auch auf die Einträge in der DB aus. Am schönsten wäre, wenn man im setList da direkt das zugehörige technische Reading fürs Mapping angeben könnte.

Ergänzung:
Die Präfixe wie DHK_BM-2_0x35, WWSystem_BM-2_0x35 oder TOB_0x8 will ich auch nicht wirklich weg haben, weil die darüber Auskunft geben, aus welchem Device / Steuerungsteil der Heizungsanlage der Parameter tatsächlich stammt. Dir ist ja z.B. schon der Außentemperaturparameter aufgefallen. Den gibt es an unterschiedlichen Stellen und der kann dann auch unterschiedliche (deutliche!) Abweichungen haben - je nach dem, wie man die Anlage konfiguriert hat. Bei mir differieren die aktuell nicht wirklich - weil die Konfig entsprechend ist. Zum Verständnis der Anlage ist schon gut, wenn man die Herkunft der Parameter sieht. Sind ja doch ein paar.

Ergänzung 2:
Mit

Code Auswählen Erweitern

setStateList on off
funktioniert die Vorbelegung tatsächlich auch bei sprechendem Namen, der vom Reading abweicht, sobald man den Wert einmal gesetzt hat. Ich kann aber derzeit nicht abschätzen, welche Nebenwirkungen dieses on off hier hat. Hätte auch hugo mueller zum selben Resultat geführt?

Danke
Gruß
fhem024

[fhem024]

Ich konnte den offenen Punkt noch klären. Hier für andere, die evtl. auch straucheln:

"/" im Readingnamen - aus dem MQTT-Trace (JSON):

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35   {"Winter/Sommer Umschaltung": 18}

wird wie folgt übersetzt:

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35/set/Winter_Sommer_Umschaltung
=> alle Leerzeichen und "/" im Namen müssen durch "_" ersetzt werden!

Es gibt auch verschachtelte JSONs. Sowas z.B.

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35 {"Programmwahl":{"340029":{"value":1,"text":"Auto"},"340032":1}}
Dies wird zu

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35/set/Programmwahl/340029/value
übersetzt, falls man über die Values arbeiten möchte.

Nochmal lieben Dank Beta-User, dass Du mir geduldig den einen oder anderen Tip gegeben hast, wie man das ganze umsetzen könnte.

Gruß
fhem024

[Beta-User]

Schön, dass nun einigermaßen klar ist, wie das "Kreis"-Prinzip funktioniert und auch bei deiner Gegenstelle (mit dieser seltsamen Struktur) konkret umgesetzt ist.

Magst du den Thread noch als [gelöst] markieren?

Die Präfixe wie DHK_BM-2_0x35, WWSystem_BM-2_0x35 oder TOB_0x8 will ich auch nicht wirklich weg haben, weil die darüber Auskunft geben, aus welchem Device / Steuerungsteil der Heizungsanlage der Parameter tatsächlich stammt.

Das mit "unabhängige Anlagenteile" erinnert mich an ebus. Da haben wir die einzelnen Teile zum größten Teil in eigene MQTT2_DEVICE-Instanzen ausgelagert, so dass man z.B. die Brauchwasser-Soll-Temperatur als "desired-temp" an der Brauchwassersteuerung einstellen kann. Das fügt sich m.E. sehr viel besser in den FHEM-Kontext ein als irgendwelche "technischen Readingnamen". Klar muss man wissen und nachvollziehen können, was woher kommt und sollte nichts durcheinanderwerfen, was nicht zusammen gehört, aber wenn man das "Ergebnis" nicht wirklich "lesen" kann, fängt man damit imo auch nicht allzuviel an.

Ich kann aber derzeit nicht abschätzen, welche Nebenwirkungen dieses on off hier hat. Hätte auch hugo mueller zum selben Resultat geführt?

Bezüglich des setters für die Temperatur ist das in der Tat völlig gleichgültig, was da steht, schon gleich, wenn und solange es diese setter gar nicht gibt.

Vielleicht schaust du zum Ganzen nochmal ins Wiki, da gibt es einen ("knackigen") Artikel zu MQTT2_DEVICE - Schritt für Schritt. Anregungen zur Verbesserung darfst du gerne geben .

[fhem024]

Hallo Beta-User,

ich habe leider noch einen Punkt vergessen, zu erwähnen . Da gibt es doch noch einen Setter, den ich benötige, der mit Umlauten im Namen daherkommt - genauer mit einem 'ß'. Das habe ich ja mit jsonMap gerade gezogen. Der Setter in der setList sieht dann wie folgt aus (ich habe via jsonMap aus ß -> ss gemacht):

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35/set/Normaussentemperatur_Heizkurve

Das funktioniert dann auch soweit - aber die Vorbelegung, also die Variable HK_Normaussen (unter diesem Namen rufe ich den Setter auf) wird zwar gesetzt (wie in allen anderen Fällen auch), aber die Rückmeldung bekommt er hier wohl nicht auf die Reihe. Ich bin aber froh, dass ich den Setter überhaupt nutzen kann.

Hast Du da noch eine Idee?

[Beta-User]

Hast Du da noch eine Idee?

Das jsonMap in deinem list sah dazu eigentlich ganz ok aus.

Ich würde in dem Fall man schauen, wie der MQTT-Verkehr im Ablauf ausschaut, wenn du den Parameter (in FHEM) setzt.(Siehe z.B. https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt#MQTT_-_Datenverkehr_mitlesen). Ohne diese Info ist es vermutlich ein "Stochern im Nebel".

Nachtrag noch: Wo sind eigentlich die ganzen Namen definiert? Vielleicht kann man "den ganzen problematischen Scheiß" auf der Gegenseite soweit gradeziehen, dass man nicht ständig nacharbeiten muss...?

[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