MQTT2 für Worx Landroid Mähroboter

Begonnen von Otto123, 09 Juni 2020, 13:55:43

Vorheriges Thema - Nächstes Thema

frober

Zitat von: Allgaeuer am 04 Februar 2024, 22:41:11Um zu testen, ob das Neztwerk sporadisch unterbricht, habe ich von einem andren Raspi via mosquitto im 1-sec-Takt Messages an meinen Problem-Raspi geschickt. Hier gab's keine Unterbrechung. Zu Worx gab's aber den bekannten Reconnect.
Grübel, grübel, wo kanns sonst noch liegen ?
Damit hast du nur das Heimnetz getestet und nicht das Internet. Es muss ja nicht direkt der Raspi sein..
Hast du irgendwelche Filter (Firewall, DNS, o.ä.) fürs Internet, die einen stabilen schnellen Verbindungsaufbau verhindern?

ZitatJeder Reconnect wird mit "timestamp 4: MQTT_Worx: reusing the acess_token" eingeleitet. Bei mir steht das Attribut "nextOpenDelay" auf 180 und das dürften die 3 Minuten für den Reconnect sein. Ich rätsle, warum diese Funktion aufgerufen wird, obwohl Daten vom Landroid gekommen sind (also eine erfolgreiche Verbindung bestand).
Die Logmeldung bedeutet ja nur, dass der Token noch gültig ist und weiterverwendet wird. Der Reconnect erfolgt anhand des Attr "nextOpenDelay", was aber nicht bedeutet, das die Verbindung nicht schon vorher verloren geht. Theoretisch kann die Internetverbindung Ping Pong spielen und irgendwann wird sie stabil und dauerhaft.

Das sind aber nur Vermutungen, vielleicht thematisierst du das Problem in einem anderen Unterforum (z.B. Einplatienencomputer) wo mehr Spezialisten lesen.
Raspi 3b mit Raspbian Buster und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Allgaeuer

Hallo zusammen,

ich denke, ich habe das Problem identifiziert und eine Lösung gefunden.

Zum Testen hatte ich ja ein neues, ganz schlankes System (RPI2) aufgesetzt. Das hat sehr schnell gebootet und auch ganz schnell FHEM gestartet. Offensichtlich waren noch nicht alle Netzwerkdienste aktiv und deshalb der 3-Minuten reconnect. Als Abhilfe habe ich die fhem.service (unter /etc/systemd/system ) leicht modifiziert. Die beiden Einträge mit "network.target" auskommentiert und dafür die beiden Einträge mit "network-online.target" eingefügt. Jetzt sind die 3-Min-Reconnects weg.
Das erklärt auch, warum bei anderen der Fehler nicht auftritt.

[Unit]
Description=FHEM Home Automation
#Wants=network.target
#After=network.target
Requires=network-online.target
After=network-online.target
#Requires=postgresql.service

Viele Grüße,

Allgäuer

Violinux

Hi
macht ja auch Sinn komplettes Netzwerk vorher zu starten
bevor Fhem u.A. in Aktion gehen.

systemd[1]: Reached target Network is Online.
systemd[1]: Starting FHEM Home Automation...
systemd[1]: Starting OpenVPN connection to server...
systemd[1]: Starting xyz connection to server...
... ;)

Gruß, Uwe

Allgaeuer

Hi,

das fhem.service von der FHEM-Standardinstallation macht genau das leider nicht. Das Netzwerk wird zwar vorher gestartet, aber FHEM wartet nicht, bis die Netzwerkdienste alle laufen. Mein "fehlerbehaftetes" System habe ich nach Standardprozedur installiert. Dieses Problem tritt aber nur auf, wenn man ein ganz "schlankes" FHEM installiert. Das ist nicht der Normalfall.

@Rudi König: Ich denke, diese Anpassung wäre ein Fall für Dich (fhem.service) :-)

Gruß Allgäuer

rudolfkoenig

Zitat@Rudi König: Ich denke, diese Anpassung wäre ein Fall für Dich (fhem.service) :-)
Habe betateilchen benachrichtigt.

betateilchen

Die Verwendung von network-online.target kann zu nicht nachvollziehbaren Verhalten beim Systemstart führen. Ob dieses sehr spezielle target überhaupt sinnvoll verwendet werden kann, hängt in erster Linie davon ab, wie die Verwaltung der Netzwerkschnittstellen auf der Plattform umgesetzt ist.

Wer - wie ich - beispielsweise nach wie vor mit ifupdown arbeitet (weil das nach wie vor hervorragend funktioniert, einfach zu konfigurieren ist und alles tut, was man braucht), wird mit dem target network-online niemals einen FHEM Start erreichen, wenn man nicht weiß, dass man in diesem Fall noch einen zusätzlichen systemd-Dienst aktivieren und starten muss, der das network-online.target für alle Interfaces simuliert, die in der /etc/network/interfaces als "auto" eingetragen sind.

Die Verwendung des network-online.target kann darüber hinaus zu unkontrollierbaren Verzögerungen beim Systemstart führen.

Aus all den Gründen habe ich nicht die Absicht, dieses aktive target als Standard in das service-file zu übernehmen, um damit das in den allermeisten Fällen problemlos funktionierende passive target zu ersetzen.

Worüber ich nachdenken werde:
Das target network-online mit einem entsprechenden Kommentar in die Datei aufzunehmen, damit man bei Verbindungsproblemen testen kann, ob es als Ersatz Abhilfe schafft.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Allgaeuer

Hallo betateilchen,

Deine Bedenken kann ich nachvollziehen. Wenn dieser Fall (schnelles Booten + FHEM-Start) in der 00_MQTT2_CLIENT bei einem reconnect behoben wird, wäre das sogar die bessere Lösung.
Ich will da niemanden in Zugzwang bringen, biete aber an, hier als Tester mitzuwirken :-)

Gruß Allgäuer

Violinux

bei mir ist die Änderung der Konfiguration nur :
After=network.target dhcpcd.service

Diese läuft hier seit mind. 8 Jahren fehlerfrei.