MQTT2 für Worx Landroid Mähroboter

[frober]

Mir fällt gerade auf, ich habe noch

Code Auswählen Erweitern

attr m2c mqttVersion 3.1.1
gesetzt. Da ich den alten Client weiter verwende.

Möglich dass das nicht setzen Probleme verursacht. AWS fordert  min. 3.1.1
Fhem Standard ist 3.1

[efyzz]

Das ist bei mir auch gesetzt, daran liegt es nicht.

Neustart nützt auch nichts. 

Set connect bringt einen neuen Datensatz und dann ist es wieder disconnected.

Finde es aber interessant, dass du noch "m2c" verwendest. Das Template verlangt scheinbar, dass das Device "MQTT_Worx" heißen muss. Jedenfalls wird dies als IODev gesetzt, wenn man das Template anwendet.

[frober]

In der DEF die du gepostet hast ist es nicht gesetzt.

m2c habe ich nur für hier, da Rudi damit "angefangen" hat

Das Template setzt du im Device und es zieht den Namen von IODev (Client)
Ich verwende auch noch "MQTT_Worx".

[rudolfkoenig]

Wie aktualisierst du die Änderung, jedesmal durch Neustart?

Ich entwickele mit 3 Terminal Fenster: Editor, FHEM mit einer minimalen fhem.cfg und Ausgabe im Terminal, und ein "telnet" Fenster, wo ich FHEM Befehle eingebe. Mit "telnet" meine ich ein alias zu "socat TCP:!:1\:!:2 READLINE,history=~/.telnet_history", damit ich die Befehle nicht immer  neu eintippen muss. Nach Aenderung des Programmes starte ich FHEM meist neu.
Will aber nicht behaupten, dass dieses Setup fuer alle perfekt ist.

[efyzz]

In der DEF die du gepostet hast ist es nicht gesetzt.

Das ist spannend. Scheinbar ist es erst nach dem Neustart aufgetaucht?! Ich habe es jedenfalls nicht nachträglich gesetzt. 

[frober]

In der DEF die du gepostet hast ist es nicht gesetzt.

Das ist spannend. Scheinbar ist es erst nach dem Neustart aufgetaucht?! Ich habe es jedenfalls nicht nachträglich gesetzt. 

mqttVersion 3.1.1 wird über die LandroidUtils gesetzt

Ich schreibe meist am Handy und kann deshalb nicht immer nachschauen...
Mir ist es nur in deinem Post aufgefallen, dass es gefehlt hat.

Funktioniert es mittlerweile?

Bei mir hat heute Nacht der Watchdog zugeschlagen und eine Reconnect ausgelöst.
Bis auf die Zwangstrennung läuft es stabil bei mir.

Mit maxFailedConnects und nextOpenDelay muss ich noch weiter testen.

[efyzz]

Funktioniert es mittlerweile?

Leider unverändert. Interessanterweise hatten die Readings alle einen nur 10min alten Zeitstempel, als ich eben nachgeschaut habe. Also als wäre gerade aktualisiert worden. Und das, obwohl der MQTT Client die ganze Zeit disconnected war.

Also habe ich ins Logfile geschaut, da steht aber nichts drin außer

Code Auswählen Erweitern

2023-04-11_21:50:27 MQTT_Worx_M attrTemplateVersion: 20221101
Warum landen denn keine Readings im Log? Das Attribut event-on-change-reading habe ich schon gelöscht, hat nichts genützt.

Irgendwie ist da total der Wurm drin. 

Hier noch die Def des Logfiles

Code Auswählen Erweitern

define FileLog_MQTT_Worx_M FileLog /media/usb/fhem_log/MQTT_Worx_M-%Y.log MQTT_Worx_M|MQTT_Worx_M:.*
attr FileLog_MQTT_Worx_M logtype text
attr FileLog_MQTT_Worx_M room MQTT2_DEVICE
#   CFGFN     
#   DEF        /media/usb/fhem_log/MQTT_Worx_M-%Y.log MQTT_Worx_M|MQTT_Worx_M:.*
#   FD         91
#   FUUID      6435ba18-f33f-6f7b-d5c8-d13260534316647f
#   NAME       FileLog_MQTT_Worx_M
#   NOTIFYDEV  MQTT_Worx_M
#   NR         26404
#   NTFY_ORDER 50-FileLog_MQTT_Worx_M
#   REGEXP     MQTT_Worx_M|MQTT_Worx_M:.*
#   STATE      active
#   TYPE       FileLog
#   currentlogfile /media/usb/fhem_log/MQTT_Worx_M-2023.log
#   eventCount 1
#   logfile    /media/usb/fhem_log/MQTT_Worx_M-%Y.log
#
setstate FileLog_MQTT_Worx_M active



[frober]

Funktioniert es mittlerweile?

Leider unverändert. Interessanterweise hatten die Readings alle einen nur 10min alten Zeitstempel, als ich eben nachgeschaut habe. Also als wäre gerade aktualisiert worden. Und das, obwohl der MQTT Client die ganze Zeit disconnected war.

Wenn der Client disconnect ist, kann nichts passieren. Was steht im Fhem log?

Bzw. setze im Client verbose auf 5 und starte neu (speichern nicht vergessen), wenn der Client auf disconnect bleibt, noch ein manuelles set ... connect.
Dann den entsprechenden Auszug aus dem log posten.
Bitte user/passwort/userID/access_token/refresh_token/clientID durch x ersetzen.

[Ralli]

Also bei mir ist seit vorgestern auch wieder "dunkel" und ich habe den Client auch nicht wieder zum Connect bewegen können. Die Stammdaten des Mähers bekomme ich aktualisiert, der eigentliche Connect findet nicht (mehr) statt und die eigentlichen Mäher-Daten werden dementsprechend auch nicht aktualisiert - der Mäher war gestern den ganzen Tag online und aktiv.

Edit:
Kaum geschrieben und nochmal ein shutdown restart gemacht und schon ist der Client wieder online. Es ist verhext.

[rudolfkoenig]

Interessanterweise hatten die Readings alle einen nur 10min alten Zeitstempel, als ich eben nachgeschaut habe. Also als wäre gerade aktualisiert worden. Und das, obwohl der MQTT Client die ganze Zeit disconnected war.

Einmal die Stunde wird Landroid_connect ausgefuehrt, und nach aktualisieren des access_tokens wird User- und Device-Info geholt, bevor ein MQTT-Connect durchgefuehrt wird. Falls man im Aufruf des Landroid_connects als letztes Parameter 1 geschrieben hat, dann werden die bei Device-Info geholten Daten auch als Reading eingetragen bzw. aktualisiert.

Vmtl. geht in dem geschilderten Fall Device-Info gut, aber MQTT-Connect geht schief.

[frober]

Vor kurzen hatte ich aus einer anderen Quelle die Info, dass es zur Zeit sehr viele unauthorisierte Zugriffe auf die Server gibt, was diese belastet. Möglich das das Probleme bereitet. Keine Ahnung ob das immer noch zutrifft.

Bei mir gibt es weiterhin keine Probleme.
Nach einem Setzen von nextOpenDelay auf 180 hat auch der auto. reconnect nach der Zwangstrennung funktioniert.

@Rudi wäre es möglich, nextOpenDelay als attr zu implementieren? 180 sec ist evtl. nicht für alle Anwendungen sinnvoll.

Bei maxFailedConnects bin ich mir nicht sicher, was angemessen ist.
Zu viel müllt bei einem längeren Serverausfall das Log zu, zu wenig erfordert das manuelle Eingreifen.

Bsp.

Code Auswählen Erweitern

nextOpenDelay 180
maxFailedConnects 20Damit wäre ein Ausfall von einer Std überbrückt...
Bzg. Sperre, diese sollte bei einem Serverausfall nicht zum tragen kommen.

oder ein

Code Auswählen Erweitern

maxFailedConnects 100 für 5 Std?

Was mir aber seltsam vorkommt, mit

Code Auswählen Erweitern

nextOpenDelay 60
maxFailedConnects 3hätte es doch mit der Zwangstrennung auch funktionieren müssen (3 x 60 = 180).
Erfolgt bei gesetztem maxFailedConnects überhaupt ein auto. reconnect?
Im Log war davon nichts zu sehen.


Lange vor der Umstellung hatte ich die Bestätigung von Positect, dass bei mehr als 150 Anfragen pro Tag für 24h gesperrt wird. vermutlich ist das immer noch so.
Bei dem gesetzten und empfohlenen "keepaliveTimeout 600" sind das 144! 
D.h. wenn durch dein Doif, watchdog etc. zu häufig versucht wird ein connect herzustellen, könnte das zum Tragen kommen. Da hilft dann nur ein disable vom Client für 24h.

[efyzz]

Was steht im Fhem log?

Bzw. setze im Client verbose auf 5 und starte neu (speichern nicht vergessen), wenn der Client auf disconnect bleibt, noch ein manuelles set ... connect.
Dann den entsprechenden Auszug aus dem log posten.

Code Auswählen Erweitern

2023.04.12 11:09:29 5: {"token_type":"Bearer","expires_in":3600,"access_token":"xxx"}
2023.04.12 11:09:29 4: MQTT_Worx: Got auth info, request: refresh_token
2023.04.12 11:09:29 5: {"id":225193,"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":"2019-07-07 17:31:23","updated_at":"2020-05-17 17:15:44"}
2023.04.12 11:09:29 4: MQTT_Worx: Got userId: 225193
2023.04.12 11:09:29 5: [{"id":379013,"uuid":"96c52e42-951a-4002-9814-2224832xxxxx","product_id":49,"user_id":225xxx,"serial_number":"201930198403010xxxxx","mac_address":"98D86346xxxx","name":"M","locked":true,"firmware_version":3.2800000000000002,"firmware_auto_upgrade":false,"push_notifications":true,"sim":null,"push_notifications_level":"warning","test":false,"iot_registered":true,"mqtt_registered":true,"pin_code":null,"registered_at":"2019-07-07 00:00:00","online":true,"app_settings":null,"protocol":0,"pending_radio_link_validation":null,"capabilities":["auto_lock","digital_fence_settings","lock","mqtt","multi_zone","multi_zone_percentage","one_time_scheduler","pairing_smartlink","pause_over_wire","rain_delay","rain_delay_start","safe_go_home","scheduler_two_slots","unrestricted_mowing_time"],"capabilities_available":[],"features":{"auto_lock":3.25,"chassis":"m_2019","digital_fence_settings":3.25,"display_type":"tube","input_type":"keyboard_tube","lock":true,"mqtt":true,"multi_zone":true,"multi_zone_percentage":true,"multi_zone_zones":4,"one_time_scheduler":3.15,"pause_over_wire":3.26,"rain_delay":true,"rain_delay_start":3.08,"safe_go_home":3.25,"scheduler_two_slots":3.15,"unrestricted_mowing_time":true,"wifi_pairing":"smartlink"},"accessories":{"ultrasonic":true},"mqtt_endpoint":"iot.eu-west-1.worxlandroid.com","mqtt_topics":{"command_in":"PRM100\/98D863460BFC\/commandIn","command_out":"PRM100\/98D863460BFC\/commandOut"},"warranty_registered":true,"purchased_at":"2019-07-06 00:00:00","warranty_expires_at":"2022-07-06 00:00:00","setup_location":{"latitude":52.xxx,"longitude":10.xxx},"city":{"id":6552xxx,"country_id":276,"name":"xxx","latitude":52.xxx,"longitude":10.xxx,"created_at":"2018-02-15 22:22:41","updated_at":"2018-02-15 22:22:41"},"time_zone":"Europe\/Berlin","lawn_size":800,"lawn_perimeter":151,"auto_schedule_settings":{"boost":0,"exclusion_scheduler":{"days":[{"slots":[],"exclude_day":false},{"slots":[],"exclude_day":false},{"slots":[],"exclude_day":false},{"slots":[],"exclude_day":false},{"slots":[],"exclude_day":false},{"slots":[],"exclude_day":false},{"slots":[],"exclude_day":false}],"exclude_nights":true},"grass_type":null,"irrigation":null,"nutrition":null,"soil_type":null},"auto_schedule":false,"improvement":false,"diagnostic":false,"distance_covered":1285292,"mower_work_time":83903,"blade_work_time":78382,"blade_work_time_reset":78314,"blade_work_time_reset_at":"2023-04-10 17:45:33","battery_charge_cycles":651,"battery_charge_cycles_reset":null,"battery_charge_cycles_reset_at":null,"created_at":"2019-04-02 07:20:05","updated_at":"2023-04-11 01:16:13","last_status":{"timestamp":"2023-04-12 09:08:12","payload":{"cfg":{"id":2,"sn":"201930198403010xxxxx","dt":"12\/04\/2023","tm":"11:08:10","lg":"en","cmd":0,"sc":{"m":1,"d":[["00:00",0,0],["13:00",195,1],["13:00",195,0],["13:00",195,0],["13:00",195,0],["13:00",195,1],["00:00",0,0]],"dd":[["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0]],"distm":0,"p":0,"ots":{"wtm":0,"bc":0}},"mz":[6,7,8,9],"mzv":[0,1,2,3,0,1,2,3,0,1],"rd":60,"al":{"lvl":0,"t":60},"tq":0,"modules":{"US":{"enabled":1}}},"dat":{"mac":"98D863460BFC","fw":3.2800000000000002,"fwb":1,"ls":1,"le":0,"conn":"wifi","bt":{"t":8.4,"v":19.86,"p":97,"nr":651,"c":1,"m":1},"dmp":[2.5,-0.2,225.9],"st":{"b":78382,"d":1285292,"wt":83903,"bl":151},"act":1,"rsi":-88,"lk":1,"tr":0,"lz":9,"rain":{"s":0,"cnt":0},"modules":{"US":{"stat":"ok"}}}}}}]
2023.04.12 11:09:29 4: MQTT_Worx: Got device info
2023.04.12 11:09:29 5: MQTT_Worx: discarding DISCONNECT (224)(0)
2023.04.12 11:09:29 5: HttpUtils url=https://iot.eu-west-1.worxlandroid.com:443/ NonBlocking via https
2023.04.12 11:09:29 4: IP: iot.eu-west-1.worxlandroid.com -> 54.72.252.151


Lange vor der Umstellung hatte ich die Bestätigung von Positect, dass bei mehr als 150 Anfragen pro Tag für 24h gesperrt wird.

Heißt das, dass man nur max. 150 Datensätze pro Tag bekommt? Früher wurde ca. alle 3 min aktualisiert. Oder darf man 150x am Tag connecten, es reicht jedoch ein connect, und dann kommen die Daten quasi automatisch zyklisch?

[rudolfkoenig]

@Rudi wäre es möglich, nextOpenDelay als attr zu implementieren? 180 sec ist evtl. nicht für alle Anwendungen sinnvoll.

Habs eingebaut, LandroidUtils.pm mit 180/20 angepasst.

Erfolgt bei gesetztem maxFailedConnects überhaupt ein auto. reconnect?

Ja, siehe den nrFailedConnects Zaehler.

Bei dem gesetzten und empfohlenen "keepaliveTimeout 600" sind das 144!

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


@efyzz: im Log waeren die naechsten Zeilen interessant. Bis dahin ist alles nach Plan.
"discarding DISCONNECT" ist zwar verwirrend, kommt aber vom Modul, und ist Schoenheitsfehler.

[frober]

Habs eingebaut, LandroidUtils.pm mit 180/20 angepasst.

Danke

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

Dann habe ich das auch missinterpretiert, sorry.
Ping ist klar, war nur der Meinung, das dadurch auch Daten angefordert/gesendet werden.


@efyzz
Antwort von Positec am 26.08.21:

Ihr Gerät sendet uns täglich um die 150 Nachrichten oder versucht mehr zu senden. 150 ist tatsächlich das Maximale, was raus gesendet werden kann und sollte mit der normalen Software nur schwer zu erreichen sein bis zu unmöglich. Wenn die Nachrichten am Maximum angekommen sind, kommt es dazu, das Ihr Konto für 24 Stunden gesperrt wird, das bekommen Sie gar nicht mit und passiert auch automatisch.

[frober]

@Rudi, eine Kleinigkeit noch.
Falls hier

Code Auswählen Erweitern

connectFn {use LandroidUtils;;Landroid_connect($NAME,"worx",1)} autocreate auf 0 oder nicht angegeben ist, gibt es beim Neustart eine perl warnung.

Bei mir habe ich es angepasst:

Code Auswählen Erweitern

-  $m2c->{autocreate} = 1 if($autocreate);
+  $m2c->{autocreate} = $autocreate?1:0;