MQTT2 für Worx Landroid Mähroboter

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

Vorheriges Thema - Nächstes Thema

frober

#315
Zitat von: Otto123 am 27 August 2021, 23:11:32
Hi,

der MQTT2 Server spielt keine Rolle, die Verbindung macht ja der MQTT2_Client :)

Ich weiß nicht was mit kontaktieren gemeint ist, der Verbindungsaufbau wird ja im LogFile geloggt. Bei mir ist das ca. einer am Tag. Ansonsten dürften ja die meisten MQTT Nachrichten vom Mäher kommen.

Gruß Otto

Danke Otto, Client klar ::), so hatte ich das auch vermutet.
Wollte nur sicher gehen...
Ich habe auch nur einen Zugriff und konnte bisher keine Sperre erkennen...

Evtl. verursacht das der Mäher, da ich Stellen mit schlechtem WLAN habe!?

Grüße Bernd
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...

efyzz

Nabend,

ich habe seit einiger Zeit das Problem, dass der Landroid keine von FHEM gesendeten Befehle mehr ausführt. Es hat bis vor kurzem noch funktioniert, ohne dass ich FHEM-seitig etwas geändert hätte. Empfangen werden die Daten vom Landroid jedoch wie gewohnt. Da ich nur selten einen Befehl absende, kann ich nicht genau sagen, seit wann es nicht mehr funktioniert. Möglicherweise seit dem Update auf FW 3.25?

Wurde mit dem Update irgendwas geändert, was ich auch FHEM-seitig hätte anpassen müssen?

Kann es an der Client ID oder am Zertifikat liegen? Aber dann dürfte FHEM ja auch nichts mehr empfangen oder?

Hier meine vollständige Definition, vielleicht entdeckt ja jemand etwas (Client ID und MAC hier natürlich absichtlich verstümmelt).

Danke!

defmod Landroid MQTT2_DEVICE android_daa37b01_5e39_486b_b096_xxxxxxxxxxx_
attr Landroid IODev MQTT_Worx
attr Landroid event-on-change-reading .*
attr Landroid group 06_Garten
attr Landroid icon scene_robo_lawnmower
attr Landroid jsonMap dat_rsi:wifiQuality dat_fw:firmware cfg_sn:SerialNumber\
dat_le:mowerError dat_ls:mowerStatus\
cfg_rd:mowerRainDelay cfg_sc_m:mowerActiveIndex cfg_sc_p:mowerTimeCorrection\
dat_bt_t:batteryTemperature dat_bt_v:batteryVoltage dat_bt_p:batteryLevel dat_bt_nr:batteryChargeCycle dat_bt_c:batteryCharging\
dat_st_b:bladeTimeCounter dat_st_d:totalDistance dat_st_wt:totalTime dat_st_bl:borderLength\
dat_dmp_1:directionPitch dat_dmp_2:directionRoll dat_dmp_3:directionYaw\
cfg_sc_d_1_1:calendarWeekday0StartTime cfg_sc_d_1_2:calendarWeekday0WorkTime cfg_sc_d_1_3:calendarWeekday0BorderCut\
cfg_sc_d_2_1:calendarWeekday1StartTime cfg_sc_d_2_2:calendarWeekday1WorkTime cfg_sc_d_2_3:calendarWeekday1BorderCut\
cfg_sc_d_3_1:calendarWeekday2StartTime cfg_sc_d_3_2:calendarWeekday2WorkTime cfg_sc_d_3_3:calendarWeekday2BorderCut\
cfg_sc_d_4_1:calendarWeekday3StartTime cfg_sc_d_4_2:calendarWeekday3WorkTime cfg_sc_d_4_3:calendarWeekday3BorderCut\
cfg_sc_d_5_1:calendarWeekday4StartTime cfg_sc_d_5_2:calendarWeekday4WorkTime cfg_sc_d_5_3:calendarWeekday4BorderCut\
cfg_sc_d_6_1:calendarWeekday5StartTime cfg_sc_d_6_2:calendarWeekday5WorkTime cfg_sc_d_6_3:calendarWeekday5BorderCut\
cfg_sc_d_7_1:calendarWeekday6StartTime cfg_sc_d_7_2:calendarWeekday6WorkTime cfg_sc_d_7_3:calendarWeekday6BorderCut\
cfg_sc_dd_1_1:calendar2Weekday0StartTime cfg_sc_dd_1_2:calendar2Weekday0WorkTime cfg_sc_dd_1_3:calendar2Weekday0BorderCut\
cfg_sc_dd_2_1:calendar2Weekday1StartTime cfg_sc_dd_2_2:calendar2Weekday1WorkTime cfg_sc_dd_2_3:calendar2Weekday1BorderCut\
cfg_sc_dd_3_1:calendar2Weekday2StartTime cfg_sc_dd_3_2:calendar2Weekday2WorkTime cfg_sc_dd_3_3:calendar2Weekday2BorderCut\
cfg_sc_dd_4_1:calendar2Weekday3StartTime cfg_sc_dd_4_2:calendar2Weekday3WorkTime cfg_sc_dd_4_3:calendar2Weekday3BorderCut\
cfg_sc_dd_5_1:calendar2Weekday4StartTime cfg_sc_dd_5_2:calendar2Weekday4WorkTime cfg_sc_dd_5_3:calendar2Weekday4BorderCut\
cfg_sc_dd_6_1:calendar2Weekday5StartTime cfg_sc_dd_6_2:calendar2Weekday5WorkTime cfg_sc_dd_6_3:calendar2Weekday5BorderCut\
cfg_sc_dd_7_1:calendar2Weekday6StartTime cfg_sc_dd_7_2:calendar2Weekday6WorkTime cfg_sc_dd_7_3:calendar2Weekday6BorderCut\
cfg_rd:changeRainDelay\
cfg_mz_1:areasArea1 cfg_mz_2:areasArea2 cfg_mz_3:areasArea3 cfg_mz_4:areasArea4\
dat_rain_cnt:rainDelayRemaining
attr Landroid model worx_landroid_mover
attr Landroid readingList PRM100/98D86346xxxx/commandOut:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr Landroid room Garten,MQTT2_DEVICE,QuickFHEM,Übersicht
attr Landroid setList mowerRainDelay:slider,0,30,1440 PRM100/98D86346xxxx/commandIn {"rd":$EVTPART1}\
  mowerTimeCorrection:slider,-100,1,100 PRM100/98D86346xxxx/commandIn {"sc":{"p":$EVTPART1}}\
  startBorderCut:noArg PRM100/98D86346xxxx/commandIn {"sc":{"ots":{"bc":1,"wtm":0}}}\
  startOneTime:slider,10,10,720 PRM100/98D86346xxxx/commandIn {"sc":{"ots":{"bc":0,"wtm":$EVTPART1}}}\
  startParty:slider,60,60,2880 PRM100/98D86346xxxx/commandIn {"sc":{"distm":$EVTPART1}}\
  startMower:noArg PRM100/98D86346xxxx/commandIn {"cmd":1}\
  pauseMower:noArg PRM100/98D86346xxxx/commandIn {"cmd":2}\
  stopMower:noArg PRM100/98D86346xxxx/commandIn {"cmd":3}\
  x_raw_payload:textField { my $payload = $EVENT;;$payload =~ s/$EVTPART0 //g;; qq(PRM100/98D86346xxxx/commandIn $payload)}
attr Landroid sortby 00
attr Landroid stateFormat mowerStatusTxt, mowerErrorTxt<br>RainDelay: rainDelayRemaining min<br>Akku: batteryLevel % (batteryVoltage V)<br>Messer: bladeTimeCounterH h
attr Landroid userReadings mowerActive:mowerActiveIndex:.* {my %activeState = (\
0 => "false",\
1 => "true",\
2 => "Party"\
);; $activeState{ReadingsVal($name,"mowerActiveIndex","0")}},\
mowerStatusTxt:mowerStatus.* {my %stateCodes = (\
0 => "Idle",\
1 => "Home",\
2 => "Start sequence",\
3 => "Leaving home",\
4 => "Follow wire",\
5 => "Searching home",\
6 => "Searching wire",\
7 => "Mowing",\
8 => "Lifted",\
9 => "Trapped",\
10 => "Blade blocked",\
11 => "Debug",\
12 => "Remote control",\
30 => "Going home",\
31 => "Zone Training",\
32 => "Edge cutting",\
33 => "Searching zone",\
34 => "Pause"\
);; $stateCodes{ReadingsVal($name,"mowerStatus","0")}},\
mowerErrorTxt:mowerError.* { my %errorCodes = (\
0 => "No error",\
1 => "Trapped",\
2 => "Lifted",\
3 => "Wire missing",\
4 => "Outside wire",\
5 => "Raining",\
6 => "Close door to mow",\
7 => "Close door to go home",\
8 => "Blade motor blocked",\
9 => "Wheel motor blocked",\
10 => "Trapped timeout",\
11 => "Upside down",\
12 => "Battery low",\
13 => "Reverse wire",\
14 => "Charge error",\
15 => "Timeout finding home",\
16 => "Mower locked",\
17 => "Battery temp out of range"\
);; $errorCodes{ReadingsVal($name,"mowerError","0")}},\
bladeTimeCounterH {ReadingsVal("Landroid","bladeTimeCounter","0") / 60 },\
batteryChargingBool {ReadingsVal("Landroid","batteryCharging","0")}
RaspberryPi3B, Bookworm Lite
Homematic Funkmodul HM-MOD-RPI-PCB
------------------------------------------------------------------------
Ich bin kein Programmierer ... aber ich weiß, auf welcher Seite der Lötkolben heiß ist.

Otto123

Hi,

die Beschreibung verwundert mich. Ich habe auch die Firmware 3.25 und die Steuerung geht. Überprüfe bitte die Funktion Deines MQTT_Worx Devices. Ich vermute Du bist geblockt. Ich hatte auch schon den Fall, die Daten in der App wurden aktualisiert, Steuerung ging aber nicht. Allerdings war in dem Zustand FHEm völlig "draußen" d.h. da kamen auch keine Daten mehr an.
Funktioniert der Zugriff mit der Windows App?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

FosCo

Wie schicke ich bei "PartyTime" noch den "PartyMode" auf 0 vorweg?
Auf 1 und 2 funktioniert der Timer nicht :)

Otto123

Hallo FosCo,

wundert mich, ich behaupte das hat mal funktioniert? Ich verwende das nicht, wenn Du meinst, dann setzt mal sowas über x_raw_payload ab:
Die 8 steht für 8 minuten ;)
{"sc":{"m":0,"distm":8}}

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frober

Zitat von: Otto123 am 27 August 2021, 23:11:32
Hi,

der MQTT2 Server spielt keine Rolle, die Verbindung macht ja der MQTT2_Client :)

Ich weiß nicht was mit kontaktieren gemeint ist, der Verbindungsaufbau wird ja im LogFile geloggt. Bei mir ist das ca. einer am Tag. Ansonsten dürften ja die meisten MQTT Nachrichten vom Mäher kommen.

Gruß Otto

Da ich immer noch Probleme habe und Worx behauptet, dass mein Fhem ca. 150 Anfragen am Tag sendet, habe ich einmal den Client abgeschaltet.

Kaum abgeschaltet, kommt die Meldung vom Boardercut wieder über die App rein. :o

Nun habe ich den MQTT_Client auf Verbose 5 gesetzt.
Im Log steht nun alle 10 Min  folgendes:
2021.09.20 12:20:02 5: MQTT2_Worx: sending PINGREQ (192)(0)
2021.09.20 12:20:02 5: MQTT2_Worx: received PINGRESP


Das wären 144 Anfragen + die Zwangstrennung von Provider.

Also sendet der Client doch Anfragen an den Server!? Ist das nötig?

Grüße Bernd
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...

rudolfkoenig

ZitatAlso sendet der Client doch Anfragen an den Server!? Ist das nötig?
Vermutlich nicht, und es ist vermutlich ein Fehler im Client (oder doch Server?), aber bisher hat keiner es geschafft, mir was Nachstellbares zu liefern.

frober

Zitat von: rudolfkoenig am 20 September 2021, 12:59:54
Vermutlich nicht, und es ist vermutlich ein Fehler im Client (oder doch Server?), aber bisher hat keiner es geschafft, mir was Nachstellbares zu liefern.

Hallo Rudi,
wie kann ich dir da weiterhelfen?
Die Definition ist so wie von Otto angegeben.
Bringt dir stacktrace etwas?
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...

rudolfkoenig

wie kann ich dir da weiterhelfen?
Am besten waere etwas, was ich selbst aufrufen kann. Wenn ich mich nicht irre, braucht der Zugang private Schluessel.
Wenn das keine Option ist, dann ein Log mit "attr MQTT2_CLIENT verbose 5". Bin aber unsicher, ob das reicht.

frober

#324
Zitat von: rudolfkoenig am 20 September 2021, 13:27:30
wie kann ich dir da weiterhelfen?
Am besten waere etwas, was ich selbst aufrufen kann. Wenn ich mich nicht irre, braucht der Zugang private Schluessel.
Wenn das keine Option ist, dann ein Log mit "attr MQTT2_CLIENT verbose 5". Bin aber unsicher, ob das reicht.

Ich glaube, ich habe das "Problem" gefunden...
attr MQTT2_Worx keepaliveTimeout 600

Ich setze den Intervall mal hoch und beobachte.

Den Link zum Log mit Verbose 5 habe ich dir per PM Mail gesendet, da auch hier die Ser.-Nr. etc. enthalten ist.
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...

Otto123

Zitat von: frober am 20 September 2021, 12:42:17
Da ich immer noch Probleme habe und Worx behauptet, dass mein Fhem ca. 150 Anfragen am Tag sendet, habe ich einmal den Client abgeschaltet.

Kaum abgeschaltet, kommt die Meldung vom Boardercut wieder über die App rein. :
wie kann man diese Anfragen sehen?
Eine Sperre dauert doch 24h - was verstehst du unter "kaum"?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frober

Zitat von: Otto123 am 20 September 2021, 20:02:08
wie kann man diese Anfragen sehen?
Eine Sperre dauert doch 24h - was verstehst du unter "kaum"?
Verbose 5 im Client...

Bzgl. Sperre behauptet Worx, dass man dies nicht mitbekommt, sie aber sehen, dass ich hin und wieder gesperrt werde, da ich die 150 Anfragen/Tag überschreite und das kann nur eine Fremdsoftware. IOBroker hatte ich nie installiert.
Bei mir waren jedoch durchweg die Daten vorhanden, nur die gemähte Zone ist zw. Fhem und App asynchron und das Boardercut wird nicht mehr gemeldet.

Ich habe Sonntags den Client disabled und Montags kam wieder die Bordercut-Meldung in der App. Aktuell ist der Client aktiviert und die Meldung kommt wieder nicht mehr.

Ich verstehe das auch noch nicht, bekomme aber durch die "Fremdsoftware" keinen Support mehr. Erst wenn ich diese abschalte, dann besteht aber das Problem nicht mehr.
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...

rudolfkoenig

ZitatDen Link zum Log mit Verbose 5 habe ich dir per PM Mail gesendet, da auch hier die Ser.-Nr. etc. enthalten ist.
Ich finde im Log kein Problem.

Da sind zwar 1059 empfangene Nachrichten (PUBLISH und PINGRESP) und 553 gesendete (PINGREQ), aber das innerhalb von 4 Tagen (genauer 90 Stunden), d.h. das sind 12 empfangen bzw. 6 gesendete Nachrichten pro Stunde. Das ist nicht die Endlosschleife, woran ich gedacht habe, und der Server sollte sich nicht anstellen.

frober

#328
Zitat von: rudolfkoenig am 21 September 2021, 11:34:37
Ich finde im Log kein Problem.

Da sind zwar 1059 empfangene Nachrichten (PUBLISH und PINGRESP) und 553 gesendete (PINGREQ), aber das innerhalb von 4 Tagen (genauer 90 Stunden), d.h. das sind 12 empfangen bzw. 6 gesendete Nachrichten pro Stunde. Das ist nicht die Endlosschleife, woran ich gedacht habe, und der Server sollte sich nicht anstellen.

Danke für die RM, der Server sperrt den Zugang bei mehr als 150 Anfragen/Tag für 24h (laut Worx).

Dieser ist anscheinend auch zickig, bei einem keepaliveTimeout von 1800 quittiert es jeden 2. Ping (alle 60 Min) mit einem disconnect. Der Client verbindet sich danach gleich wieder.
Mit einem keepaliveTimeout von 1200 ist alles noch ok.

Testweise habe ich den keepaliveTimeout aktuell abgeschaltet. Muss nun ein paar Tage abwarten um zu sehen wie sich alles verhält.
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...

frober

Ohne keepaliveTimeout gibt es alle 30 Min einen disconnect. ::)
Also wieder mit 1200 aktiviert..
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...