JSON-Parsing-Fehler

[PvtOta]

Hi @andesse,

danke für das coole Projekt! Da Huemagic bei mir seit der neuen Version nicht mehr funktioniert, habe ich auf deinen Flow gewechselt.

In seltenen Fällen erhalte ich allerdings einen "JSON-Parsing-Fehler" vom http-Request-Node:

Dies ist mir schon beim Deployment passiert, bei "Get all Data" und beim Ansteuern von Lampen. Es kommt nicht oft vor und ich konnte es bisher nicht rekonstruieren. Weißt du vielleicht, woran das liegen könnte?

Aus dem Debug-Node kommt folgendes:

Meine Hue Bridge ist auf der neusten Version.

Der philipshue-events Node funktioniert bei mir leider nicht. Beim Pairing passiert nichts und auch wenn ich die IP und den API-Key manuell eingebe, passiert nichts.
Der API-Key ist exakt identisch anzugeben, wie in deinen function-Nodes, oder?

Der SSE_Event_Stream hingegen funktionierte bei ersten Tests gut. Die Motion-True und Motion-False Events von einem Bewegungsmelder werden scheinbar immer jeweils doppelt ausgegeben. Hast du vielleicht einen Tipp, wie ich die ausfiltern kann, um sie nur noch einfach zu bekommen?

Vielen Dank schon mal für deine Rückmeldung und deine Unterstützung.

[andesse]

@PvtOta
Hi, danke danke :)

Der json parsing Fehler kommt manchmal vor, wenn in dem Befehl der in der change Node definiert ist ein Fehler ist. (Json kann dort schon nicht formatiert werden) Das kannst Du mal folgendermaßen prüfen. Guck in Deinen action changes nodes rein. Öffne den json Teil und klicke mal auf den „Visual Editor“ Button. Wenn da ein Fehler angezeigt wird, ist was falsch.
(Normalerweise sollte das json Feld in der Change Node auch nen roten Rahmen haben)

2. Lösungsansatz
   Ich hatte auch das gleiche Problem und habe Stunden nach dem Fehler gesucht…
   Es kann passieren wenn (ich weiß ja nicht wie du triggerst, ich habe es über Mqtt gemacht) das payload / topic nicht sauber ist. Da musst du mal debug (volles Nachrichten Objekt) machen was von deinem Auslöser (Taster/Mqtt/etc) an payload in die change Node reingeht. Ich musste folgenden Kram aus dem payload was vom Mqtt kam vorher löschen so das nur ein reines payload übrig blieb.
   

Das die orangene Node nicht funktioniert kann passieren. Das hatte ich letztens auch einmal.
Die Konfiguration mit der IP Adresse muss dann gelöscht werden, dann ohne konfig deployed werden, dann erstellst Du nen neue Konfig, gibst die IP Adresse per Hand ein, UND DANN OHNE PAIR ZU KLICKEN, das mit der IP fertig stellen, ok klicken und das deployen. Danach wieder rein, Deine IP steht jetzt drin, pair klicken und dann den Button auf der Bridge drücken.
Dann müsste dort eigentlich der neue Key erscheinen.

Wenn das nicht geht und du hast Huemagic noch drauf, erzeuge dir dort einen neuen Key in der Config Node und versuche es mit diesem.

Hoppla, bei meinem Bewegungsmelder Subflow fehlt tatsächlich etwas. Da muss eine RBE Node rein, damit die Nachricht nur einmal durchgeht. Änder den Subflow mal so

Dann sollte wahrscheinlich alles gelöst sein, sag ma Bescheid.
Gruß Andreas

[andesse]

@PvtOta

Status code 503 ist unavailable. Da stimmt wahrscheinlich etwas mit dem api key nicht.
du brauchst in jedem Fall nen frischen. Kann sein das ein Bridge Update da was zerbröselt hat.
Die API V2 ist noch in der Entwicklung, kann passieren das da mal etwas bei nem Update nicht geht.
Die HUE app nutzt momentan gemischt V1 und V2 Ressourcen. Deswegen fällt es dort nicht auf.

[andesse]

@PvtOta noch was! Der json parsing Fehler kann auch kommen wenn die Bridge zu viele Anfragen auf einmal erhält.
Bei get all Data habe ich in dem Subflow Zeiten definiert, kann auch sein das die bei Deinem Setup länger sein müssen. Mehr Abstand zwischen den Anfragen.

Kann vieles sein… sonst kannst du auch alle inject nach einander klicken. Ist im Endeffekt das gleiche. Warte dann immer auf das Array payload

[PvtOta]

Wow @andesse , das nenne ich eine schnelle und ausführliche Antwort. Vielen Dank!!

Den Event-Node habe ich auch mit den von dir beschriebenen Schritten nicht zum Laufen gebracht. Wenn ich den Node allerdings komplett neu reinziehe und die Daten manuell eingebe, dann funktioniert er tatsächlich. Interessanterweise sieht er optisch auch anders aus. Keine Ahnung, warum.

Der JSON-Parsing-Error scheint mit dem SSE Event Stream zusammen zu hängen. Wenn der Stream aktiv ist (gleicher API-Key, wie die http-Nodes), erhalte ich beim Ansteuern einer Lampengruppen in 100% der Fälle den JSON-Error. Deaktiviere ich den Event Stream, läuft der gleiche Flow ohne Fehler durch:

Ich habe den SSE Event Stream jetzt raus geworfen und seither keinen einzigen JSON-Error mehr erhalten. Scheint jetzt alles rund zu laufen :)

Die doppelten Motion-Events beim Bewegungsmelder kommen offensichtlich auch nur mit dem SSE Event Stream. Mit dem philipshue-event Node erhalte ich die Events nur noch einmal. Auch ohne deine oben genannte Änderung.

Danke nochmal für deine schnelle Rückmeldung und Unterstützung.

[andesse]

@PvtOta
Die Hue Event Node ist in meinem Beispiel deaktiviert. Deswegen sieht die durchsichtig aus. Man kann die Node unten links ein/ausschalten. ;) Dann war das der Fehler.

ist aus dem Grund, falls jemand ohne die vorher zu installieren deployed und dann ggf. ein restart / Boot Loop ausgeführt wird.

Mit dem SSE kann ich das nicht nachvollziehen. Man könnte einen anderen Key der gleichen Bridge ausprobieren.
Aber die Hue Event stream ist besser.

Schönen Abend

[PvtOta]

@andesse
Oje, Anfängerfehler :-D
Immerhin ist es geklärt.
Danke und ebenfalls einen schönen Abend.

[GeorgeCastanza]

Not sure what this is, since i can't read German, but I think I've got this error as well. I'm getting

"JSON parse error"

Thoughts?

[andesse]

And the retry in the flow you are using should actually do this „wait a bit“ delay node

[FredBlo]

The 'JSON Parse error' actually occurs when the HUE bridge 'refused' the request. In this case, the http request node receives an HTML page which it cannot parse to JSON. Therefore the warning seen in debug pane.
Refusal of a request may occur for many reasons (invalid token, unknown ID,... too many calls,..)
Since we need/try to have all 'possible valid' calls to be sent to the bridge, the retry loop is intended to retry on 'manageable' errors.

Initially, a tried to use a rate limiter but, during my 'hit & try' tests, I had to limit rate to 1 per second to avoid errors (mainly when using 'group commands' which HUE bridge does not accept with same frequency as ligt point ones (doc indicate 'approx. 1 per second...').
When having many calls (~20), it became really too long, so I preferred the retry technique...

But thinking again about your post, I made more tests :

• I (re)set-up a rate limiter at 1 per 250ms (which is +/- max allowed for light point ~(5/sec... but my bridge 'tolerates' up to 10-12 / second)
• keep the 'retry loop' for exceptions

I will update the flows based on this and my lasts tests :-)

[andesse]

Debug debug debug… every node in the flow where the error occurs. Then it’s possible to find the error.

[GeorgeCastanza]

Initially, a tried to use a rate limiter but, during my 'hit & try' tests, I had to limit rate to 1 per second to avoid errors (mainly when using 'group commands' which HUE bridge does not accept with same frequency as ligt point ones (doc indicate 'approx. 1 per second...').

When I was getting the errors (JSON Parsing Error), it was during transition between Hue Magic nodes and this. I had some setup with this integration, others with the Hue Magic integration. I increased the timeout to 250msec, and the errors dissappeared.

Having removed all Hue magic integration, the errors have gone, and I've reduced the timeout to 150msec. I use a combination of grouped_lights and lights. Not scenes. I've also removed all other integratons, especially HomeAssistant. It was probably accessing the v.1 API and bogging down the Hue hub, contributing to the JSON parse error.

I have ~60 lights, + 6 motion sensors, + 6 buttons all on 1 Hue hub. It's seamless at the moment.

[andesse]

@GeorgeCastanza good to hear!

I don’t know your setup, but I would recommend to use scenes.

They have in general a better performance as sending a command to (multiple) lights or groups. The scene is a preset that is saved in the bridge, (that why you can read the Id). Sending a single http request to the bridge, activates the scene, and the bridge fires all settings via Zigbee to the lamps. You will never run with that in a parsing error.

Multiple commands to lights or groups have a less good performance, cause they are not Pre-saved and the bridge need to handle the process internally before or within sending settings to the lamps. Requesting multiple light settings with http request (or two lights and a group for example) are leading to the typical parsing/request errors.

So I did avoid using single lamps, I have just 2, next to my bed for wife and me. All other groups just use scenes.

It can also help (its just a feeling idk) to spread the request room-wise to separate header+http nodes, so every room has an own

greetings
Andreas