MQTT2 für Worx Landroid Mähroboter

[rudolfkoenig]

autocreate auf 0 oder nicht angegeben ist, gibt es beim Neustart eine perl warnung.

Ich kann das nicht nachstellen (weder mit 0, noch ohne Parameter), und auch Code-Lesen hat mich nicht weitergebracht.
Kannst Du die konkrete Meldung zeigen?

[frober]

autocreate auf 0 oder nicht angegeben ist, gibt es beim Neustart eine perl warnung.

Ich kann das nicht nachstellen (weder mit 0, noch ohne Parameter), und auch Code-Lesen hat mich nicht weitergebracht.
Kannst Du die konkrete Meldung zeigen?

Rudi, mir fällt noch mehr auf...

meine Def nach doppelten Neustart (dazwischen einen connect um sicher zu gehen), aktuelle Änderungen von heute (ausgekürzt aufs nötigste):

define MQTT2_Worx MQTT2_CLIENT XX
attr MQTT2_Worx autocreate simple
attr MQTT2_Worx connectFn {use LandroidUtils;;;;Landroid_connect($NAME,"worx",0)}
attr MQTT2_Worx keepaliveTimeout 600
attr MQTT2_Worx maxFailedConnects 3
attr MQTT2_Worx mqttVersion 3.1.1
#  ClientsKeepOrder 1
#  DEF        XX
#  DeviceName XX
#  NAME      MQTT2_Worx
#  STATE      disconnected
#  TYPE      MQTT2_CLIENT
#  clientId  MQTT2_Worx
#  connecting 1
#  inConnectFn 1
#  nrConnects 0
#  nrFailedConnects 0
#  READINGS:
#    2023-04-12 19:11:45  state          disconnected

nach einem manuellen connect

Code Auswählen Erweitern

attr MQTT2_Worx maxFailedConnects 20
attr MQTT2_Worx nextOpenDelay 180

setstate MQTT2_Worx opened
D.h. ein connect bei Neustart von Fhem funktioniert nicht. Hatte es durch meine vielen Tests schon geahnt, deshalb der doppelte Neustart um sicher zu gehen.
Edit: hattest du das sogar geschrieben? Muss ich nachlesen...

im Log:

Code Auswählen Erweitern

2023.04.12 19:07:56 1: ERROR: Landroid_connect MQTT2_Worx - no username attribute
2023.04.12 19:08:12 1: PERL WARNING: Use of uninitialized value in hash element at FHEM/LandroidUtils.pm line 193.
Diese Perl Warnung habe ich gemeint, Zeile 193:

Code Auswählen Erweitern

if(!$attr{$m2d->{NAME}}{readingList} && $m2c->{autocreate});
Den ERROR verstehe ich nicht, das attr ist da, sonst würde der connect nicht funktionieren. Die Meldung müsste von Zeile 54 kommen:

Code Auswählen Erweitern

return Log 1, "$errPrefix no username attribute" if(!$usr);


Eine Frage noch, du hast

Code Auswählen Erweitern

{use LandroidUtils;;Landroid_connect($NAME,"worx",0)} mit doppelten Semikolon gepostet, ich habe es gerade mit einem und Neustart probiert, funktioniert genauso. War das ein Typo oder welcher Sinn steckt dahinter?

[efyzz]

@efyzz: im Log waeren die naechsten Zeilen interessant. Bis dahin ist alles nach Plan.

Tatsache, eine Zeile kam noch dazu. Sorry!
Und dann geht's eine Stunde später wieder von vorn los.

Code Auswählen Erweitern

2023.04.12 11:09:40 2: maxFailedConnects (1) reached, no more reconnect attemtps
2023.04.12 12:08:29 4: MQTT_Worx: requesting new token

Ihr Gerät sendet uns täglich um die 150 Nachrichten ...

Na toll, also bestenfalls alle 10min ein Update. Dagegen war das ja früher nahezu "Echtzeit". Aber warum hat das dann funktioniert? Kann ja irgendwie nicht sein, dass es früher schon auf 150 begrenzt war?!

[Ralli]

MQTT PING als Anfrage zu zaehlen waere unprofessionell (hoeflich ausgedrueckt).

Nur als Hinweis: der ioBroker-Adapter hat ein Update erfahren. Dort wurde mqttPing nun deaktiviert:

https://github.com/iobroker-community-adapters/ioBroker.worx/commit/0c2921f70d74e30203af87c1fc4c4afac1784d19

Ich habe nach wie vor das Problem, dass aus unerfindlichen Gründen irgendwann der Client offline geht und einige Stunden auch keine Verbindung mehr herstellt.

[frober]

Ich habe nach wie vor das Problem, dass aus unerfindlichen Gründen irgendwann der Client offline geht und einige Stunden auch keine Verbindung mehr herstellt.

Dein Doof steht auf 30s hast du Mal geschaut wie oft es auslöst?

Mein Watchdog reagiert erst nach 30 Min!

[frober]

Na toll, also bestenfalls alle 10min ein Update. Dagegen war das ja früher nahezu "Echtzeit". Aber warum hat das dann funktioniert? Kann ja irgendwie nicht sein, dass es früher schon auf 150 begrenzt war?!

Es ist ein Unterschied, ob ich Daten Anfrage oder der Mower von sich aus sendet. Ich hatte damals ein notify das zu oft ausgelöst hat.
Mit der aktuellen FW wurde das eh eingeschränkt, es werden nur noch Events gesendet. Batteriespannung, Temp. usw. kommen nicht mehr regelmäßig.
Zumal die Verbindung zum Server möglichst gehalten wird. Ein ständiges dis-/reconnect ist nicht sinnvoll, wenn man regelmäßig Daten haben möchte.

[rudolfkoenig]

Nur als Hinweis: der ioBroker-Adapter hat ein Update erfahren. Dort wurde mqttPing nun deaktiviert:

mqttPing (in FHEM als keepaliveTimeout bekannt) hilft Verbindungsprobleme schneller zu entdecken.
Das als "Fallback" aktivierte KeepAlive auf TCP-Ebene prueft nur alle 2+ Stunden, ob die Gegenseite noch da ist.
Man kann keepaliveTimeout auch auf einem groesseren Wert setzen oder auf 0 zum deaktivieren.

Ich habe jetzt LandroidUtils so angepasst, dass geaenderte Attribute (keepaliveTimeout, maxFailedConnects und nextOpenDelay) bei einem Landroid_connect Aufruf nicht ueberschrieben werden.

@Frober: ich habe vmtl. auch die Ursache der obigen Warnung gefunden (und behoben): es liegt an dem Zugriff auf eine noch nicht vorhandene Attributliste.

[frober]

Nur als Hinweis: der ioBroker-Adapter hat ein Update erfahren. Dort wurde mqttPing nun deaktiviert:

mqttPing (in FHEM als keepaliveTimeout bekannt) hilft Verbindungsprobleme schneller zu entdecken.
Das als "Fallback" aktivierte KeepAlive auf TCP-Ebene prueft nur alle 2+ Stunden, ob die Gegenseite noch da ist.
Man kann keepaliveTimeout auch auf einem groesseren Wert setzen oder auf 0 zum deaktivieren.

Ich habe jetzt LandroidUtils so angepasst, dass geaenderte Attribute (keepaliveTimeout, maxFailedConnects und nextOpenDelay) bei einem Landroid_connect Aufruf nicht ueberschrieben werden.

@Frober: ich habe vmtl. auch die Ursache der obigen Warnung gefunden (und behoben): es liegt an dem Zugriff auf eine noch nicht vorhandene Attributliste.

Danke, werde ich testen...
Mit den Attr finde ich gut, hatte den Gedanken auch schon.



mqttPing ist mWn dafür die Verbindung zu halten, wenn länger als 15 oder 20 Min (?) keine Kommunikation stattfindet beendet der Server die Verbindung.
Zumindest habe ich das so gelesen, da aber Postitec hier eine benutzerdefinierte Konfiguration benutzt ist es möglich, dass es hier nicht zutrifft.
Bei ioBroker ist die Ursache der Probleme noch nicht bekannt, ich habe die Issue komplett gelesen. Die Vermutung war von 24h-Sperre bis zu Internetproblemen.

Bei mir läuft Fhem mit der AndroidApp parallel ohne Probleme. Allerding steuere ich nichts, ich lese nur...
Vor der Umstellung hatte ich den Ping auch auf 1000.

[frober]

Ich habe noch etwas im Inet gestöbert...

Bei openHAB wird alle 599s ein polling ausgeführt, mit der Bemerkung das nach 600s die Verbindung geschlossen wird.
Bei AWS IOT gibt es für den Server ein keepAliveTimeout, ist dieses um das 1,5 fache überschritten, beendet der Server die Verbindung (keine Info, wie es Positec konfiguriert hat).
In PositecBeta sehe ich bisher keine Änderung.

Hier ziehlt das Bsp. für Ping direkt auf den Mower (Seriennummer):

Code Auswählen Erweitern

./index.js --brand-prefix WX --auth-endpoint=xxx --auth-client-id=xxxx --endpoint=xxx ping 20220000000000000123
@Rudi, war ich damit wirklich so unprofessionell, dass ich die Pings mitgezählt habe?

Wobei ich aktuell nicht weiß/verstehe, wie das im MQTT2_Client erfolgt. Zumindest sehe ich hier nichts im Zusammenhang mit LandroidUtils.   

[rudolfkoenig]

Dass der MQTT-Server nach 1,5 fachen Ueberschreiten des keepAlives die Verbindung zuklappen muss, ist im MQTT-Standard beschrieben, MQTT2_SERVER macht das auch.

"index.js ping" ist kein MQTT-Ping, da wird das Landroid Backend "angepingt" (leeres Kommando), und der antwortet mit einem JSON, wovon ich nichts verstehe

[rudolfkoenig]

"index.js ping" ist kein MQTT-Ping, da wird das Landroid Backend "angepingt" (leeres Kommando), und der antwortet mit einem JSON, wovon ich nichts verstehe

Das kann man auch selbst nachstellen, wenn die MQTT-Verbindung steht, mit:

Code Auswählen Erweitern

set MQTT2_Worx publish PRM100/FC*******/commandIn {"cmd":0}wobei man das Beobachten nicht vergessen sollte:
- "attr MQTT2_Worx rawEvents .*" + Event-Monitor
- oder "Show MQTT traffic" in der FHEMWEB Detailansicht von MQTT2_Worx

[frober]

"index.js ping" ist kein MQTT-Ping, da wird das Landroid Backend "angepingt" (leeres Kommando), und der antwortet mit einem JSON, wovon ich nichts verstehe

Das kann man auch selbst nachstellen, wenn die MQTT-Verbindung steht, mit:

Code Auswählen Erweitern

set MQTT2_Worx publish PRM100/FC*******/commandIn {"cmd":0}wobei man das Beobachten nicht vergessen sollte:
- "attr MQTT2_Worx rawEvents .*" + Event-Monitor
- oder "Show MQTT traffic" in der FHEMWEB Detailansicht von MQTT2_Worx

"Show MQTT traffic" funktioniert "nicht", man sieht was gesendet wurde, sobald die Antwort kommt klappt es sofort zu (getestet mit 2 gleichen Browserfenster, eins zum senden, eins um nachzuschauen, was passiert ist).
Es kommt eine ganz "normale" Statusmeldung zurück mit aktueller Konfig + Istdaten.
D.h. im ioBroker zählt dieser "Ping" als Anfrage zu den max. 150/Tag.
Bei Fhem ist das nicht so...

Der Errormeldung ist noch vorhanden, Perl Warnung ist weg.

Code Auswählen Erweitern

2023.04.13 19:03:06 1: ERROR: Landroid_connect MQTT2_Worx - no username attributeMich stört es nicht, ist eher ein Schönheitsfehler...

[Ralli]

Es wird immer doller. Ich bekomme jetzt sowohl beim manuellen Aufruf per Browser der Login-Seite als auch über den MQTT2-Client ein 403.

Wohlgemerkt VOR der Account-Eingabe.

Code Auswählen Erweitern

2023.04.14 07:50:17.109 1: ERROR: Landroid_connect MQTT2_Client_Worx - no access_token / <html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>


[frober]

Es wird immer doller. Ich bekomme jetzt sowohl beim manuellen Aufruf per Browser der Login-Seite als auch über den MQTT2-Client ein 403.

Wohlgemerkt VOR der Account-Eingabe.

Code Auswählen Erweitern

2023.04.14 07:50:17.109 1: ERROR: Landroid_connect MQTT2_Client_Worx - no access_token / <html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>


Wieso bekommst du dauernd html-Meldungen? Normalerweise kommt hier Json zurück.
Mir scheint es so, als wenn du gesperrt wurdest...

Welche Login-Seite? Eine 403 vor Eingabe der Logindaten?
Kannst du dich hier https://id.worx.com/login noch anmelden?

Steuerst du deinen Mäher über Fhem?
Schon einmal probiert, den Fhem-Client für 24h abzuschalten?
Hast du geschaut, was dein Doif alle 30s "treibt"?

[Ralli]

Wieso bekommst du dauernd html-Meldungen? Normalerweise kommt hier Json zurück.
Mir scheint es so, als wenn du gesperrt wurdest...
Welche Login-Seite? Eine 403 vor Eingabe der Logindaten?
Kannst du dich hier https://id.worx.com/login noch anmelden?

Genau diese Seite hatte heute morgen offensichtlich ein Problem. Jetzt geht sie wieder und mein MQTT-Client ist auch wieder online. Scheinbar werkeln die ganz schön an der Infrastruktur herum.