Monatsrückblick Juli / August 2026 ist online!

[Meister Mopper]

@eLichte

Wo ist der Vorteil? Kann der ioBroker mehr als die App? Warum gehst du diesen Weg? Bring bitte Licht ins Dunkle.1

[eLichte]

@Meister-Mopper Die Frage verstehe ich nicht.
So könnte man jede Intergration in Iobroker hinterfragen. Schließlich kann man alles klassich bedienen.

Was ich mir vorstelle:

• Mähzyklus abhängig von Hitze, Trockenheit
• Gar nicht rausfahren wenns regnet
• etc
• etc
  ....

[stolly82]

@Dia-dro Ich habe hier noch mal die Abfrage korrigiert! Sollte behoben sein.

[Dia-dro]

@stolly82

Im Prinzip sieht es relativ gut aus. Nur eine Zone hat es doppelt erstellt, die hartnäckig bleibt. Teilweise werden auch andere doppelt aufgelistet, aber sobald ich den Browser aktualisiere, sind diese wieder weg. Muss dazu jedoch sagen, dass ich grad wieder knapp Zeit hatte und der längere Test noch ausblieb. Leider sieht es die nächsten Tage auch nicht "rosig" aus, aber ich werde sobald als möglich weiter testen!

So wie es scheint, funktioniert nun auch das "StartSelected", welches nun nur noch diejenigen Zonen mäht, welche auch im Payload erwähnt sind. Ich denke: gute Arbeit!

[stolly82]

@Dia-dro Hey, vielen Dank!

Zu den "doppelten Zonen", kann das ein IoBroker View issue sein?

Denn doppelte Objekt- IDs gibt es ja nicht und die sollten eigentlich standardisiert angelegt werden.

[ADB-83]

Hallo stolly82.

Die Auslands-Ferien für dieses Jahr sind durch und ich konnte nun endlich noch etwas weitertesten.

Gestern war unter den Objekten eigentlich nur der Süd-Bereich doppelt aufgelistet. Heute sind zusätzlich der "Nord-" sowie "West-Bereich" hinzugekommen. Die restlichen drei Bereiche sind aktuell nur einmal aufgeführt. Dieses Mal bleiben die doppelten Bereich auch nach dem Aktualisieren des Browser-Fenster erhalten. Auch wenn ich die Objekt-Seite vom IOBroker in einem anderen Mac öffne, werden diese alle angezeigt.
Etwas ist mir noch aufgefallen: Gestern habe ich zu Testzwecke den Nord-Bereich (über das Payload-Objekt) mähen lassen. Als ich dies heute wiederholen wollte, fiel mir auf, dass die ID, die ich gestern im Payload-Objekt eingetragen hatte, gar nicht mehr unter den Objekten auffindbar war. Es sieht quasi so aus, als würde die ID doch ändern. Ich muss dazu sagen, dass ich wegen dem lauten "Ge-Piepe" vor dem Start des Drehtellers den Robi neu gestartet habe. Vielleicht ist es auch purer Zufall...? Um auf Nummer sicher zu gehen, müsste ich dies die nächsten Tage weitertesten...

Bin ich demnach der Einzige mit diesem Verhalten? Liegt es evtl. am neuen Luba Mini 2 AWD 1500 mit Lidar?

Noch eine weitere Frage: Betreffend der Reihenfolge (pathOrder -> 0 = Erst Rand, dann Fläche / 1 = Erst Fläche). Hast du hierfür evtl. schon eine Lösung oder ist dessen Korrektur zu komplex?

[ADB-83]

ADB-83 sagte:

Es sieht quasi so aus, als würde die ID doch ändern. Ich muss dazu sagen, dass ich wegen dem lauten "Ge-Piepe" vor dem Start des Drehtellers den Robi neu gestartet habe. Vielleicht ist es auch purer Zufall...? Um auf Nummer sicher zu gehen, müsste ich dies die nächsten Tage weitertesten...

Nachtrag:
Als Versuch entfernte ich gerade eben den Objektbaum der Zonen und habe den Adapter neu gestartet und ein ReSync der Maps durchführen lassen. Die Hash-Bezeichnungen der Zonen hatten sich dadurch wieder geändert.

[Gustav Winkler]

Ich habe folgendes Problem:
nach dem Start des Adapters kommt eine Fehlermeldung als error.

Python bootstrap failed: Field "data" of type Optional[ShareNoticeData] in ShareNoticeListResponse has invalid value {'total': 4, 'data': [{'gmtModified': 1774883263000, 'targetId': 'sI4QwtmabGwwgx9NbAnV000000', 'receiverIdentityId': '50f4op5a571b7fad2945b5ead0017df9bb1c1203', 'description': 'You have accepted the sharing with null', 'targetType': 'DEVICE', 'gmtCreate': 1774882588000, 'batchId': 'ACCOUNT_DEV_SHARE_422036e4-371b-4d48-af20-a15721105514', 'nodeType': 'DEVICE', 'deviceName': 'Yuka-VPW82YH2', 'productName': 'YukaPlus', 'recordId': '40e0cc5a01df4d02a7b7bbc39928c289', 'initiatorIdentityId': '50a2op8ee7fb7af0b71e739a41c0ae5ce8db6442', 'isReceiver': 1, 'initiatorAlias': 'null', 'receiverAlias': 'null', 'status': 0}, {'gmtModified': 1774882542000, 'targetId': 'sI4QwtmabGwwgx9NbAnV000000', 'receiverIdentityId': '50f4op5a571b7fad2945b5ead0017df9bb1c1203', 'description': 'null has canceled the sharing with you', 'targetType': 'DEVICE', 'gmtCreate': 1774882188000, 'batchId': 'ACCOUNT_DEV_SHARE_7054e29f-b835-4bea-be59-7ea5d783a676', 'nodeType': 'DEVICE', 'deviceName': 'Yuka-VPW82YH2', 'productName': 'YukaPlus', 'recordId': '3671d0d0cb2140dca0a268a4a9883db1', 'initiatorIdentityId': '50a2op8ee7fb7af0b71e739a41c0ae5ce8db6442', 'isReceiver': 1, 'initiatorAlias': 'null', 'receiverAlias': 'null', 'status': 2}, {'gmtModified': 1774866125000, 'targetId': 'ELy20z0JXOnxLG38DeYd000000', 'categoryImage': 'https://ai-genie-center.oss-cn-hangzhou.aliyuncs.com/app-data/iot-center/static_category/Tracker/定位终端备份.png', 'receiverIdentityId': '50f4op5a571b7fad2945b5ead0017df9bb1c1203', 'description': 'You have accepted the sharing with null', 'targetType': 'DEVICE', 'gmtCreate': 1774866020000, 'batchId': 'ACCOUNT_DEV_SHARE_998c2bc5-d4c3-4cf5-ba43-3cd5eb43e861', 'nodeType': 'DEVICE', 'deviceName': 'RBSA2789H4T', 'productName': 'RBS03', 'recordId': 'ee6f22dfc3de473ea3cf61e30f31bb62', 'productImage': 'https://ai-genie-center.oss-cn-hangzhou.aliyuncs.com/app-data/iot-center/static_category/Tracker/定位终端备份.png', 'initiatorIdentityId': '50a2op8ee7fb7af0b71e739a41c0ae5ce8db6442', 'isReceiver': 1, 'initiatorAlias': 'null', 'receiverAlias': 'null', 'status': 0}, {'gmtModified': 1774866100000, 'targetId': 'sI4QwtmabGwwgx9NbAnV000000', 'receiverIdentityId': '50f4op5a571b7fad2945b5ead0017df9bb1c1203', 'targetType': 'DEVICE', 'gmtCreate': 1774866020000, 'batchId': 'ACCOUNT_DEV_SHARE_998c2bc5-d4c3-4cf5-ba43-3cd5eb43e861', 'nodeType': 'DEVICE', 'deviceName': 'Yuka-VPW82YH2', 'productName': 'YukaPlus', 'recordId': '348a9fed45134e76b6bf696f7803b506', 'initiatorIdentityId': '50a2op8ee7fb7af0b71e739a41c0ae5ce8db6442', 'isReceiver': 1, 'initiatorAlias': 'null', 'receiverAlias': 'null', 'status': 6}], 'pageNo': 1, 'pageSize': 100}

danach folgendes als warnung:

	[sidecar-error] Field "data" of type Optional[ShareNoticeData] in ShareNoticeListResponse has invalid value {'total': 4, 'data': [{'gmtModified': 1774883263000, 'targetId': 'sI4QwtmabGwwgx9NbAnV000000', 'receiverIdentityId': '50f4op5a571b7fad2945b5ead0017df9bb1c1203', 'description': 'You have accepted the sharing with null', 'targetType': 'DEVICE', 'gmtCreate': 1774882588000, 'batchId': 'ACCOUNT_DEV_SHARE_422036e4-371b-4d48-af20-a15721105514', 'nodeType': 'DEVICE', 'deviceName': 'Yuka-VPW82YH2', 'productName': 'YukaPlus', 'recordId': '40e0cc5a01df4d02a7b7bbc39928c289', 'initiatorIdentityId': '50a2op8ee7fb7af0b71e739a41c0ae5ce8db6442', 'isReceiver': 1, 'initiatorAlias': 'null', 'receiverAlias': 'null', 'status': 0}, {'gmtModified': 1774882542000, 'targetId': 'sI4QwtmabGwwgx9NbAnV000000', 'receiverIdentityId': '50f4op5a571b7fad2945b5ead0017df9bb1c1203', 'description': 'null has canceled the sharing with you', 'targetType': 'DEVICE', 'gmtCreate': 1774882188000, 'batchId': 'ACCOUNT_DEV_SHARE_7054e29f-b835-4bea-be59-7ea5d783a676', 'nodeType': 'DEVICE', 'deviceName': 'Yuka-VPW82YH2', 'productName': 'YukaPlus', 'recordId': '3671d0d0cb2140dca0a268a4a9883db1', 'initiatorIdentityId': '50a2op8ee7fb7af0b71e739a41c0ae5ce8db6442', 'isReceiver': 1, 'initiatorAlias': 'null', 'receiverAlias': 'null', 'status': 2}, {'gmtModified': 1774866125000, 'targetId': 'ELy20z0JXOnxLG38DeYd000000', 'categoryImage': 'https://ai-genie-center.oss-cn-hangzhou.aliyuncs.com/app-data/iot-center/static_category/Tracker/定位终端备份.png', 'receiverIdentityId': '50f4op5a571b7fad2945b5ead0017df9bb1c1203', 'description': 'You have accepted the sharing with null', 'targetType': 'DEVICE', 'gmtCreate': 1774866020000, 'batchId': 'ACCOUNT_DEV_SHARE_998c2bc5-d4c3-4cf5-ba43-3cd5eb43e861', 'nodeType': 'DEVICE', 'deviceName': 'RBSA2789H4T', 'productName': 'RBS03', 'recordId': 'ee6f22dfc3de473ea3cf61e30f31bb62', 'productImage': 'https://ai-genie-center.oss-cn-hangzhou.aliyuncs.com/app-data/iot-center/static_category/Tracker/定位终端备份.png', 'initiatorIdentityId': '50a2op8ee7fb7af0b71e739a41c0ae5ce8db6442', 'isReceiver': 1, 'initiatorAlias': 'null', 'receiverAlias': 'null', 'status': 0}, {'gmtModified': 1774866100000, 'targetId': 'sI4QwtmabGwwgx9NbAnV000000', 'receiverIdentityId': '50f4op5a571b7fad2945b5ead0017df9bb1c1203', 'targetType': 'DEVICE', 'gmtCreate': 1774866020000, 'batchId': 'ACCOUNT_DEV_SHARE_998c2bc5-d4c3-4cf5-ba43-3cd5eb43e861', 'nodeType': 'DEVICE', 'deviceName': 'Yuka-VPW82YH2', 'productName': 'YukaPlus', 'recordId': '348a9fed45134e76b6bf696f7803b506', 'initiatorIdentityId': '50a2op8ee7fb7af0b71e739a41c0ae5ce8db6442', 'isReceiver': 1, 'initiatorAlias': 'null', 'receiverAlias': 'null', 'status': 6}], 'pageNo': 1, 'pageSize': 100}

leider habe ich garkeinen Plan davon.
Ich hoffe, irgendwer kann mir helfen.

[Henry 3]

Hallo stolly82,

erst einmal vielen Dank für den Adapter und die Arbeit daran.

Ich teste aktuell ioBroker.mammotion 0.0.7 mit einem Luba 2 AWD.

Dafür habe ich bewusst einen separaten zweiten Mammotion-Account eingerichtet. Der Luba wurde vom Hauptaccount an diesen Account freigegeben. Der zweite Account funktioniert in der Mammotion-App und hat Zugriff auf den Roboter.

Der Login im ioBroker-Adapter funktioniert ebenfalls und der Adapter findet den Luba korrekt als freigegebenes Gerät. Der zweite Account in der Android App ist dann abgemeldet

Leider bekomme ich aber keine eigentliche Telemetrie.

Die Datenpunkte

telemetry.batteryPercent
telemetry.deviceState

werden angelegt, bleiben jedoch ohne Wert.

Gleichzeitig steht

telemetry.connected = false

In der Adapterkonfiguration habe ich eingestellt:

legacyPollIntervalSec: 30
legacyTelemetryTransport: poll
storeDebugPayloads: false

Ich habe zusätzlich direkt das Instanzobjekt kontrolliert. Dort sind diese Einstellungen genauso gespeichert:

"legacyPollIntervalSec":30,
"legacyTelemetryTransport":"poll",
"storeDebugPayloads":false

Nach dem Start erscheint im Log allerdings:

Initialization successful: 1 device(s), telemetry via MQTT.
Aliyun IoT MQTT connected (Legacy/Shared).

Unmittelbar davor bzw. danach kommen mehrere Meldungen dieser Art:

MQTT subscribe failed (...): Connection closed

Anschließend erscheint ungefähr alle fünf Sekunden:

MQTT connected.

Es scheint durchaus Kommunikation stattzufinden. telemetry.lastUpdate wird aktualisiert und als letzter MQTT-Topic wurde beispielsweise

.../app/down/account/bind_reply

empfangen. Die eigentlichen Werte wie Akkustand oder deviceState kommen jedoch nicht an.

System:

ioBroker Mammotion: 0.0.7
Node.js: 22.23.2
js-controller: 7.2.2
Betriebssystem: Debian
Mäher: Luba 2 AWD
Mammotion-Zugang: freigegebener zweiter Account

Falls es bei der Fehlersuche hilft, kann ich gerne ein Debug-Log oder einen anonymisierten Export der Mammotion-Datenpunkte zur Verfügung stellen.

Viele Grüße
Henry

[Henry 3]

Hallo stolly82,

kurzes Feedback zu 0.0.8 mit einem freigegebenen/shared Luba:

• Gerät wird korrekt erkannt mit owned: 0.

• Der normale JWT-MQTT-Weg verbindet kurz, die Geräte-Subscriptions enden aber mit Connection closed und anschließendem Reconnect alle 5 Sekunden.

• HTTP-Polling liefert:

  • user device not bind
  • device is unbind

• Aliyun MQTT verbindet sich erfolgreich.

• Account-Binding klappt ebenfalls: code=200, message=success.

• Direkte Subscriptions auf die bekannten Luba-Topics werden vom Broker aber mit Subscribe error: Unspecified error abgelehnt.

Für mich sieht es so aus, als ob Shared-Geräte noch einen zusätzlichen Bind-/ACL-/Topic-Mechanismus benötigen.

Falls es hilft, kann ich gern weitere Tests oder Logs liefern.

Gruß aus dem Norden

[stolly82]

Sorry für die späte Rückmeldung, ich habe mir die gemeldeten Punkte jetzt noch einmal genauer angesehen.

@adb-83

Die mehrfach angelegten Zonen waren so natürlich nicht gewollt. Während eines Map-Syncs kamen zeitweise unvollständige Daten beziehungsweise zusätzliche interne Hashes zurück. Der Adapter hat diese teilweise bereits als echte Zonen übernommen und bestehende Objekte gleichzeitig zu früh gelöscht.

Das habe ich geändert:

• Zonen werden nur noch aus den tatsächlich vorhandenen Map-Areas erstellt.
• Während ein Map-Sync läuft, werden keine Zonen gelöscht.
• Alte Zonen werden erst nach einem vollständig abgeschlossenen Sync bereinigt.
• Temporäre Arbeits- oder Status-Hashes werden nicht mehr als neue Zonen angelegt.

Falls Mammotion nach einem Neustart oder einer Kartenänderung tatsächlich neue Hashes vergibt, wird nach dem nächsten vollständigen Sync die alte Zone entfernt und die neue angelegt. Die über 100 dauerhaft angesammelten Einträge sollten damit aber nicht mehr auftreten.

Bei pathOrder lag zusätzlich ein Fehler in meiner Zuordnung vor. Das war nicht die Reihenfolge der ausgewählten Areas, sondern sollte steuern, ob zuerst der Rand oder zuerst die Fläche gemäht wird.

Ich habe das deshalb eindeutiger aufgebaut:

mowOrder:
0 = zuerst Rand
1 = zuerst Fläche

perimeterLaps:
Anzahl der Runden am Rand der Mähfläche

noGoZoneLaps:
Anzahl der Runden um No-Go-Zonen

Die alten Bezeichnungen pathOrder und boundaryLaps werden zur Kompatibilität noch angenommen, sollten für neue Skripte aber nicht mehr verwendet werden.

@henry-3

Deine Logs stammen noch aus dem anderen ioBroker.mammotion-Adapter mit der eigenen MQTT-/Aliyun-Implementierung. Einstellungen wie legacyPollIntervalSec und legacyTelemetryTransport gibt es bei meinem neuen mammotion-pymammotion-Adapter nicht.

Genau wegen dieser Probleme habe ich den neuen Adapter gebaut: Die komplette Anmeldung sowie Mammotion-, MQTT- und Aliyun-Kommunikation übernimmt dort PyMammotion.

Ich habe PyMammotion jetzt auf Version 0.8.14 aktualisiert. Dort wurden auch weitere Dinge für freigegebene Geräte und die Erkennung der Account-Bindings angepasst.

Ich kann allerdings noch nicht garantieren, dass damit jedes Shared-Account-Modell funktioniert. Mammotion verwendet für freigegebene Geräte teilweise andere Berechtigungen und Topic-ACLs. Wenn du möchtest, kannst du die neue Version gerne mit deinem zweiten Account testen. Falls weiterhin keine Telemetrie kommt, wäre ein Debug-Log des mammotion-pymammotion-Adapters hilfreich.

Die Änderungen liegen jetzt als Version 0.1.6 auf GitHub.