Cutter mit Eigenschaft "valides JSON geliefert"

Hallo,
ich habe in der Zwischenzeit einige Geräte selbst per Script und Client-/Server-/Web-Socket an IP-Symcon angebunden. Die meisten dieser Geräte antworten mittlerweile per JSON. Der Cutter kann aber nur relativ simpel filtern. Bei den relativ kleinen Datenblöcken sorgt offenbar bereits ein Teil in der TCP/IP Kommunikation dafür, dass idr. der vollständige JSON Block ankommt. Aber manchmal eben auch nicht. Daher muss ich erst darauf prüfen.

Jetzt wäre es wünschenswert diese häufig verwendete Funktion in den „Core“ auszulagern, anstatt per PHP obendrauf zusetzen.

Daher der konkrete Featurerequest: Der Cuttter möge zusätzlich die Option haben, auf valides JSON (ggf. mit 1-3 Abstufungen für halb inkompatible Geräte) zu prüfen und erst dann die Daten an die RegisterVariable / das Script weiterzuleiten.

Eine Stufe 0 Implementierung wäre vielleicht ein simples prüfen, ob genausoviele { wie } vorhanden sind. Insbesondere in Betracht auf CPU Zeit, etc.

Gruß
Tobias

Das ist weniger ein symcon oder valides JSON Problem, deine Geräte schicken mehrere IP Pakete, da ein Paket max. ca. 1.500 Bytes haben kann. Dadurch kommt ein „unvollständiges“ JSON an.

Soetwas hatte ich auch mit den Wiffi’s von Eugen Stall, dafür habe ich mir ein Mini-Modul gebastelt, dass die Pakete puffert und auf die dort vorhandenen zwei }} prüft, aber „optimal“ ist etwas anderes :eek:.

Außerdem prüfe ich zusätzlich im Script hinter der Registervariablen auf valides JSON, da leider beim Reboot der Wiffi’s immer noch „Müll-Pakete“ geschickt werden.

Und um das Problem soll sich Symcon kümmern, nicht ich mich selbst. Erst wenn soviele korrekte Daten eingegangen sind, dass ein valider JSON String im Buffer liegt, soll es weitergehen. Denn sonst schreibt sich jeder mehr oder weniger gute Routinen um das Problem sehr aufwändig zu lösen.

Der Cutter ist kein JSON oder „sonst-etwas“ - Validator!

Falls @paresy eine gute Idee hat, dann würde ich mich auch freuen.

Wenn es überhaupt ein „symcon Problem“ wäre, dann vielleicht beim Socket, aber ich vermute eher, dass die Quellen mehrere Pakete schicken, die in sich abgeschlossen sind.

Der Cutter ist für wirklich simple Tasks ausgelegt. Somit sehe ich aktuell wenig Chance, dass wir diesen um so etwas kompliziertes bzw. auch fehleranfälliges erweitern.

Dein Vorschlag mit dem „validen“ JSON ist ja leider nicht so einfach bzw. nicht vollständig. Man müsste auch noch die zählen, da ja die Objekte in einem Array sein könnten. Und was, wenn nur ein String in „“ eingebettet gesendet wird? Dann müssten wir diese auch zählen.

Somit sollte das Protokoll eher wohldefiniert sein, um diese Problematik garnicht erst auftreten zu lassen. Nur JSON zu senden ist leider, meiner Meinung nach, nicht wohldefiniert. Da muss man eher über die Zeit gehen und hoffen, dass das Gerät nur alle x Sekunden sendet und Pakete mit Timeouts verwerfen.

paresy