Leider gibt es bei mir einige Readings mit Umlauten. Ich hatte mich auch damit abgefunden, dass die Readings z.B. anstatt einem "ü" mit "ü" vorgeschlagen/gespeichert wurden und das funktioniert.
Beim mode "plot" aus https://forum.fhem.de/index.php/topic,86584.0.html wird mir ebenfalls "ü" vorgeschlagen, allerdings muss ich das manuell in ein "ü" ändern damit der Plot in SmartVisu Daten empfängt.
Gibt es eine aktuellere Lösung inklusive Plots, bei dem die Namen durchgängig mit einer einheitlichen Schreibweise und passenden Vorschlägen funktionieren?
Grüße
Manfred
Tritt das auch bei anderen Widgets als Plot auf?
"ü" wird bei allen Readings vorgeschlagen, aber beim Plot muss ich die Umlaute ändern damit in SmartVisu 3.2 etwas ankommt.
Was heißt vorgeschlagen?
Beim Tippen werden "Vorschläge" angezeigt... siehe Anhang.
Ok, also bei den Plots. Das Plot Widget ist nicht von mir, da muss der Autor ran.
Vorgeschlagen wird immer mit "ü" (auch in der Originalversion).
Innerhalb smartVISU ist alles UTF-8 kodiert. In den Skripten 01_fronthem.pm und 31_fronthemDevice.pm ist das auch so. Auffällig ist, dass in 99_fronthemUtils.pm das "use utf8" im Kopf fehlt und nur bei den Logs explizit utf-8 encoded wird. Kann das die Ursache sein?
Vielen Dank Wolfram, dass Du Dich auch noch darum kümmerst!
Für mich habe ich ja bereits herausgefunden, wie SmartVisu Daten bekommt.
Da das bisher niemandem aufgefallen ist oder die Plots niemand verwendet vertiefe ich das nun auch nicht weiter und hoffe, das irgendwann jemand Zeit findet sich das weiter anzusehen.
Ein ähnliches Problem hat sich im smartVISU-Forum ergeben:
https://knx-user-forum.de/forum/supportforen/smartvisu/1750413-erweiterung-basic-input?p=1751197#post1751197
Im fhem-Treiber ist der gleiche Code in Zeile 341:
io.socket.send(unescape(encodeURIComponent(JSON.stringify(data))));
Beim smarthomeNG-Treiber funktioniert folgende Zeile bisher gut im Test:
io.socket.send(JSON.stringify(data));
Könnt Ihr dies mal mit fronthem testen?
Gruß
Wolfram
Zitat von: wvhn am 12 März 2022, 21:09:18
Könnt Ihr dies mal mit fronthem testen?
Das Problem mit den Umlauten hatte ich innerhalb von fhem.
"basic.input" nutze ich nicht.
Der erste Versuch mit "basic.stateswitch" und Umlauten hat dazu geführt, dass fronthem auch nach einem Neustart des kompletten Produktivsystems nicht mehr läuft. Es musste erst das Reading mit Umlaut im fhem Device manuell geändert und fhem erneut gestartet werden. Da ich kein Testsytem habe muss das bitte jemand anderes weiter untersuchen.
Zitat von: herrmannj am 27 Februar 2022, 15:18:37
Ok, also bei den Plots. Das Plot Widget ist nicht von mir, da muss der Autor ran.
Mir ist aktuell leider nicht zu 100% klar, welche Version von fronthem nun innerhalb von fhem verwendet werden soll und wer sich darum kümmert, dass möglichst viel in SmartVisu funktioniert.
Danke fürs Testen. Ich hoffe, Du bekommst das wieder zum Laufen.
Das Problem ist zuerst bei basic.input aufgefallen, ist aber ein grundsätzliches Problem. Der Treiber zerstört die utf-8 Codierung der Sonderzeichen. Da viele Anwender vorsichtig sind und lieber keine Umlaute verwenden, ist das bisher nicht aufgefallen.
Soweit ich fronthem verstehe, wird beim ersten Aufrufen einer smartVISU-Seite die Liste der abonnierten items geladen und im Editor ,,vorgeschlagen", wie Du geschrieben hast. Sorry, wenn ich hier nicht so recht mit der Terminologie vertraut bin. Das von Dir beschriebene Verhalten passt zu dem Problem, dass wir im Treiber für smarthomeNG beobachtet haben. Ich gehe davon aus, dass die Veränderung der Umlaute durch den fhem-Treiber von smartVISU verursacht wird. Durch die Änderung des Treibers müssen alle Reading-Verknüpfungen mit Umlauten angepasst werden.
Allerdings mag es sein, dass fronthem selbst mit Umlauten in utf-8 nicht zurechtkommt und sich bisher zwei Fehler kompensiert haben. Das kann ich nicht beurteilen / testen.
Gruß
Wolfram
Das ist möglich. Parallel bastelt Rudi auch an den Umlauten, lange Zeit wurde leider die Notwendigkeit Umlaute in fhem überhaupt zu unterstützen nicht gesehen
Zitat von: wvhn am 13 März 2022, 10:42:17
Danke fürs Testen. Ich hoffe, Du bekommst das wieder zum Laufen.
Läuft schon wieder.
Beim Senden eines Umlauts z.B. mit "basic.stateswitch" wird der Wert in einer "Variable" (Reading) in fhem gespeichert, jedoch nicht als korrekter Umlaut.
Ich vermute, das Problem ist erst beim "Zurücksenden von fhem an Smartvisu" entstanden.
Nach dem Löschen des gespeicherten Werts und einem Neustart von fhem funktioniert wieder alles.
Testen mag ich das trotzdem nicht mehr ohne Testsystem.
Zitat von: wvhn am 13 März 2022, 10:42:17
Allerdings mag es sein, dass fronthem selbst mit Umlauten in utf-8 nicht zurechtkommt und sich bisher zwei Fehler kompensiert haben.
Meine Namen in fronthem/Smartvisu haben keine Umlaute. In fhem muss ich dem Namen dann aber "Variablen" (Readings) in fhem zuordnen. Grund für den Thread war, dass einige meiner "Variablennamen" (Readingnamen) innerhalb von fhem dummerweise Umlaute enthalten und eine Umstellung viel Arbeit und Testen bedeutet. Das hat aber auf den Austausch der Daten mit Smartvisu soweit noch keine negativen Folgen. Je nach Typ "Plot" bzw. "Rest" muss die Variable einmal wie "vorgeschlagen" bzw. manuell beim Plot auf Umlaute geändert werden. Wenn das bekannt ist und man auch in Jahren noch dran denkt, dann ist das soweit zu verschmerzen.
Das NEUE Problem ist, dass die Inhalte der "Variablen" (Readings) keine Umlaute enthalten sollten. Das ist das größere Problem, da der Benutzer in einem Text-Widget natürlich irgendwann machen wird.
Leider scheint sich aktuell niemand mehr für fronthem in seinen unterschiedlichen Varianten zuständig zu fühlen.
Ich bin daher derzeit froh, dass ich eine Lösung habe, die auch Plots abdeckt. Eventuell muss ich langfristig auf Grafana ausweichen.
Grüße,
vielleicht zur Frage von wvhn und dem Beitrag aus dem knx-user-forum.
Also basic.input -> fronthem -> fhem. Ohne eine Änderungen in der smartVISU, also V3.2.0
Im angehängten Bild sieht man, dass das "ö" nicht richtig interpretiert wird. Ich werde im knx-user-forum auch antworten und versuchen bei der Eingrenzung im fhem-Treiber der smartVISU zu helfen.
Nebeneffekt: FHEM zeigt dann kurz "lost connection" an. Bei einem Text ohne Umlaut kommt diese Meldung nicht.
Super. Danke fürs Mithelfen.
Der Lösungsvorschlag steht weiter oben im Thread.
Connection lost kommt eigentlich nur, wenn das Backend die Verbindung beendet. Also muss der Websocket-Server einen Fehler wegen der falsch kodierten Zeichen schmeißen. Das ist ungewöhnlich.
Gruß
Wolfram
Mit der Änderung im smartVISU-FHEM-Treiber
von
io.socket.send(unescape(encodeURIComponent(JSON.stringify(data))));
auf
io.socket.send(JSON.stringify(data));
kommen kein Texte mit Umlauten mehr an. Im FHEM-LOG steht dann folgender Fehler
ipc fronthem:127.0.0.1:46348 (ws): error malformed UTF-8 character in JSON string, at character offset 134 (before "\x{fffd}}") at ./FHEM/01_fronthem.pm line 250.
Grüße,
in fronthem habe ich als converter auch "encode" und "decode". Ich weiß nicht wie diese funktionieren. Wenn ich "encode" wähle erscheint im Log.
error doing $result = fronthem::encode($param); Not enough arguments for Encode::encode at (eval 3672) line 1, near "$param)"
Kann mir jemand sagen, wofür diese Converter gedacht sind und wie diese parametriert werden?
Hallo zusammen,
ich stehe gerade an dem gleichen Punkt, dass die Eingabe eines Textes mit Umlauten in ein basic.input zum abrupten Beenden der Verbindung zwischen FHEM und Smartvisu führt.
Gibt es inzwischen vielleicht einen Lösungsansatz?
Danke und Gruß,
Bruece-Lee
Laut ramann sollte die Version im develop branch des neuen Repository's mit Umlauten umgehen können (siehe https://forum.fhem.de/index.php/topic,127432.msg1234355.html#msg1234355). Mir fehlt aber das Wissen, um die Codestelle zu lokalisieren, mit der das gemacht wird. Es wäre super wenn das jemand testen / lokalisieren könnte.
Gruß
Wolfram
Ich habe in der 01_fronthem.pm in der Funktion fronthem_ipcRead($) aus der Version von ramann das $msg = Encode::encode('UTF-8', $msg); übernommen bevor das decode_json() ausgeführt wird. Dies für dazu, dass fronthem nicht mehr abstürzt, wenn ein Umlaut eingegeben wird und das Reading, das befüllt wird, wird korrekt in FHEM mit Umlaut dargestellt. Problem gelöst!