Hallo Rudi,
toJSON({'state','ON','on_time',$EVTPART1})
liefert bei $EVTPART1=44 aktuell
{"on_time":"44","state":"ON"}
Richtig wäre aber
{"on_time":44,"state":"ON"}
Das Ganze scheint eine Eigenart in der Auflösung von $EVTPARTx zu sein. Mit "normalen" Variablen denen ich den numerischen Wert zuweise, z.B. in der 99_myUtils.pm konnte ich das Problem mit den Anführungszeichen um den numerischen Wert nicht nachstellen.
Mit dem untenstehenden patch konnte ich das Phänomen beseitigen. Aufgrund der Rekursion, die in toJSON() verwendet wird, kann ich nicht genau abschätzen, ob die Änderung irgendwelche negativen Auswirkungen haben könnte.
Vielleicht magst Du Dir das mal irgendwann anschauen. Danke.
Index: fhem.pl
===================================================================
--- fhem.pl (Revision 28765)
+++ fhem.pl (Arbeitskopie)
@@ -5335,7 +5335,8 @@
if(not defined $val) {
return "null";
-
+ } elsif (looks_like_number $val) {
+ return $val;
} elsif (length( do { no warnings "numeric"; $val & "" } )) {
return $val;
Mit dem o.g. Patch wird die Zeile drunter ueberfluessig.
Da diese mir esoterisch erscheint, habe ich die Begruendung angeschaut: https://forum.fhem.de/index.php?topic=100951
Die aktuelle Implementierung macht eine Unterscheidung zwischen "3" und 3.
Da $EVTPART1 aus einem split kommt, und damit zwingend ein String ist, waere mAn in deinem Fall die Loesung $EVTPART1+0
Danke für die erste Einschätzung, ich werde das heute Abend mal testen.
Zitat von: rudolfkoenig am 08 April 2024, 11:06:24Die aktuelle Implementierung macht eine Unterscheidung zwischen "3" und 3.
Dabei frage ich mich allerdings, wo "3" überhaupt ein korrekter json-Wert wäre.
Zitat von: rudolfkoenig am 08 April 2024, 11:06:24Da $EVTPART1 aus einem split kommt, und damit zwingend ein String ist, waere mAn in deinem Fall die Loesung $EVTPART1+0
Ok, das funktioniert.
Aber es fühlt sich irgendwie "nicht richtig" an, solch eine Krücke verwenden zu müssen.