Hallo
Was will mir diese Fehlermeldung sagen ?
10.06.2021, 22:20:31 | FlowHandler | Kann Daten nicht zur Instanz #30428 weiterleiten: Packet was not fully consumed, Buffer:
Instanz 30428 ist der MQTT Server.
Ist das irgendwas das ich reparieren kann/soll/muß ?
bb
Servus!
Verwendest du ZigBee2MQTT?
Nö, hab nur Selbstbau Lösungen mit ESP und NodeMCU.
OK, eine HeishaMon ist kürzlich eingezogen. Das setzt im wesentlichen aber auch auf die Arduino Lib auf.
Leider bietete die Meldung keine weitere Information welcher Node der Verursacher sein könnte.
gruß
bb
Ich dacht zuerst, es hängt ausschließlich mit meinen ZigBee-Geräten zusammen.
Nach einigen Versuchen, hat sich das aber nicht verhärtet.
Der Fehler kommt scheinbar (wie von @KaiS auch schon vermutet), vom MQTT-Server.
Aufgrund von Problemen, habe ich habe zwei MQTT-Instanzen angelegt und die Geräte aufgeteilt.
Leider habe ich trotzdem im Augenblick mehr als 800x diese Fehlermeldung und das in kurzer Zeit.
Ich denke, bei mir kommt es von meinem Stromzähler Shelly 3EM, welcher relativ viele Datensätze schickt.
Diese Meldungen habe ich zurzeit:
**Shelly 3EM Debug:**
13.06.2021, 00:27:07 | ReceiveDataFilter | Large Payload (>16kb) skipped due to GCC crash issue with RegEx
**MQTT Server Debug:**
13.06.2021, 00:29:32 | CLEANUP | Connection 192.168.1.215:54344 was marked as erroneous and will be removed
Kommt der Fehler auch sofort wenn du IP-Symcon neu startest? (Bzw. wie lange dauert es bis er kommt?)
paresy
Muß ich mal beobachten.
zzt. kommen keine Meldungen, letztens war das ganze log voll.
Ich denke ich habe inzwischen auch neu gestartet.
gruß
bb
@paresy
Hatte jetzt einige Zeit (ca. 1 Tag) keinen Fehler und jetzt geht’s wieder voll los.
Ich hab herausgefunden, dass der Fehler weg ist, wenn ich die Server-Socket Instanz deaktiviere und wieder aktiviere.
Leider fehlen weitere Informationen, woher der Fehler kommt.
Ich hatte diesen Fehler auch schon mal, konnte aber auch nicht erkennen woher der kommt.
Wenn der bei mir wieder auftritt melde ich mich.
Vielleicht kann ich @paresy dann ja Zugriff auf mein System geben.
Grüße,
Kai
Ich dachte, dass das Problem vielleicht mit dem letzten Update der 6.0 behoben ist.
Leider tritt der Fehler schon wieder auf und ich habe 1600 Fehlermeldungen.
Ich schätze, dass Symcon mit der Anzahl an MQTT-Meldungen überfordert ist.
Es betrifft jedes mal die gleiche MQTT Splitter Instanz und zwar jene, wo auch der Shelly 3EM angemeldet ist.
Ich werde mal testweise den 3EM auf die andere MQTT-Server Instanz legen und schauen, ob sich dann der Fehler verlagert.
Ich wollte nur kurz nachhaken. Hast das bei dir die Lösung gebracht?
paresy
Ich habe den 3EM nun seit 8 Tagen auf die andere Instanz umgestellt und folgendes festgestellt:
Den genannten Fehler habe ich nicht mehr erhalten, jedoch ist wieder ein anderer (früherer) Fehler aufgetaucht, den ich damals nie bei Symcon vermutet hätte.
Ich habe im Bad einen 3er-Deckenspot mit 3x Shelly-Bulbs GU10 installiert.
Das Problem war, dass bei Betätigung des Tasters, sehr oft nur 2 von 3 Lampen geschaltet haben.
Zuerst war die Vermutung bei den Shelly-Bulbs, dann an Kai’s Modul.
Wir haben unzählige Versuche durchgeführt.
Durch Zufall stellte sich dann heraus, dass scheinbar der MQTT-Server überlastet war und teilweise Meldungen nicht weitergegeben hatte.
Da ich generell Probleme mit dem MQTT-Server hatte, habe ich das ganze testweise auf zwei Instanzen aufgeteilt und plötzlich war auch das Problem mit den Lichtern weg.
Dieser Fehler ist, seit dem ich den 3EM wieder zur anderen Instanz hinzugefügt habe, wieder da.
Der 3EM (Stromzähler) sendet relativ viele MQTT-Meldungen in kurzen Abständen mit dem aktuellen Stromverbrauch aus. Scheinbar ist der Server damit überfordert.
Ich hab diese Fehler auch. Mal mehr. Mal weniger häufig.
Ich nutze einige shellies und Go e Charger.
Bin aber noch auf 5.5
Gruß Sebastian
Ich kann bestätigen, dass das Shelly 3EM den MQTT Server bzw. Symcon total lahmlegen kann.
Ich habe mittlerweile das Shelly 3EM über einen externen Broker, welcher auf meinem NAS im Docker Container läuft, im Betrieb.
Grüße,
Kai
Wie viele Shelly EM brauche ich denn um das Problem zu provozieren? Ich würde dem Problem endlich mal gerne auf Spur kommen 
paresy
Du brauchst ein Shelly 3EM. Das Teil erzeugt Last ohne Ende.
Grüße,
Kai
Seit ich einen eigenen MQTT Server für meinen 3EM benutze, habe ich auch keine Fehlermeldungen mehr.
Ich bekomme bald noch 2 weitere. Bin gespannt.
Sebastian
Ich bekomme die Tage einen. Dann werde ich mal berichten was bei mir passiert 
paresy
Gibt es neue Erkenntnisse?
Auch ich habe die FlowHandler Fehlermeldungen
16.09.2021, 14:14:04 | FlowHandler | Kann Daten nicht zur Instanz #44470 weiterleiten: Packet is too short. Expected: 14646, Actual: 483
44470 ist mein MQTT Server
Ich habe einen Shelly 3em
Wir haben einen Shelly EM3 hier - wir kamen jedoch noch nicht dazu es uns näher anzusehen.
paresy
