jens-maus / RaspberryMatic

:house: A feature-rich but lightweight, buildroot-based Linux operating system alternative for your CloudFree CCU3/ELV-Charly 'homematicIP CCU' IoT smarthome central. Running as a pure virtual appliance (ProxmoxVE, Home Assistant, LXC, Docker/OCI, Kubernetes/K8s, etc.) on a dedicated embedded device (RaspberryPi, etc.) or generic x86/ARM hardware.
https://raspberrymatic.de
Apache License 2.0
1.54k stars 187 forks source link

HTML-Entities in programms get decoded and disappear #1590

Closed Stasik0 closed 2 years ago

Stasik0 commented 2 years ago

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

  1. Create string-variable "Heizung"
  2. Create a program: dom.GetObject(ID_SYSTEM_VARIABLES).Get("Heizung").State("🌡");
  3. Create a time triggered execution
  4. After on execution the html entities get "decoded"

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?

CCU3 used

Additional information

No response

jens-maus commented 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.

Stasik0 commented 2 years ago

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?

jens-maus commented 2 years ago

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.

Stasik0 commented 2 years ago

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).

jens-maus commented 2 years ago

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.

Stasik0 commented 2 years ago

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

Baxxy13 commented 2 years ago

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.

jens-maus commented 2 years ago

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.

MichaelN0815 commented 2 years ago

Oder vielleicht die skripte mit dem SDV von Black in die CCU schieben

jens-maus commented 2 years ago

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?!?

MichaelN0815 commented 2 years ago

Bekennende Linux Hasser? 🤷🏻‍♂️

Baxxy13 commented 2 years ago

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("'🌡'");

jens-maus commented 2 years ago

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?

Baxxy13 commented 2 years ago

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.

Baxxy13 commented 2 years ago

WriteLine(dom.GetObject(ID_SYSTEM_VARIABLES).Get("SV_Text").Value()); ergibt: '🌡' WebUI: SV_Thermometer 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.

Stasik0 commented 2 years ago

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.

Baxxy13 commented 2 years ago

Leider geht der workaround auch hier nicht.

Stimmt, hatte ich nicht sauber getestet. Auch hier wird beim 2. speichern wieder gewandelt.

Stasik0 commented 2 years ago

@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/) ;)

jens-maus commented 2 years ago

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.