MQTT2 für Worx Landroid Mähroboter

[remo]

Danke für deine Antwort.
Also 24h abwarten und hoffen, dass es dann erledigt ist?
Oder kann man noch irgendwie weitere Informationen erhalten?
Logs usw ...

[Otto123]

so ist es warten ...
Ich würde den MQTT_Worx deaktivieren, der schreibt das Log voll...

[remo]

Hab ich vorausschauender Weise getan.
Danke, ich melde mich.

Schönen Abend.

[remo]

Die Sperre wurde soeben aufgehoben.
Die iOS-App läuft (lief) wieder.
Ich habe in FHEM wieder alles eingestellt wie vorher.
Account ist nun wieder gesperrt und die App funktioniert wieder nicht.
Für 5 Minuten lief die App. FHEM hat nicht einmal Readings aktualisiert.

Was kann das sein?

Ich habe die in FHEM eingestellten attr-Werte mit denen aus der Windows Software verglichen.
Passt aber alles ...



EDIT:

Der MQTT2_Client in FHEM springt immer von opened auf disconnected - immer hin und her. 

[Otto123]

Hallo remo,

aber es lief doch schon mal? Ich meine das fehlerhafte Verhalten tritt in zwei Fällen auf:
Die Zertifikate stimmen nicht - ich habe im ersten Beitrag noch etwas ergänzt kannst Du das bitte nochmal prüfen.
Die clientId wird doppelt verwendet oder hat das falsche Format, sie muss so aussehen android-5edf7268-f33f-520c-6e65-44b2afc7008e

Aber gerade stelle ich fest, ich bin auch rausgeflogen - gestern 2021.06.28 11:55:13 - ohne etwas getan zu haben? 
Mist - jetzt bin ich erstmal ratlos
Doch ich habe was getan: ich habe gestern eine Testinstanz neu gestartet, in der gab es eine temporär ruhig gestellte, gleiche definition 

Gruß Otto

[remo]

Es ist nichts anders, außer, dass der NodeJS-Server (Debian) weg ist.
Zertifikat habe ich inzwischen neu geladen und die Schlüssel exportiert.
Es sind aber die selben.

Das ist interessant.

Mal eine andere Frage:
Spielt die Reihenfolge der attr des MQTT-Clients eine Rolle?
Denn mein FHEM hat diese irgendwie ,,umsortiert" - die Reihenfolge stimmt jetzt nicht mehr mit der aus deinem define (erster Post) überein...

EDIT:
ID sieht so aus wie sie aussehen muss.
Syntax stimmt. Meine ID ist natürlich eine andere.

[Otto123]

Es ist nichts anders, außer, dass der NodeJS-Server (Debian) weg ist.

Das macht mich irgendwie stutzig. Damit sollte die Fehlerquelle ja kleiner und nicht größer werden.

Mir scheint es so, als hast Du nicht alles deaktiviert und ein Prozess rennt noch?

[remo]

Das ist ausgeschlossen. Hatte gestern Abend noch Luft und hab meinen Deb neu aufgesetzt. Nix drauf. Nur FHEM.
Was ist mit der Reihenfolge der attr ?

[Otto123]

Die Reihenfolge brauchst Du nach der Anlage mMn nicht beachten - also ich mach das nie. Man gibt die Zeilen ein und FHEM sortiert die irgendwie zum Gerät in der cfg. Schau ich nie hin

[remo]

Gut. Ok. Also wieder abwarten 

[frober]

Kann mir jemand weiterhelfen, ich wollte mir die aktive Mähzone in ein Reading schreiben.

Irgendwie stehe ich auf dem Schlauch und finde meinen Fehler nicht.

Als Erweiterung des userreadings, getrennt mit einem Komma ans Ende angehängt:

Code Auswählen Erweitern

mowerActiveZone:dat_lz.* {my $evt = ReadingsVal($name,"dat_lz","0"); my $evt1 = 'cfg_mzv_'.$evt; ReadingsVal($name,$evt1,"0")}

Danke und Grüße
Bernd

[remo]

Wie ist das mit der uuid generell zu verstehen?
Ist das eine Session ID oder die eineindeutige ID für mein Gerät?
Denn die DeskApp zeigt nicht immer die selbe ID an...

[Otto123]

@ Bernd Ich habe es nicht ganz verstanden, aber bei mir steht in dat_lz eine 0 und die cfg_mzv_ laufen von 1-10 - das kann so nicht funktionieren. Eventuell mit $evt + 1 ?

@remo Die clientId ist eine eindeutige ID für die Anmeldung am mqtt Cloud Server - bei mir hat die DeskApp beim ersten Start eine festgelegt und die bleibt. Allerdings denke ich, sie verwendet diese nicht so wie sie zeigt! Die mehrfache Anmeldung mit gleicher ID führt zur Sperre.

[frober]

@ Bernd Ich habe es nicht ganz verstanden, aber bei mir steht in dat_lz eine 0 und die cfg_mzv_ laufen von 1-10 - das kann so nicht funktionieren. Eventuell mit $evt + 1 ?

Hallo Otto,

da hast du Recht, habe ich übersehen, allerdings habe ich aktuell eine 9. Sollte also funktionieren, allerdings mit dem falschen Ergebnis.
Edit: muss morgen schauen, ob er auf 10 oder 0 springt.

Getestet habe ich bisher nur mit trigger und setreading.

Zur Erklärung, falls nicht bekannt:
cfg_mzv_1 (-10) ist die gesamte Mähzeit (100%) in 10% Schritten. Das Value 0-3 entspricht der Zone 1-4.
D.h. bei 30% in Zone 2 steht bei 3 dieser Readings eine 1. Die anderen sind 0 für Zone 1.
dat_lz gibt an welche 10% der Gesamtzeit gerade oder beim nächsten Mähvorgang gemäht werden.
D.h. bei mir ist dat_lz aktuell 9, beim nächsten Start wird der Teil 81-90% der Gesamtmähzeit gemäht in der Zone die unter cfg_mzv_9 steht.

Sofern er nicht wieder aus der Zone flüchtet  ...muss noch etwas nachbessern.

[Otto123]

ach so und ich glaube der trigger muss so aussehen mowerActiveZone:dat_lz:.*