MQTT2 für Worx Landroid Mähroboter

frober · 19 April 2023, 09:18:07

Zitat von: efyzz am 19 April 2023, 08:53:16
Zitat//edit2: habe testweise mich mal online anmelden wollen. Dort kommt der Hinweis, dass ich scheinbar temporär gesperrt bin. Mal schauen. Wahrscheinlich geht es dann erst wieder morgen weiter...

Wie genau machst du das? Wenn ich mich bei eu.worx.com einlogge, kann ich dort nur meine persönlichen Daten einsehen/ändern, sonst nichts.

https://account.worxlandroid.com/login

da wird die IP-Adresse gebannt -> aus dem Heimnetz 403 forbidden, Mobil kann ich mich einloggen

fred_feuerstein · 19 April 2023, 09:32:08

Also dort kann ich mich nun wieder einloggen. Bin also scheinbar wieder entsperrt.

Aber an der Sache mit MQTT, FHEM und worx hat sich nichts geändert.
Das Device steht nach wie vor auf disconnected und alle 180 Sekunden wird ein connect versucht. Dabei kommen dann am Mäher-Device die Standard-Readings vom Mäher (ohne die Status und Battery Readings und ohne Kalender etc.)

Im Log vom Haupt-Device sehe ich trotz verbose 5 nur solche Einträge:

Code Auswählen

2023-04-19_07:49:16 MQTT_Worx connect
2023-04-19_07:49:18 MQTT_Worx disconnected
2023-04-19_07:49:59 MQTT_Worx connect
2023-04-19_07:50:01 MQTT_Worx disconnected
2023-04-19_07:55:26 MQTT_Worx disconnected
2023-04-19_07:57:20 MQTT_Worx disconnected
2023-04-19_07:57:41 MQTT_Worx connect
2023-04-19_07:58:13 MQTT_Worx disconnected

fehlt noch eine Grundeinrichtung bei mir? wie gesagt, letztes Jahr hatte es mit MQTT2 alles funktioniert, somit gehe ich davon aus, dass alle benötigten Dinge installiert sind.

frober · 19 April 2023, 09:38:44

Zitat von: fred_feuerstein am 19 April 2023, 09:32:08Also dort kann ich mich nun wieder einloggen. Bin also scheinbar wieder entsperrt.

Aber an der Sache mit MQTT, FHEM und worx hat sich nichts geändert.
Das Device steht nach wie vor auf disconnected und alle 180 Sekunden wird ein connect versucht. Dabei kommen dann am Mäher-Device die Standard-Readings vom Mäher (ohne die Status und Battery Readings und ohne Kalender etc.)

Im Log vom Haupt-Device sehe ich trotz verbose 5 nur solche Einträge:
Code Auswählen Erweitern
2023-04-19_07:49:16 MQTT_Worx connect 2023-04-19_07:49:18 MQTT_Worx disconnected 2023-04-19_07:49:59 MQTT_Worx connect 2023-04-19_07:50:01 MQTT_Worx disconnected 2023-04-19_07:55:26 MQTT_Worx disconnected 2023-04-19_07:57:20 MQTT_Worx disconnected 2023-04-19_07:57:41 MQTT_Worx connect 2023-04-19_07:58:13 MQTT_Worx disconnected
fehlt noch eine Grundeinrichtung bei mir? wie gesagt, letztes Jahr hatte es mit MQTT2 alles funktioniert, somit gehe ich davon aus, dass alle benötigten Dinge installiert sind.

ich kann nur spekulieren...
Hast du im Fhemweb, in der Regel "WEB", bei attr sslVersion etwas definiert?
MQTT benötigt TLSv12

Mit einem "Trick" bin ich nun wieder online.

frober · 19 April 2023, 09:51:13

Zitat von: frober am 19 April 2023, 08:12:45Hallo Rudi,

autocreate 0 macht Probleme. Auch beim nachträglichen Setzen.
Edit: evtl. hängt es damit zusammen, dass ich mein Device umbenannt habe, ich habe auch keine "Mowerdaten" in diesem Device.

Bei mir hat es heute Nacht zugeschlagen, bin nun erstmal komplett gesperrt...auch die AndroidApp usw.

Ich habe nun auch eine 403 forbidden als HTML im Log.

Das Problem habe ich vermutlich erkannt. Da der Client das umbenannte Device nicht kennt, stimmten nach den Anpassungen die Internals nicht mehr.
Ich benenne nun das Neue um und probiere autocreate 0 noch einmal...

fred_feuerstein · 19 April 2023, 10:20:54

Zitat von: frober am 19 April 2023, 09:38:44ich kann nur spekulieren...
Hast du im Fhemweb, in der Regel "WEB", bei attr sslVersion etwas definiert?
MQTT benötigt TLSv12

sslVersion war bei mir gar nicht definiert. Habe es nun auf TLSv12 gesetzt.

hat aber nach erneutem fhem Neustart auch nichts gebracht.

Hier mal ein list vom Haupt-Device:

Code Auswählen

Internals:
   BUF        
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        iot.eu-west-1.worxlandroid.com
   DeviceName iot.eu-west-1.worxlandroid.com:443
   FUUID      643ed8e2-f33f-965f-f880-1229b3821cb918e2d4e
   NAME       MQTT_Worx
   NEXT_OPEN  1681892098.90043
   NR         1563
   PARTIAL    
   SSL        1
   STATE      disconnected
   TYPE       MQTT2_CLIENT
   autocreate 1
   clientId   WX/USER/123456/FHEM/12345678-f33f-965f-66d8-12122b6c7aaa222f
   connecting 1
   devioLoglevel 5
   eventCount 2
   landroidType worx
   mqttEndpoint iot.eu-west-1.worxlandroid.com
   nextOpenDelay 180
   nrConnects 1
   nrFailedConnects 1
   userId     12345
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2023-04-19 10:11:58   state           disconnected
     2023-04-18 19:53:33   wxid            12345678-f33f-965f-66d8-202932372457243
   sslargs:
     SSL_alpn_protocols mqtt
Attributes:
   connectFn  {use LandroidUtils;;Landroid_connect($NAME,"worx",1)}
   disable    0
   execAfterConnect { my $h=$defs{$NAME};MQTT2_CLIENT_doPublish($h,'DB510/12345678/commandIn','{}')}
   keepaliveTimeout 600
   maxFailedConnects 1
   nextOpenDelay 180
   room       MQTT2_DEVICE
   subscriptions DB510/123456789/commandOut
   username   mail@mail.de
   verbose    5

also das Haupt-Device sollte eigentlich immer auf "opened" stehen, oder?
Da es das bei mir nicht macht, brauche ich am Mäher-Device gar nicht weiter probieren. Dort kommen halt nur diese Standard-Readings an.

Bin momentan etwas ratlos.

frober · 19 April 2023, 10:24:48

@Rudi, ich habe weiter getestet...

Das alte Device gelöscht, das Neue umbenannt und mit dem Template angepasst.
Mit autocreate 1 wird wieder ein neues Device mit den Mowerdaten angelegt, die MQTT-Daten gehen jedoch nur in das alte Device und ohne die Mowerdaten (evtl. wg. dem Template oder weil der Client es nicht "kennt".
Wenn ich das neue Device lösche, wird es beim nächsten connect wieder angelegt.
Lösche ich es und setze autocreate auf 0 gibt es beim nächsten connect wieder ein ständiges dis-/connect.

Mache erstmal Pause, damit ich nicht wieder gesperrt werde...

frober · 19 April 2023, 10:40:05

Zitat von: fred_feuerstein am 19 April 2023, 10:20:54
Zitat von: frober am 19 April 2023, 09:38:44ich kann nur spekulieren...
Hast du im Fhemweb, in der Regel "WEB", bei attr sslVersion etwas definiert?
MQTT benötigt TLSv12

sslVersion war bei mir gar nicht definiert. Habe es nun auf TLSv12 gesetzt.

hat aber nach erneutem fhem Neustart auch nichts gebracht.

Hier mal ein list vom Haupt-Device:
ZitatInternals:

clientId WX/USER/xxxx/FHEM/xxxx
userId xxxx

READINGS:
2023-04-19 10:11:58 state disconnected
2023-04-18 19:53:33 wxid xxxx

Attributes:
execAfterConnect { my $h=$defs{$NAME};MQTT2_CLIENT_doPublish($h,'DB510/xxxx/commandIn','{}')}
subscriptions DB510/xxx/commandOut

also das Haupt-Device sollte eigentlich immer auf "opened" stehen, oder?
Da es das bei mir nicht macht, brauche ich am Mäher-Device gar nicht weiter probieren. Dort kommen halt nur diese Standard-Readings an.

Bin momentan etwas ratlos.

Bitte sslVersion wieder löschen, der Default ist von Fhem aus richtig gesetzt.
Korrigieren bitte auch deinen Post und ersetzt deine Daten wir von mit rot gekennzeichnet.

Der Client sollte auf opened steht und auch bleiben. Es erfolgt alle Std + x Min ein reconnect.
Momentan sehe ich keine Fehler, was steht im Log (verbose 4 reicht, ist default)?

Edit:
was für ein Log hattest du gepostet? Das ist nicht das Fhemlog (Logfile in Fhemweb)...

rudolfkoenig · 19 April 2023, 10:58:24

Zitatautocreate 0 macht Probleme. Auch beim nachträglichen Setzen.

Habs offensichtlich nicht getestet.
Ursache war, dass nur damit subscription berechnet wurde, und die Gegenseite reagiert allergisch auf falsche subscriptions. Wuerde ich in der gleichen Situation auch.
Habs jetzt gefixt.

ZitatBei mir hat es heute Nacht zugeschlagen, bin nun erstmal komplett gesperrt...auch die AndroidApp usw.

Leider greifte in diesem Fall nextOpenDelay und maxFailedConnects nicht.
Ich habe das jetzt fuer nextOpenDelay gefixt, allerdings fehlt mir die Energie fuer maxFailedConnects.

Die neue Version ist wie erwaehnt sofort aus SVN oder morgen ab 7:45 + Processing-Time per FHEM-Update zu holen

fred_feuerstein · 19 April 2023, 11:15:53

Zitat von: frober am 19 April 2023, 10:40:05Der Client sollte auf opened steht und auch bleiben. Es erfolgt alle Std + x Min ein reconnect.
Momentan sehe ich keine Fehler, was steht im Log (verbose 4 reicht, ist default)?

Edit:
was für ein Log hattest du gepostet? Das ist nicht das Fhemlog (Logfile in Fhemweb)...

(hatte die meisten IDs aus meinem List schon vorher auf Phantasiewerte gesetzt. Hab die restlichen auch noch geändert, danke)

hatte das Log vom Device gepostet. Hier der Auszug aus fhemlog (der erste Block noch mit verbose 5, Rest dann mit verbose 4)

Code Auswählen

2023.04.19 10:56:24 4: MQTT_Worx: reusing the acess_token
2023.04.19 10:56:24 5: {"id":75595,"user_type":"customer","push_notifications":true,"location":null,"mqtt_endpoint":"a1optpg91s0ydf-ats.iot.eu-west-1.amazonaws.com","actions_on_google_pin_code":null,"created_at":"2018-07-04 19:10:33","updated_at":"2020-05-16 00:00:23"}
2023.04.19 10:56:24 4: MQTT_Worx: Got userId: 75595
2023.04.19 10:56:24 5: [{"id":240315,"uuid":"..... alle statischen Readings werden geholt ...1}}}}]
2023.04.19 10:56:24 4: MQTT_Worx: Got device info
2023.04.19 10:56:24 5: MQTT_Worx: discarding DISCONNECT (224)(0)
.
.
.
2023.04.19 10:59:34 4: MQTT_Worx: reusing the acess_token
2023.04.19 10:59:39 4: MQTT_Worx: Got userId: 75595
.
.
2023.04.19 10:59:58 1: ERROR: Landroid_connect3 MQTT_Worx - start_SSL https://api.worxlandroid.com:443 timed out
.
.
2023.04.19 11:02:58 4: MQTT_Worx: reusing the acess_token
2023.04.19 11:02:58 4: MQTT_Worx: Got userId: 75595
2023.04.19 11:02:59 4: MQTT_Worx: Got device info
2023.04.19 11:02:59 4: IP: iot.eu-west-1.worxlandroid.com -> 52.214.209.63


nach einem Neustart von FHEM kam auch diese Zeile im Log:
2023.04.19 11:30:26 1: ERROR: Landroid_connect MQTT_Worx - no username attribute
Aber auch nur einmal, danach kam wieder der Block mit reusing the Access Token etc.

Habe nun bereits die neueste Version von Rudolf installiert.

Ralli · 19 April 2023, 11:55:32

Zitat von: rudolfkoenig am 19 April 2023, 10:58:24Die neue Version ist wie erwaehnt sofort aus SVN oder morgen ab 7:45 + Processing-Time per FHEM-Update zu holen

Vielen Dank. Läuft hier.

rudolfkoenig · 19 April 2023, 12:06:51

Zitat2023.04.19 10:56:24 5: MQTT_Worx: discarding DISCONNECT (224)(0)

Das bedeutet entweder Muell in der Leitung, oder ein MQTT-Disconnect Nachricht, bevor unser CONNECT mit CONNACK bestaetigt wuurde. Ich habe das noch nie selbst erlebt.
Wenn jemand das reproduzieren kann, bitte mit dem "HOWTO" melden.

Zitat2023.04.19 10:59:58 1: ERROR: Landroid_connect3 MQTT_Worx - start_SSL https://api.worxlandroid.com:443 timed out

Problem auf der anderen Seite, "kann man nix machen"

Zitat2023.04.19 11:30:26 1: ERROR: Landroid_connect MQTT_Worx - no username attribute

Ich hoffe diese Meldung ist klar, wenn nicht, bitte um Verbesserungsvorschlag.

fred_feuerstein · 19 April 2023, 12:20:12

die letzte Meldung ist zwar klar, aber ich verstehe nicht warum. Am Device hat sich nach der Einrichtung nichts geändert. Somit ist dort per attr auch der Username hinterlegt. Warum dann irgendwann einmal diese Meldung kommt, kann ich mir deshalb nicht erklären.

kann ich sonst noch etwas testen? Sonst setze ich das Device erstmal auf disable und hoffe dass mir oder jemandem von euch noch eine Idee kommt.

Der User efyzz hatte ja glaube ich das gleiche Problem.

//edit: gerade mal die neue DeskApp 0.31 unter Windows11 probiert. Dort läuft es. Also genau wie in der Android App. Nutzt halt leider nichts für die fhem Integration. Ausser, dass zumindest die Login-Daten zu stimmen scheinen

frober · 19 April 2023, 12:39:38

Die Error Meldung habe ich auch schon gepostet, die Funktion ist trotzdem gegeben.
D.h. während des Starts von Fhem ist das gesetzte attr username noch nicht für LandroidUtils verfügbar.
Die Meldung kommt noch vor

Code Auswählen

Including /opt/fhem/log/fhem.save, keine Ahnung, ob das damit zusammen hängt.

@Rudi wäre $hash->{NR} eine Lösung, d.h. Nr. hoch setzen damit der Client bzw. LandroidUtils erst später initialisiert wird?

Die aktuelle Version hat noch Probleme, ~~mit autocreate 1~~ es wird alle "nextOpenDelay" ein reconnect ausgeführt (bei mit aktuell alle 60s), trotz erfolgreichem connect.
Edit: es fehlt wahrscheinlich die Überprüfung auf "state opened"

Ein neues Device wird, wenn ein umbenanntes vorhanden ist, nicht mehr angelegt.

~~Mit autocreate 0 bekomme ich kein connect.~~

Zitat2023.04.19 12:18:25 1: ERROR evaluating my $NAME= $evalSpecials->{'%NAME'};{use LandroidUtils;;Landroid_connect(MQTT2_Worx,"worx",0)}: Bareword "MQTT2_Worx" not allowed while "strict subs" in use at (eval 31087) line 1.

Edit: ~~Der Name wird aktuell direkt gesetzt, aber ohne Quotes. Habe es bei korrigiert, dann funktioniert autocreate 0.~~ Hmm, bin mir gerade nicht sicher, ob ich das war...aktuell habe ich es wieder auf $NAME geändert, damit funktioniert autocreate 0, aber auch mit ständigem reconnect.

~~Mowerdaten habe ich keine im Devcice, sollten auch nicht nötig sein!?~~

frober · 19 April 2023, 13:42:21

@Rudi, Zeile 57,58 geändert auf

Code Auswählen

if(!$noToCheck && $m2c->{".CONNECT_TO"} &&
    gettimeofday() < $m2c->{".CONNECT_TO"} && DevIo_getState($m2c) eq 'disconnected"') {

scheint erstmal zu funktionieren, keine Ahnung ob es Nebenwirkungen gibt...

...und "%types -> ferrex => {..." würde ich raus nehmen, laut PositecBeta gibt es das nicht (mehr).

rudolfkoenig · 19 April 2023, 14:48:06

ZitatD.h. während des Starts von Fhem ist das gesetzte attr username noch nicht für LandroidUtils verfügbar.

Ich wuesste gerne, was Ihr wieder fuer Sonderkonfiguration hingekriegt habt.
MQTT-Connect (und damit die connectFn Auswertung) wird per InternalTimer gestartet, die Abarbeitung laeuft erst los, wenn alles eingelesen wurde.

Zitatkeine Ahnung ob es Nebenwirkungen gibt...

Entspricht einem "unter dem Teppich kehren" Aktion.
Ich frag mich, wieso ich kein Problem damit habe, Du hast vmtl. neben "starten und laufen lassen" noch was gemacht (fhem.cfg editiert / reloadcfg / Landroid_connect direkt aufgerufen, etc).
Das Problem kann ich nur fixen, wenn ich mehr weiss, bei mir laeuft es laut verbose 4 problemlos.

Zitatkann ich sonst noch etwas testen?

Einen Anmeldeversuch starten mit "attr global verbose 5", und das komplette Log hier posten.

Man kann dafuer auch ein separates FHEM verwenden:
- in /opt/fhem fhem.cfg.landroid erstellen mit folgenden Inhalt:

Zitatdefine m2c MQTT2_CLIENT XX
attr m2c connectFn {use LandroidUtils;;Landroid_connect($NAME,"worx",1)}
attr m2c username user@host
set m2c password geheim

- FHEM im Terminal starten mit "perl fhem.pl -d fhem.cfg.landroid", und die Ausgabe hier als Datei anhaengen