Moin, habe gerade auf 7.0 hochgerüstet und räume auf, dabei habe ich im Statusprotokoll sehr oft die Meldung:
„Absender: Flowhandler Nachricht: Kann Daten nicht zur Instanz #46444 weiterleiten: vector too long“
Instanz #46444 ist dabei mein MQTT-Server.
Wie kann ich den Verursacher der zu langen Übertragung herausfinden? (Ich habe viele Geräte, wie Shelly, WallBox… über MQTT eingebunden)
Ich würde den Debug vom I/O öffnen und versuchen von der Zeit her zu isolieren, wann die Nachrichten rein kommen und von welcher IP diese kommen.
paresy
gibt es eine Länge im Debug Protokoll ab der die Meldung "vector too long " ausgegeben wird? Eine Zeit kann ich aus dem Protokoll nicht ermitteln, da teilweise bis zu 5 Meldungen im Sekundentakt ausgegeben werden.
Wäre es nicht möglich bei der Debugausgabe die Sender IP mitzugeben ?
Solche Fehler kommen ja nicht regelmäßig sondern sporadisch. Hier mit dem Timestamp aus dem riesen Wulst an Daten was rauslesen zu wollen ist eine wenig „Stecknadel im Hauhaufen“ Prinzip.
gruß
bb
Ist es doch; im Server Socket.
Aber da kommt die Fehlermeldungen ja nicht her. Sondern irgendwo intern, wo die Daten und die IP nicht zwangsläufig im gleichen Datenfeld sind.
Ein Tip wäre sonst den Debug des ServerSocket in die Datei umleiten und dann die 5-10 Datensätze mit dem gleichen Zeitpunkt wie der Fehlermeldung raussuchen.
Michael
Ja eh. Das ist mir schon klar.
Aber hey, das ist Software also sollte doch alles machbar sein. Denk ich mir.
Moin, habe versucht zum Zeitpunkt der Meldung im Debug des Server Sockets den Verursacher zu finden. Sehe dort an verschiedenen IP’s Telegramme mit einer Länge >1000. Sie kommen von mehreren verschiedenen Shellys aber auch von meinen beiden bitshake Tasmotas (zur Strommessung).
Meine Frage nochmal ab welcher Länge wird die Meldung generiert ?
Habe auch schon einige der Geräte abgeklemmt , trotzdem kommt dann die Meldung immer noch, aber nicht in der großen Anzahl.
Das ist weniger von der Länge abhängig, sondern wird eher ein Fehler im MQTT Paket selbst oder bei uns in der Verarbeitung sein.
Ich habe schon überlegt wie ich dies besser darstellen kann (Insbesondere wäre ja das Paket und Absender interessant, damit ich es isoliert nachstellen kann)
paresy
ja @paresy , wäre schön wenn es eine Möglichkeit gäbe. Wann könnte man damit rechnen?
Bis dahin lege ich das Thema erstmal zur Seite. Hab ja noch ein paar andere Baustellen.
Hol das Thema gerne noch mal nächste Woche hoch. Diese Woche sind wir noch mit dem Release stark ausgelastet.
paresy
danke, ich melde mich nächste Woche nochmal
Kannst du das Problem „nachstellen“ oder kommt das eher zufällig? Ich würde mir dies gerne ansehen - optimalerweise lässt du den Debug vom I/O und vom MQTT Splitter mitlaufen (in die Datei) und stellst mir diese inkl. vom Meldungslog zur Verfügung. (Damit ich die Fehlermeldung zum Datenpaket verknüpfen kann)
paresy
Kommt eher zufällig dann aber massiv, werde mich am Wochenende mal ransetzen und versuchen die Debugs zu erfassen.
Frage: Mit Meldungslog meinst du das Statusprotokoll? Wie kann ich das Statusprotokoll in eine Datei bekommen ?
Gruß Gerd
Moin,
evtl. ist das - wie bei mir - ein Shelly (3EM). Dieser hat mir immer wieder mal seltsame Zeichen beim neuen Thema im Konfigurator angezeigt. Natürlich unberechenbar und somit sporadisch. Vielleicht - falls du solch einen dein Eigen nimmst, könnte ein FW Update abhelfen ?!
LG Tom
3EM nicht ist nicht vorhanden. Alle genutzten Shelly haben das letzte Update. Trotzdem könnte es der Ecke kommen.
Gruß Gerd