Verbesserung der Behandlung von Leerzeichen mit MQTT

[martinrieder]

Wie in #173 (comment) bereits gezeigt kann es im Zusammenhang mit den Funktionen parseJSON und ParseFloat zu unerwünschtem Verhalten kommen. Folgende Verbesserungen schlage ich daher vor:

1. Die Typsicherheit von parseJSON muss gewährleistet sein, insbesondere bei Verwendung in Benutzereingaben als TEMPLATE (vgl. MQTT-Dimmer und -Analogwertempfänger: Mehr Möglichkeiten um den Wert zu extrahieren #70).
2. Der an ParseFloat übergebenen String darf keine vorangestellten oder nachfolgenden Leerzeichen enthalten (sog. Trim Whitespace), um weitere ähnliche Probleme mit anderen Extraktoren zu vermeiden.
3. Die irreführende Fehlermeldung im Debug Log ("Template returned invalid number literal") sollte berichtigt werden, da fval nicht berücksichtigt wird.
4. Wenn Fehlermeldungen einen String referenzieren, sollte dieser generell in Anführungszeichen gesetzt sein.

Zu 1. möchte ich hinzufügen, dass ich mit der etwas ungewöhnlichen Syntax nicht vertraut bin, aber ich denke, dass die doppelt geschweiften Klammern um den Ausdruck (z.B. {{(parseJSON .).a_act_power}}) herum erzwungen werden müssen. Sofern sie nicht vom Benutzer eingegeben wurden, sollten sie einfach programmatisch hinzugefügt werden, um die "Typsicherheit" zu erhalten. Ich verstehe aber nicht genügend Golang, um diese Vermutung bewerten zu können.

[mdzio]

Noch ein paar Kommentare von mir zu den einzelnen Punkten:

1. Die Typsicherheit von [`parseJSON`](https://github.com/mdzio/ccu-jack/blob/master/virtdev%2Fmqtt.go#L160-L167) muss gewährleistet sein, insbesondere bei Verwendung in Benutzereingaben als `TEMPLATE` (vgl. [MQTT-Dimmer und -Analogwertempfänger: Mehr Möglichkeiten um den Wert zu extrahieren #70](https://github.com/mdzio/ccu-jack/issues/70)).

Das Template auf Gültigkeit zu prüfen, ist sehr schwierig und damit aufwändig.

2. Der an [`ParseFloat`](https://github.com/mdzio/ccu-jack/blob/master/virtdev%2Fmqtt.go#L266-L269) übergebenen String darf keine vorangestellten oder nachfolgenden Leerzeichen enthalten (sog. _Trim Whitespace_), um weitere ähnliche Probleme mit anderen Extraktoren zu vermeiden.

Das ist nun angepasst worden.

3. Die irreführende Fehlermeldung im Debug Log ("Template returned invalid number literal") sollte berichtigt werden, da `fval` nicht berücksichtigt wird.

Die Fehlermeldung stimmt schon. Die Fehlermeldung von ParseFloat ist immer die selbe (invalid syntax), sodass sie nicht mit ausgegeben wird. Im Fehlerfall ist fval immer 0,0, sodass eine Ausgabe auch nicht sinnvoll ist.

4. Wenn Fehlermeldungen einen String referenzieren, sollte dieser generell in Anführungszeichen gesetzt sein.

Die vom Template generierte Zeichenfolge ist nun von ' eingeschlossen.

Zu 1. möchte ich hinzufügen, dass ich mit der etwas ungewöhnlichen Syntax nicht vertraut bin, aber ich denke, dass die doppelt geschweiften Klammern um den Ausdruck (z.B. {{(parseJSON .).a_act_power}}) herum erzwungen werden müssen. Sofern sie nicht vom Benutzer eingegeben wurden, sollten sie einfach programmatisch hinzugefügt werden, um die "Typsicherheit" zu erhalten. Ich verstehe aber nicht genügend Golang, um diese Vermutung bewerten zu können.

In einem Template können beliebig viele (bzw. auch gar keine) {{ ... }} Blöcke verwendet werden. Vor oder nach einem {{ ... }} Block können auch beliebige Zeichen, die unverändert in die Ausgabe übernommen werden, stehen. Diese Flexibilität wird eventuell für spätere Erweiterungen benötigt.

[martinrieder]

1. Die Typsicherheit von [`parseJSON`](https://github.com/mdzio/ccu-jack/blob/master/virtdev%2Fmqtt.go#L160-L167) muss gewährleistet sein, insbesondere bei Verwendung in Benutzereingaben als `TEMPLATE` (vgl. [MQTT-Dimmer und -Analogwertempfänger: Mehr Möglichkeiten um den Wert zu extrahieren #70](https://github.com/mdzio/ccu-jack/issues/70)).

Das Template auf Gültigkeit zu prüfen, ist sehr schwierig und damit aufwändig.

Okay, es mag schwierig sein, das Template zu prüfen. Ich habe mich zu dem Thema ein wenig aufgeschlaut. Soweit habe ich das schon verstanden, dass es einen String erzeugt, der vom Extractor in ein Float umgewandelt wird.

Bezüglich der Funktion parseJSON sehe ich aber den fundamentalen Unterschied, dass hier ein String in ein Objekt gewandelt wird. Erst in Folge der weiteren Behandlung durch das Template wird das dann wieder zurück in einen String gewandelt. An dieser Stelle würde ich mir die Typsicherheit wünschen, aber ich will jetzt auch keinen theoretischen Fall für eine problematische Randbedingung konstruieren. Wir belassen es besser erst mal dabei, wie es ist.

2. Der an [`ParseFloat`](https://github.com/mdzio/ccu-jack/blob/master/virtdev%2Fmqtt.go#L266-L269) übergebenen String darf keine vorangestellten oder nachfolgenden Leerzeichen enthalten (sog. _Trim Whitespace_), um weitere ähnliche Probleme mit anderen Extraktoren zu vermeiden.

Das ist nun angepasst worden.

Vielen Dank für die schnelle Umsetzung!

3. Die irreführende Fehlermeldung im Debug Log ("Template returned invalid number literal") sollte berichtigt werden, da `fval` nicht berücksichtigt wird.

Die Fehlermeldung stimmt schon. Die Fehlermeldung von ParseFloat ist immer die selbe (invalid syntax), sodass sie nicht mit ausgegeben wird. Im Fehlerfall ist fval immer 0,0, sodass eine Ausgabe auch nicht sinnvoll ist.

Meiner Ansicht nach sollte es bezogen auf den Eingabe-String dann lauten: "Template returned invalid number literal for payload"
... denn sonst könnte man interpretieren, dass sich der nachfolgende Text auf den Rückgabewert bezieht. Ich will aber auch hier nicht die Mücke zum Elefanten machen. Wer im Stande ist, ein Debug Log zu interpretieren, der sollte auch den Code dazu verstehen. ;-)

4. Wenn Fehlermeldungen einen String referenzieren, sollte dieser generell in Anführungszeichen gesetzt sein.

Die vom Template generierte Zeichenfolge ist nun von ' eingeschlossen.

Klasse. Damit sollten ungültige Zeichen schneller aufzufinden sein. Was passiert denn, wenn eine Einheit hinter der Zahl steht?

[mdzio]

Was passiert denn, wenn eine Einheit hinter der Zahl steht?

Im JSON-Format ist dies nicht zulässig. Bei EXTRACTOR=BEFORE oder AFTER wird die Einheit ignoriert.