Closed Stasik0 closed 2 years ago
When I enter unicode-entities in programs as part of strings, they get "decoded" into unicode and are displayed wrongly over XML API.
Unicode is not supported in ReGaHss. It's simple as that. Stay in ISO-8859-1 (latin1) or you will sooner or later face problems. ReGaHss is latin1 (ISO-8859-1) only.
I am okay with not using unicode. Thats why i wanna use html entities like 🌡
But who turns them into unicode? Is is web editor gui for programs or the execution engine?
But who turns them into unicode? Is is web editor gui for programs or the execution engine?
Well, you are mentioning "XML API". Please show exactly what you are doing, trying to achieve. There are certain internal components that use html entities themselves and thus will could be responsible to convert these entities.
I have a custom html5/js based dashboard where i want to use some emojis as html entities for status icons.
I write those html entities in a system variable from a program (see initial post), and show the variable on my js dashboard polling it via javascript through the xml-api-addon (no writing).
and show the variable on my js dashboard polling it via javascript through the xml-api-addon (no writing).
And are you sure that this xml-api-addon is not the one mangling your html entities? could easily be. Thus, please show the request and response payload in detail so that the issue can be reproduced and not just loosly wrapped up in mind.
Well, i feel it, because also the web editor changes the „source code“ of the program. I‘d bet it is the bad guy.
Will though check xml request and response in the evening and report back
Hat nix mit XML-Api zu tun.
Der Script-Editor wandelt da mal wieder irgendwas beim schließen/speichern um.
Eingegebener Code im DANN eines Programmes:
dom.GetObject(ID_SYSTEM_VARIABLES).Get("SV_Text").State("🌡");
erneutes Öffnen des Scripteditors:
dom.GetObject(ID_SYSTEM_VARIABLES).Get("SV_Text").State("🌡");
erneutes Öffnen des Scripteditors:
dom.GetObject(ID_SYSTEM_VARIABLES).Get("SV_Text").State("%uD83C%uDF21");
Bin hier noch auf der Version vom 09.12. daher spielt das Systemprotokoll wegen dem ;
auch verrückt.
Hat nix mit XML-Api zu tun. Der Script-Editor wandelt da mal wieder irgendwas beim schließen/speichern um.
Sowas dachte ich mir schon. Das werden wir aber nicht so einfach repariert bekommen weil diese HTML entities intern auch für andere Dinge verwendet werden. Bei den vielen Altersschwächen die die WebUI so hat muss man damit glaube ich einfach leben und die Finger von solchen Gimmicks lassen oder eben eine externe Skriptengine wie ioBroker&Co nehmen und gänzlich die Finger von WebUI/ReGaHss Programmen lassen.
Oder vielleicht die skripte mit dem SDV von Black in die CCU schieben
Oder vielleicht die skripte mit dem SDV von Black in die CCU schieben
SDV ist closed source und Windows-only. Wer will/macht/nutzt denn sowas?!?
Bekennende Linux Hasser? 🤷🏻♂️
Die Umwandlung passiert ja erst beim 2. speichern. Also Code eingeben, schließen und gut ist's. Ich würde solche Spielereien aber auch nicht nutzen.
Jetzt bitte kein Kriegsbeil ausgraben. Jeder sollte das nutzen was ihm am besten liegt.
Als Workaround ginge auch...
dom.GetObject(ID_SYSTEM_VARIABLES).Get("SV_Text").State("'🌡'");
Als Workaround ginge auch...
dom.GetObject(ID_SYSTEM_VARIABLES).Get("SV_Text").State("'🌡'");
Das ist in der Tat ein guter Hinweis. Was genau kommt denn dann in der SV_Text an am Schluss? Sichtbar von der WebUI und sichtbar aus Skripten heraus?
Teste ich später, mein Testsystem liegt gerade nach einspielen des heutigen Nightly's auf dem Rücken. Irgendwas mit der HB-RF-USB-TK.
WriteLine(dom.GetObject(ID_SYSTEM_VARIABLES).Get("SV_Text").Value());
ergibt:
'🌡'
WebUI:
Halt ein Thermometer in ' '
Systemprotokoll kann ich nicht testen weil der heutige Nightly nicht will und mit dem letzten noch die Probleme mit dem ;
bestehen.
Die Umwandlung passiert ja erst beim 2. speichern. Also Code eingeben, schließen und gut ist's. Ich würde solche Spielereien aber auch nicht nutzen.
Jetzt bitte kein Kriegsbeil ausgraben. Jeder sollte das nutzen was ihm am besten liegt. Als Workaround ginge auch...
dom.GetObject(ID_SYSTEM_VARIABLES).Get("SV_Text").State("'🌡'");
Leider geht der workaround auch hier nicht. Wahrscheinlich ist es ein wontfix. Ich werde dann im script irgendwelche tokens einbauen und die direkt in html5 Seite ersetzen.
Was tatsächlich auch geht ist nur einmal abspeichern d.h. das Skript einfach irgendwo extern verwalten.
Leider geht der workaround auch hier nicht.
Stimmt, hatte ich nicht sauber getestet. Auch hier wird beim 2. speichern wieder gewandelt.
@jens-maus Kannst du mir bitte helfen die Ursache des Problems zu versehen? Ersetzt die "Editor-Komponente" die Entitäten d.h. wenn man einen austauschbaren Editor (textarea) hätte, wäre dieses Problem behoben? Naja, und es gibt ja noch andere Editoren (https://microsoft.github.io/monaco-editor/) ;)
Nein, das dürfte nicht am editor selbst liegen, sondern vielmehr daran welchen weg der übergebe Text aus dem Editor dann intern via verschiedener Frameworks nimmt bis er letztendlich in ReGAHSs landet bzw in der Systemvariablen gepusht wird bzw auch der umgedrehte weg beim wieder laden. Es gibt da einfach gewisse reservierte Zeichen und Zeichenfolgen die mitunter nicht im String selber auftauchen dürfen weil die sonst verschluckt oder umgewandelt werden. Und genau diesen Effekt siehst du eben nun bei deinen HTML Entitäten.
In der Vergangenheit habe ich schon öfters hier+da probiert das zu optimieren. Aber gänzlich lässt sich das vermutlich nicht lösen. Die WebUI in ihrer jetzigen Form hat einfach ihre klaren Limitationen und Bordercases. Und jeder der ernsthafte bzw komplexe Programmierung/Skripting machen will ist besser damit beraten das externen Engines wie ioBroker, etc. Zu überlassen und die WebUI lediglich als Konfigurationsoberfläche für die HomeMatic Geräte anzusehen.
Describe the issue you are experiencing
When I enter unicode-entities in programs as part of strings, they get "decoded" into unicode and are displayed wrongly over XML API.
When I enter this a program and save the line becomes:
dom.GetObject(ID_SYSTEM_VARIABLES).Get("Heizung").State("🌡");
dom.GetObject(ID_SYSTEM_VARIABLES).Get("Heizung").State("%uD83C%uDF21");
And then there is broken output over XML API.
Describe the behavior you expected
I expect to keep the HTML-entity in the program.
Steps to reproduce the issue
dom.GetObject(ID_SYSTEM_VARIABLES).Get("Heizung").State("🌡");
What is the version this bug report is based on?
3.61.5.20211113
Which base platform are you running?
rpi3 (RaspberryPi3)
Which HomeMatic/homematicIP radio module are you using?
n/a
Anything in the logs that might be useful for us?
Additional information
No response