IP-Symcon goes MQTT

Das auf jeden Fall.

Meine Frage war eher, ob du irgendwelche PHP-Modul hast, die hinter dem MQTT Server sind. Das kannst du am besten über die physikalische Baumansicht prüfen. Falls ja, wäre die Frage ob IP-Symcon auch abstürzt, wenn du die PHP-Module zeitweise deaktivierst.

paresy

@Paresy: Sorry, wenn ich so genau nachfragen muss. Aber Du meinst, wenn ich jetzt das SMA Modul deaktiviere bzw. lösche, ob dann IPSymcon weiterhin abstürzt, wenn ich das MQTT vom Staubsauger aktiviert habe?

Paresy meint die Module, die Daten vom der MQTT Instanz verarbeiten.

Grüße,
Kai

Ok also alle Skripte, Programme, Module deaktivieren, die an MQTT senden bzw. die Daten verarbeiten?

Ich würde mit den Modulen anfangen.

Grüße,
Kai

Ich habe jetzt folgende Szenarien durchgespielt und konnte zum Schluß das Problem eingrenzen:

  1. Alle Module, die MQTT nutzen, sowie alle MQTT devices die Nachrichten an IPSymcon schicken sind deaktiviert --> IPSymcon läuft stabil.

  2. Alle Module, die MQTT nutzen, sowie alle MQTT devices die Nachrichten an IPSymcon schicken sind deaktiviert außer der Staubsauger --> IPSymcon läuft stabil auch wenn der Roboter staubsaugt.

  3. Alle Module, die MQTT nutzen, sowie alle MQTT devices die Nachrichten an IPSymcon schicken sind aktiviert --> IPSymcon läuft stabil auch wenn der Roboter staubsaugt.

  4. Alle Module, die MQTT nutzen, sowie alle MQTT devices die Nachrichten an IPSymcon schicken sind aktiviert und IPSymcon Service wurde von mir manuell neugestartet --> IPSymcon stürzt nach einiger Zeit ab, wenn der Roboter staubsaugt.

  5. Alle Module, die MQTT nutzen, sowie alle MQTT devices die Nachrichten an IPSymcon schicken sind aktiviert und der Staubsauger wurde nach dem manuellen Neustart von IPSymcon neu gestartet --> IPSymcon läuft stabil auch wenn der Roboter staubsaugt.

Es muss also ein Problem existieren wenn IPSymcon neu startet der Staubsauger danach jedoch nicht. Irgendeine Idee woran das liegen könnte?

Interimslösung: Folglich muss ich nach jedem Neustart von IPSymcon (was ja zum Glück nicht so häufig vorkommt) den Staubsauger auch neu starten.

Hallo KingKahn,

gleich kommt noch ein Update, in dem wir ein Absturzproblem bei MQTT korrigiert haben, sofern unvollständige/fehlerhafte Pakete empfangen wurden. Evtl. hilft dies auch bei dir.

paresy

Hallo,

werde bald umzuziehen auf einen Qnap mit dem IPS.
MQTT läuft also noch nicht so astrein?

Bei mir ist zu 90% alles per MQTT am laufen, wäre ja
schade da Ärger zu haben.
Sonst nutze ich ja bis jetzt die Dienste des Linux Systems,
läuft unzerstörbar eigentlich.

Gruß

@paresy

Seit dem Aktivieren des OpCache Spezialschalters, ist die Latenzzeit der MQTT-Pakete auf ein Bruchteil gesunken und die Schaltvorgänge laufen einwandfrei.
Jedoch habe ich täglich eine große Menge an Warnungen hinsichtlich des MQTT-Server-Sockets.

Was kann das sein?

LG Peter

Hi babba,

außer dem einem sehr speziellen Absturz-Problem von demel42 gibt es keine mir bekannten Probleme mit MQTT.

Was führt denn das RequestAction aus? Ist das Problem auch da wenn du über das WebFront die Aktion ausführst?

Wir habe in der letzten Version einiges an MQTT Funktionen hinzugefügt. Somit kann es aber gut einen Fehler geben. Ich brauche nur noch ein paar Details wie ich es nachstellen könnte.

paresy

Hat sich bei 5.3 irgendwas grundlegendes am MQTT Server geändert? Nach dem Update auf 5.3 konnte ich die Shelly Steckdosen nicht mehr schalten.

Was passiert denn? Steht etwas im Debug vom MQTT Server oder vom Shelly Modul?

Grüße,
Kai

Gesendet von iPhone mit Tapatalk

Im Debug vom MQTT Server wurde leider gar nichts ausgegeben. Beim Shelly Modul hab ich dummerweise nicht geschaut, bin jetzt auch wieder zurück auf der 5.2.

Also hier geht alles.
Stand denn auch gar nichts im Log?

Grüße,
Kai

Das mit dem Last Will fixe ich zeitnah.

paresy

Hallo an alle!

Konnte jemand bisher das gleiche Problem feststellen:

Ich habe täglich eine Menge an Warnung. Wenn ich diese öffne, komme ich immer auf den MQTT - Server Socket.
Hat jemand eine Idee, woher die Fehler kommen?

Peter

Leider kein Erfolg bei mir mit der 5.3 Version. Der Fehler tritt weiterhin auf, wenn der Roboter saugt und die Map sekündlich überträgt.

Ich habe das Ganze auch mal mit ioBroker getestet. Dort funktioniert die Anbindung des Roboters an den MQTT Server/Broker von ioBroker ohne Probleme. Auch kann ich dort einstellen, welche MQTT Topics an andere Server/Broker im Netzwerk weitergeleitet werden sollen. Das Map topic habe ich deaktiviert und so bekommt IPSymcon alle notwendigen Infos ohne abzustürzen.

Eine Problemstellung habe ich jedoch noch, die ich bis jetzt nicht Lösung konnte. Kann ich von IPSymcon auch einen Publish auf ein Topic senden, der dann vom ioBroker empfangen wird? Ich würde gerne aus IPSymcon die Reinigungen von definierten Zonen starten. Leider klappt das mit dem Befehl nicht: RequestAction(XXXXX, „Payload“); Auch mit anderen Modulen hatte ich bis jetzt keinen Erfolg. Habt ihr noch einen Tipp für mich?

Danke,
Kai

Kannst du mal zeigen, wie deine MQTT Device Instanz aussieht?

Grüße,
Kai

Hat sich ioBroker denn auch korrekt auf das Topic bei IP-Symcon angemeldet?

paresy

Also im ioBroker sieht es wie folgt aus:

So sieht es in IPSymcon aus:
IPSymcon mqtt instanz.png