Veränderte Backslash Nutzung bzgl. 3.41.11.20181222 und JSON RPC API

[gerald]

Hallo Jens,

ich habe noch einen weiteren Fehler in der letzten Beta bezüglich der JSON RPC API entdeckt. Bzw. ein Nutzer meiner App. Wie es scheint, wird das Backslash falsch interpretiert:

Beispiel:


HMScript:

Code: Alles auswählen

Write('A \\ B \ C')

Als JSON RPC Request:

Code: Alles auswählen

{"method":"ReGa.runScript","params":{"script":"Write('A \\\\ B \\ C')","_session_id_":"xyz"}}

Soll JSON RPC Response:
(So ist es meiner Meinung nach richtig und so macht es auch die CCU 1, 2, und 3 mit aktueller Firmware)

Code: Alles auswählen

{"version": "1.1","result": "A \\\\ B \\ C","error": null}

Decodiert:

Code: Alles auswählen

A \\ B \ C

So sieht es mit deiner letzte Beta aus:

Ist JSON RPC Response:

Code: Alles auswählen

{"version": "1.1","result": "A \\ B \\ C","error": null}

Decodiert:

Code: Alles auswählen

A \ B \ C

Wie du siehst, geht ein Backslash verloren. Ich hab das aus den Logs meines App-Nutzers abgeleitet. Also das Beispiel nicht 1:1 so nachgestellt, da keinen Raspberry. Ich nutze Backslashes und zwei aufeinanderfolgende Backslashes aber intensiv als Trennzeichen mit meiner App. Und in den Logs sehe ich, dass die Darstellung in der Response nicht mehr stimmt.

Viele Grüße und ein Schönes Fest!
Gerald

[jmaus]

Also als erstes hab ich das Thema mal von dem Beitrag rund um das RPI-RF-MOD abgetrennt. Solch Thread Hijacking sollte man wirklich vermeiden damit man hier nicht über Äpfel diskutiert wenn Birnen gemeint sind...

ich habe noch einen weiteren Fehler in der letzten Beta bezüglich der JSON RPC API entdeckt. Bzw. ein Nutzer meiner App. Wie es scheint, wird das Backslash falsch interpretiert:

Das du das jetzt wahrnimmst hat wohl mit dieser Änderung in der neuesten ReGaHss Version zu tun (die auch teil der heute releasten 3.41.11.20181222 version ist):

Code: Alles auswählen

- fixed string backslash unescaping routines to correctly unescape double backslash uses and thus allow to define e.g. \t by using a \\t string which were not possible before (#514).

Mehr nachlesen kannst du dazu hier:
https://github.com/jens-maus/RaspberryMatic/issues/514
https://github.com/eq-3/occu/issues/82

Zusammenfassend lässt sich sagen das du wohl leider nicht drumherum kommen wirst entweder deine Backslash Verarbeitung umzustellen oder (und das wird auf längere Sicht hin das beste sein) ganz auf die Nutzung des Backslashes zur Trennung von Informationen zu verzichten und hierfür einen anderen Qualifier zu nutzen.

Hintergrund des ganze ist, das in früheren ReGaHss Versionen die Verarbeitung von backslashes schlichtweg falsch bzw. fehlerhaft war. Und du bist jetzt leider in deiner @Home App wohl einem vermeintlichen Feature auf den Leim gegangen das jedoch ein Bug darstellt. Denn schaut man sich einfach das von dir genannte Beispiel einmal an:

Unter alter ReGaHss (CCU2, etc.):

Code: Alles auswählen

Write('A \\ B \ C'); ! Ergibt: A \\ B \ C

Unter neuer ReGaHss (Angefangen mit RaspberryMatic 3.41.20181222):

Code: Alles auswählen

Write('A \\ B \ C'); ! Ergibt: A \ B \ C

Sollte es eigentlich recht klar sein warum die "neue" korrigierte Ausgabe die richtige ist (d.h. ein "\\" in einem String sollte in ein einzelnes "\" gewandelt werden – was auch so in der offiziellen Dokumentation steht). Die alten ReGaHss Versionen haben hier eben kurzerhand das "\" komplett falsch verarbeitet wodurch z.B. das erzeugen des strings "\t" nicht möglich war was normalerweise mittels Anweisung "\\t" möglich gewesen sein sollte. Somit sind nun Strings wie z.B. folgende:

Code: Alles auswählen

Write("A \\t B \t C");

möglich und das ergibt unter der neuen/reparierten ReGa nun den String "A \t B C" wobei die Trennung zwischen B und C dann ein echter Tabulator (0x9) übernimmt. In der alten ReGa ist/war das eben nicht möglich da hier das doppelte Backslash falsch verarbeitet wurde und es kam hier der String "A \ B C" raus, was aber eben falsch war.

Für dich bzw. deine Anwendung ergibt sich nun eben folgende Möglichkeiten:

1. Du nutzt statt dem Backslash ein anderes Trennzeichen (z.B. eben den echten Tabulator) ode ähnliches.
2. Du stellst deine string Nutzungen auf die Nutzung von "super strings" um. D.h. du nutzt statt den doppelte Anführungszeichen " einfach das ^ Zeichen. Damit wird dann einfach das gesamte backslash escaping und sämtliche String Vorverarbeitung ausser kraft gesetzt. D.h. dein Beispiel würdest du jetzt einfach wie folgt formatieren:

Code: Alles auswählen

Write(^A \\ B \C^);

Ich würde dir natürlich empfehlen Punkt 1 anzugehen und deine @Home app auf ein anderes Trennzeichen umzustellen da dies längerfristig bessere Erfolgschancen hat und die Lesbarkeit deines eigenen Codes aufrechterhalten sollte. Aber du kannst natürlich auch Lösungsansatz 2 Nutzung und alles auf Super-Skript Zeichen umstellen (welche es übrigens schon immer in der CCU2 oder älter gibt nur bis dato nicht bekannt war).

Welche Lösung du da jetzt nutzt bleibt natürlich dir überlassen, was allerdings nun mit meinen Ausführungen klar sein sollte ist, das es sich hier nicht um einen neuen Bug handelt, sondern du bisher leider eben ein vermeintliches Feature genutzt hast das allerdings ein Bug war und der nun repariert wurde und so auch früher oder später in der CCU3 Firmware dann landen wird. Ergo, solltest du deine @Home App entsprechend umstellen.

[helge5]

Das ist zwar IMO eindeutig ein Bug, aber ich glaube ich würde den Fix trotzdem zurückdrehen, da kann einfach zuviel in bestehender Rega Software brechen (wie im GH beschrieben). Der Zug ist einfach abgefahren.

[jmaus]

Das ist zwar IMO eindeutig ein Bug, aber ich glaube ich würde den Fix trotzdem zurückdrehen, da kann einfach zuviel in bestehender Rega Software brechen (wie im GH beschrieben). Der Zug ist einfach abgefahren.

Bring mir noch ein weiteres prominentes Beispiel und ich denk drüber nach. Ich würde sagen wir warten hier einfach mal ab und beobachten was denn da wirklich noch in die "Brüche" geht. IMHO ist die Gefahr da recht überschaubar weil die Backslash Nutzung bisher sich eben vmtl. vor allem wegen dieser bisherigen Bugs (die jeder sicherlich bald gemerkt hatte) in grenzen gehalten hat.

[gerald]

Hallo Jens,

ich, für meine App kann zusagen, dass zu lösen. Das die Behandlung von Sonder- und Steuerzeichen in HMScript-Strings nicht ganz stringent ist, musste ich schon mehrfach feststellen. Nicht zuletzt habe ich mich auch deshalb für \ und \\ als Steuerzeichen entschieden. Andere Zeichen, u.a. Tab und Line Break konnten zumindest damals ohne weiteres falsch terminiert in Strings durch Nutzer untergebracht werden. Z.B. indem ganze HTML Seiten incl. JavaScript in eine Systemvariable geladen wurden. Diese haben dann meinen Parser durcheinander gebracht.

Wie ist denn deine Zeitplanung? Können wir uns hier abstimmen?

@Home ist die einzige (mir bekannte) kostenlose Homematic App für iOS und aktuell auf ca. 35.000 Geräten installiert. Davon auf ca. 20.000 Geräten regelmäßig genutzt. Es wäre bedauerlich, wenn Du mit dem Fix schneller bist als ich mit meinem. Dem Nutzer ist es letztlich egal wer die "Schuld" hat, dass die App nicht mehr läuft. Letztlich würden wir es wohl beide abbekommen Mit dem Finger dann auf den anderen zeigen hilft dem Anwender auch nicht.

Mein Problem ist aktuell, dass Apple keine Updates von mir akzeptiert. Im Worst Case so lange, bis ich die App auf einen Firmen-Account übertragen habe. (Hintergrund: Ich nutze in @Home IPSec VPN Features von iOS, die mittlerweile aber nur Entwicklern erlaubt sind, die mit Firmen-Account bei Apple angemeldet sind). Ich warte aktuell noch auf die Eintragung ins Handelsregister meiner neu gegründeten Gesellschaft. Erst dann kann ich überhaupt den Firmen-Account bei Apple anlegen.

Denkst Du, Du könntest so lange mit dem Fix warten? Ich habe die Hoffnung, dass sich das im Laufe des Januars klärt und würde dich natürlich auf dem Laufenden halten.

Viele Grüße
Gerald

[jmaus]

Denkst Du, Du könntest so lange mit dem Fix warten? Ich habe die Hoffnung, dass sich das im Laufe des Januars klärt und würde dich natürlich auf dem Laufenden halten.

Der Fix ist bereits in der heute erschienenen 3.41.11.20181222 Version von RaspberryMatic enthalten. Wann dieser in die CCU3 und ggf. auch CCU2 Firmware Einzug hält muss sich noch zeigen, das kann sicher aber bis Ende Januar/Februar dauern. Insofern sind dann wohl erst einmal nur RaspberryMatic Nutzer davon betroffen und auch nur die die die aktuellste RaspberryMatic Version von heute einsetzen. Du müsstest also bis auf weiteres deinen Nutzern erst einmal raten maximal die ältere 3.41.11.20181112 Version von RaspberryMatic einzusetzen bis du eine neue @Home Version deiner App herausgeben kannst.

Tut mir leid das du damit nun ein wenig zusätzliche Arbeit auf dem Tisch hast, aber wie ich schon sagte, den Backslash zu nutzen war dann vielleicht doch unterm Strich zurückblickend eine ungünstige Wahl und ein Tab oder einfach ein ";" wären ggf. sinnvoller gewesen.

[gerald]

Sehr bedauerlich. Gerade jetzt, wo viele Zeit haben sich mit Ihrer Homematic zu befassen.

Bin gespannt, wie eQ3 das für die CCU löst. Eigentlich kann es nicht in ihrem Interesse sein, die Anwendungen Ihrer Partner abzuklemmen.

In der Vergangenheit haben sie die Möglicheit gehabt, die ReGa Version auszuwählen...

Grüße

[jmaus]

Deshalb kommt das eben zuerst in RaspberryMatic was ja quasi der Laborfirmware der CCU entspricht und damit Dinge besser evaluiert werden können und somit externe Anwendungen quasi Zeit haben sich darauf einzustellen.

Und hier klemmt ja auch niemand etwas ab. Ich habe dir ja Ratschläge gegeben wie du das in deiner App reparieren kannst und es sollte abgesehen von den Apple Policies ja ein Leichtes sein diese Anpassungen vorzunehmen (kannst du nicht eine Zwischenversion ohne VPN Funktionalität herausbringen?). Und wer @Home zwingend braucht muss eben bis du das angepasst hast azf der Vorversion von RM bleiben.

Und bis jetzt ist @Home die einzige externe Anwendung die mir bekannt ist die mit dieser Umstellung ein Problem hat bzw. überhaupt davon betroffen ist. Trotzdem tut es mir natürlich leid das du deshalb jetzt zusätzlichen Aufwand hast - gerade zu Weihnachten. Ich werde pber Weihnachten wohl mal sowas wie nightly builds einführen dann steht auch noch etwas mehr Zeit bereit vor einem Release breiter zu testen. Allerdings wäre es dann auch gut wenn du natürlich auch eine RaspberryMatic Testinstallation hättest.

[gerald]

Wie schon gesagt, das zu Fixen geht schnell. Nur die Bereitstellung im Store ist aktuell problematisch. Tatsächlich habe ich bereits am 5.12. eine VPN-Freie Version hochgeladen um den Anforderungen von Apple gerecht zu werden. Diese wurde nun vor 3 Tagen mit der Begründung abgelehnt, weil es eine VPN App wäre. Die Kommunikation mit Apple ist sehr schleppend, auf konkrete Fragen wird nicht eingegangen. Statt dessen Antworten aus Textbausteinen...

Nun ist es halt so ... Frohes Fest

[It-noob]

ich fände es fair diesen Thread festzupinnen! (und ihr könntet beide Richtung Apple zeigen )