[geklärt] json2namevalue mit non-Standard-JSON

[TomLee]

Hallo Rudolf,

völlig unnötig beschäftigt mich folgendes:

An eine MQTT2_SERVER-Definition (mit complex) auf einem Testsystem sende ich zum Test/Verständnis einen Json, welchen ich aus dem Trafficmonitor meines Hauptsystem vom Ebusd kopiere.

Meine Vorstellung ist das von der Konfiguration her alles gegeben sein sollte (wie auf dem Haupsystem und da funzt das wie immer) und hier gibts einen Fehler:

Code Auswählen Erweitern

defmod MQTT2_mymqtt_171398149054287 MQTT2_DEVICE mymqtt_171398149054287
attr MQTT2_mymqtt_171398149054287 readingList mymqtt_171398149054287:testy/bla:.* { json2nameValue($EVENT, 'bla_', $JSONMAP) }
attr MQTT2_mymqtt_171398149054287 room MQTT2_DEVICE

setstate MQTT2_mymqtt_171398149054287 2024-11-17 15:47:06 IODev MQTT2_Server
setstate MQTT2_mymqtt_171398149054287 2024-11-17 15:56:17 json2nameValueErrorText error parsing (#1) '(10) "0": {"name": "temp1", "value": 66.0},(10) "1": {"name": "temp1", "value": null},(10) "2": {"name": "temp2", "value": 7.312},(10) "3": {"name": "temp1", "value": 0.0},(10) "4": {"name": "temp1", "value": 44.0},(10) "5": {"name": "pumpstate", "value": 64}'
setstate MQTT2_mymqtt_171398149054287 2024-11-17 15:56:17 json2nameValueInput {(10) "0": {"name": "temp1", "value": 66.0},(10) "1": {"name": "temp1", "value": null},(10) "2": {"name": "temp2", "value": 7.312},(10) "3": {"name": "temp1", "value": 0.0},(10) "4": {"name": "temp1", "value": 44.0},(10) "5": {"name": "pumpstate", "value": 64}}
? ? ?

Allerdings ergibt das hier, auf beiden Systemen ausgeführt, auch den Fehler:

Code Auswählen Erweitern

{ my $r=json2nameValue('{(10) "time": {"value": "16:40:24"},(10) "date": {"value": "17.11.2024"}}','Status01_');; join("\n", map { "$_=>$r->{$_}" } sort keys %{$r}) }
Wenn man die (10) aus dem JSON entfernt, dann passt alles.

Wo ist jetzt mein Denkfehler, was übersehe ich ?

Gruß Thomas

[rudolfkoenig]

Der Text mit (10) ist meines Wissens kein gueltiges JSON.
Ich vermute, dass irgendwer \n als (10) ausgibt, und damit das schoene JSON kaputtmacht.

[TomLee]

Die Daten kommen so direkt vom Ebusd beim MQTT2_SERVER an, da ist keiner mehr zwischendrin:

Code Auswählen Erweitern

2024.11.18 12:42:21 5: in@192.168.188.25:35440 PUBLISH: 0(28)(0)(19)ebusd/global/uptime2669232
2024.11.18 12:42:21 4:   MQTT2_Server_192.168.188.25_35440 ebusd_3.3_3878 PUBLISH ebusd/global/uptime:2669232
2024.11.18 12:42:21 5:   MQTT2_Server_192.168.188.25_35440 ebusd_3.3_3878 => ebusd/global/uptime:2669232
2024.11.18 12:42:21 5: out@192.168.188.25:35440 PUBLISH: 0(28)(0)(19)ebusd/global/uptime2669232
2024.11.18 12:42:21 5: MQTT2_Server: dispatch autocreate=complex\000ebusd_3.3_3878\000ebusd/global/uptime\0002669232
2024.11.18 12:42:22 5: in@192.168.188.25:35440 PUBLISH: 0(161)(2)(0)(18)ebusd/bai/Status01{(10)     "0": {"name": "temp1", "value": 45.0},(10)     "1": {"name": "temp1", "value": null},(10)     "2": {"name": "temp2", "value": 8.812},(10)     "3": {"name": "temp1", "value": 0.0},(10)     "4": {"name": "temp1", "value": 46.0},(10)     "5": {"name": "pumpstate", "value": "on"}}
2024.11.18 12:42:22 4:   MQTT2_Server_192.168.188.25_35440 ebusd_3.3_3878 PUBLISH ebusd/bai/Status01:{
     "0": {"name": "temp1", "value": 45.0},
     "1": {"name": "temp1", "value": null},
     "2": {"name": "temp2", "value": 8.812},
     "3": {"name": "temp1", "value": 0.0},
     "4": {"name": "temp1", "value": 46.0},
     "5": {"name": "pumpstate", "value": "on"}}
2024.11.18 12:42:22 5:   MQTT2_Server_192.168.188.25_35440 ebusd_3.3_3878 => ebusd/bai/Status01:{
     "0": {"name": "temp1", "value": 45.0},
     "1": {"name": "temp1", "value": null},
     "2": {"name": "temp2", "value": 8.812},
     "3": {"name": "temp1", "value": 0.0},
     "4": {"name": "temp1", "value": 46.0},
     "5": {"name": "pumpstate", "value": "on"}}

[rudolfkoenig]

Die Daten kommen so direkt vom Ebusd beim MQTT2_SERVER an, da ist keiner mehr zwischendrin:

Doch, die Darstellung in FHEMWEB

Hypothese: Du hast die Daten aus dem FHEM MQTT-Trafic-Monitor rauskopiert.
Dafuer werden nicht druckbare Zeichen als (xx) umkonvertiert, das heisst, hier ist FHEM selber "schuld".
FHEM-Intern ist '(10)' weiterhin als \n vorhanden, wie man das in deinem Log sieht.

[TomLee]

OK, danke für das erklären (irgendwie dacht ich mir das schon). Weiß der Kuckuck warum ich mich bisher immer gegen die Verwendung von mosquitto_sub gewehrt habe, ab jetzt guck ich nur noch da.