Fehlermeldung: FlowHandler | Kann Daten nicht zur Instanz #12345 weiterleiten

Ich bekommen in unregelmäßigen Abständen die Fehlermeldung: „FlowHandler | Kann Daten nicht zur Instanz #12345 weiterleiten: freeze protection“

Die Instanz ist mein Modul zur Abfrage von Udomi Brennstoffzellen. https://github.com/timo-u/Symcon_Udomi

Durch was wird denn diese Meldung ausgelöst?

Diese Meldung muss im Datenfluss vom Modul geworfen werden. Somit musst du schauen, an welcher Stelle du Daten weiterleitest und woher die Meldung genau kommt und ggf. eine schönere Meldung werfen.

paresy

Hallo Paresy,

Ich habe versucht dem Problem weiter auf den Grund zu gehen aber ich werde nicht fündig :frowning:

Ich habe sowohl den Aufruf von SendDataToChildren als auch SendDataToParent in einem Try-Catch Block unterbracht als auch in ReceiveData und ForwardData. Hier wird jedoch kein Fehler geworfen. :confused:

Der Fehler selbst ist auch nicht reproduzierbar tritt aber in unregelmäßigen Abständen geworfen.

kannst du mir vielleicht sagen an welcher Stelle der Fehler geworfen wird? Ich habe eine IO-Instanz als Gateway und schicke es dann an die Geräte-Instanzen (wie z.B. 18095).

heißt das der Fehler tritt im Gateway beim Senden an die Children-Instanz auf oder bei der Ausführung in der Children-Instanz?

19.01.2019, 23:31:22 | FlowHandler | Kann Daten nicht zur Instanz #18095 weiterleiten: freeze protection

Bin zwar nicht Paresy, aber ich antworte dennoch :wink:
Kann es sein das aus deinem ReceiveData im Child du wieder über eine Funktion versuchst Daten an den Parent per SendDataToParent zu versenden?
Dann könnte ich mir vorstellen das hier eine Routine in IPS greift um ein blockieren zu verhindern.
Michael

Habe mir deinen Code angesehen.
Du nutzt den Datenaustausch an der Stelle falsch.
Du kannst nicht im IO bei ForwardData ein SendDataToChildren aufrufen. (Da kommt der Freeze Fehler her, da es zu einem Deadlock führen kann.)
Du musst in ForwardData deine Nutzdaten per Return zurückgeben.
Der Child bekommt dann seine Nutzdaten direkt als Rückgabewert von der Methode SendDataToParent.
Die Funktionen SendDataToChildren im IO und ReceiveData im Child werden nicht benötigt.
Michael

Ah Super! das ist ja ein Ansatz :smiley:
Erklärt auch warum es genau so bei meinem SMS-Modul funktioniert. Hier wird es durch den SMS-Versand asynchron.

Danke Michael,

ich hab es jetzt umgeschrieben und gehe mal davon auch, dass es jetzt auch funktioniert :slight_smile:
Bis jetzt war ich davon ausgegangen, dass die Rückgabe nur für einen Status gedacht war :rolleyes:

Liegt vielleicht daran, dass ich das Chart zum Datenfluss wohl falsch interpretiert habe.
SDK => Datenfluss

Eigentlich fehlt da etwas im Chart.
Wie die eigentlichen Daten von oben in den IO gelangen bzw von dort nach oben weg.
Du benötigst nur die linke Seite.
Sendest von unten nach oben und dein eigener IO gibt ja sofort die Antwort im gleichen PHP-Thread zurück.
Und diese Antwort kann dann immer als Rückgabewert durchgereicht werden (imho aber nur als String, darum arbeite ich immer mit serialize).

Die rechte Seite ist wichtig wenn der IO von sich aus Daten nach unten senden muss.
Also z.B. wenn dieser den Timer hätte und alle Daten von sich aus ausliest, oder wenn Daten in den IO gepusht werden.
Michael

Ja das habe ich mittlerweile auch raus gefunden :slight_smile:
Bei meinem SMS-Modul nutze ich das ja auch in die andere Richtung. Hier habe ich dann wohl einfach nur zu kompliziert gedacht :smiley:

Ich arbeite zum Serialisieren mit json_encode und json_decode. Die APIs arbeiten ohnehin meistens mit JSON und somit bleibt man bei einem Format :smiley:

Da ich häufig auch Rohdaten oder ganze Objekte im Datenaustausch nutze, ist JSON immer Aufwand. Da müssen Rohdaten immer erst utf8 kodiert werden und Objekte aufwendig neu erzeugt werden.
Da war mir serialize lieber; da geht beides so.
Michael

Stimmt … dann macht es Sinn :grin:

Ganz scheint das Problem noch nicht behoben zu sein :frowning:

23.01.2019, 15:13:13 | TimerPool | Brennstoffzelle 1 (Update): freeze protection

Ich gehe mal davon aus, dass das Problem immer noch das gleiche ist, nur jetzt wird der Fehler direkt vom auslösenden Timer ausgegeben und nicht mehr durch den Eventhandler :confused:

Ich dachte das es ggf. ein Laufzeitproblem des Scripts ist?
Gibt es sonst noch Ideen :slight_smile: