Ja, kannst du das Problem provozieren? Und wenn ja, mir die Logfiles vom ServerSocket/MQTT Server zusenden? Dann könnte ich nachvollziehen an welcher Stelle sich der MQTT Server verschluckt.
paresy
Anbei ein Zip mit den beiden Logfiles und Screenshot des Meldungsfensters über den geloggten Zeitraum
MQTT_Server.zip (296,8 KB)
Falls es an Datenrate liegt wie oft die Nodes senden, so könnte ich die natürlich runtersetzen. Muß nicht alles sooo häufig gelogged werden. zzt. Ist es halt sehr schön reproduzierbar.
viel Spass
BB
Hallo,
ich habe nun auch häufig die Fehlermeldung. Ursache unbekannt.
Jedoch sorgt es dafür, dass ich regelmässig Symcon neu starten muss, da der MQTT Server nicht mehr erreichbar ist.
Ich überlege nun einen Mosquitto dazwischen zu schalten.
Wie konfiguriere ich dann Symcon? Sollte ich ich hier weiterhin einen Server laufen lassen und Mosquitto als Bridge nutzen oder sollte ich Symcon auf einen Client umstellen und auf den Mosquitto connecten?
Ein Fix für die Fehlermeldungen kommt zur 6.1, welche demnächst als Public Beta starten wird.
paresy
2 „Gefällt mir“
Hallo,
ich setzte die Version 6.2 ein, aber der Fehler kommt bei mir immer noch. Allerding nicht bei den Shelly EM, sondern bei den KTEM06, welche ich mit Tasmota geflasht habe. Gibt es dazu auch eine Lösung?
Viele Grüße
Norman
Ich hänge mich mal hier rein - passt teilweise.
Ich habe auch n och imme die Meldungen „Packet was nox fully consumed“ aber nur so 10 am Tag.
Heute was neues - „Packet is too short“
18068 ist der MQTT Server
Habe ua. einen Shelly Pro3EM (erst 2 Wochen am Markt) und eine go-e Box im System (die go-e ohne aktives MQTT nur das Modul)
Kann man das eingrenzen - abstellen?
LG Alexander
Du müsstet herausfinden, was die Meldungen provoziert. Bzw. wenn du den Debug vom ServerSocket aktiv hast schauen, was zu dieser Zeit „rein“ kommt.
paresy
Danke - werde das beobachten. Bis jetzt in 3 Tagen nicht wieder aufgetreten - seltsam.