[TEST] Mammotion – Adapter für Mammotion Luba / Yuka

Norb 0

Hier der log dazu:

468bc354-067a-4181-9bf6-32a249a49d92-log.txt

stolly82

@norb-0

Fixed!

War bei mir auch so, geht wieder!

Norb 0

perfekt, geht

Dia-dro

@Thomas-Braun sagte:

Bringt die Kisten doch bitte beizeiten auf einen aktuellen Stand...

Gesagt, getan. Der neue RPi wurde heute in Betrieb genommen.
Mit unserem Luba mini 2 awd 1500 Lidar scheint es auf den ersten Blick zu funktionieren.

Evtl. erste Fragen:

Unter "mammotion-pymammotion.0.devices.Luba-xxxxxx.zones.config.pathOrder" sollte doch mit "0" definiert werden können, dass zuerst der Rand gemäht werden soll. Bei mir mäht er zuerst den Innenbereich und erst danach die Ränder - egal, ob Wert 0 oder 1 gesetzt ist. Gesetzt habe ich den Wert über "mammotion-pymammotion.0.devices.Luba-xxxxxx.zones.startPayload". Müssen hier weitere Parameter mitgesendet werden?

{
  "areas": [
    "16708554255351643138"
  ],
  "startImmediately": true,
  "bladeHeight": 35,
  "pathSpacing": 11,
  "pathOrder": 0,
  "cuttingPathMode": 0,
  "obstacleDetectionMode": 0,
  "cuttingPathAngle": 0,
  "cuttingPathAngleMode": 0,
  "crossingAngle": 0,
  "boundaryLaps": 2,
  "noGoZoneLaps": 0,
  "perimeterLaps": 2,
  "startProgress": 0,
  "collectGrassFrequency": 0
}

Ich nehme nicht an, dass es möglich ist, (wie in der App) darzustellen, wo sich der Mäher befindet und welchen Teil er bereits gemäht hat, oder?
Bei mir stimmen die Flächenwerte vom IOBroker zur App nicht überein. Die App zeigt stets einen höheren Wert als "Luba-xxxxx.zones.zone_xxxxxxxx.info.areaM2". Ist das bei euch auch so?

Edit:

Weiter ist mir aufgefallen, dass die verschiedenen Mähzonen in den Objekten aktuell 3x mit unterschiedlicher Nummer aufgelistet werden. Ändert sich der Hash-Name nach einer gewissen Zeit?

stolly82

@Dia-dro

Danke fürs Testen.

Zu pathOrder:
Das sollte eigentlich genau dafür da sein. Nach aktuellem Stand sieht es aber so aus, als ob das im Adapter bzw. in PyMammotion noch nicht sauber so ankommt, wie es die App macht. Zusätzliche Parameter solltest du dafür eigentlich nicht brauchen. Das schaue ich mir noch mal an.

Karte / aktuelle Mähposition / bereits gemähte Fläche:
So wie in der App wird das im ioBroker-Adapter eher nicht gehen. Dafür müsste man eine echte Karten-/View-Logik bauen. Der Adapter liefert aktuell die Daten/States, aber keine grafische Live-Karte.

Flächenwerte:
Die können abweichen. Im Adapter kommen die Werte aktuell aus den Zonendaten bzw. der berechneten Geometrie. Die App zeigt da offenbar etwas anders bzw. genauer/anders gerundet an. Das ist also eher kein Einzelfall.

Zonen / Hash-Namen:
Die Hashes selbst sollten sich nicht ständig ändern. Was sich aber ändern kann, ist die Zuordnung bzw. der Fallback-Name, wenn Mammotion/PyMammotion keine sauberen Zonennamen liefert. Gerade beim Luba 1 ist das leider unschön, weil die App intern zwar „Bereich 1, 2, 3 …“ zeigt, das aber nicht 1:1 sauber in den Daten hängt.

Ich habe in den neueren Versionen schon zusätzliche Zonen-Metadaten eingebaut, damit man die Bereiche wenigstens besser über Fläche / Position / Reihenfolge zuordnen kann.

Dia-dro

@stolly82

Danke für deine ausführliche Rückmeldung!

Ich werde versuchen, dies in unsere Visualisierung zu integrieren und parallel den Adapter weiter-testen. Falls mir noch etwas auffällt, werde ich mich erneut melden.

stolly82

Hey,

testet irgendwer?

SchlaMatt

Ich kann leider nicht testen, da ich den Adapter nicht zum laufen bringe.
Iobroker läuft bei mir unter Docker auf der NAS
Bekomme die Fehlermeldung: Python bootstrap failed: Python 3.13+ not found. Configure pythonExecutable or install python3.13.

Plattform: docker (official image - v11.1.0)
Betriebssystem: linux
Architektur: x64
CPUs: 2
Geschwindigkeit: 2396 MHz
Modell: Intel(R) Celeron(R) CPU J3355 @ 2.00GHz
RAM: 15.4 GB
Node.js: v22.23.1

LG Matt

Thomas Braun

@SchlaMatt sagte:

Python 3.13+ not found. Configure pythonExecutable or install python3.13.

Die Meldung ist eigentlich eindeutig. Du musst ein aktuelleres python verfügbar machen.

SchlaMatt

@Thomas-Braun
Hätte ich versucht, bekomme aber immer die Meldung

python3 is already the newest version (3.11.2-1+b1).
python3-distutils is already the newest version (3.11.2-3).

Thomas Braun

@SchlaMatt

Im Container...
Ob und wie man da was aktuelleres reinbekommt weiß ich nicht, verwende die Dinger nicht.

stolly82

@schlamatt

Da entweder ein custom docker draus bauen mit 3.13 oder warten bis das offizielle image 3.13 enthält.

Die Python 3.13 ist leider eine Anforderung vom PyMammotion, ich kann das aus dem Grund nicht ändern.

Hier kommen wir zu den Nachteilen, wenn man eine Abhängigkeit wie PyMammotion nutzt und man dann noch mit fertigen Docker images arbeitet statt z.B. einen Proxmox container zu nutzen.

SchlaMatt

@stolly82
Ich bin gerade dabei, zu testen, wie ich Python 3.13 am besten in den Container bekomme.
Die ersten Versuche waren nicht von Erfolg gekrönt, aber ich werde weiterprobieren.

Dia-dro

@stolly82 sagte:

Zonen / Hash-Namen:
Die Hashes selbst sollten sich nicht ständig ändern. Was sich aber ändern kann, ist die Zuordnung bzw. der Fallback-Name, wenn Mammotion/PyMammotion keine sauberen Zonennamen liefert. Gerade beim Luba 1 ist das leider unschön, weil die App intern zwar „Bereich 1, 2, 3 …“ zeigt, das aber nicht 1:1 sauber in den Daten hängt.

@stolly82

Sorry für die späte Rückmeldung. Leider ist die letzten Tage etwas dazwischen gekommen und ich konnte nicht weiter testen. Als ich mich heute dem Projekt erneut widmen wollte, musste ich feststellen, dass über 100 neue Zonen-Einträge bei den Objekten aufgelistet werden. Der Luba Mini 2 wurden jedoch die letzten Tage nur über die Mammotion eigene App gestartet.

Verstehe ich es richtig, dann kann hier nichts "optimiert" werden?

stolly82

@Dia-dro

Hast du denn die aktuelle Version drauf freigegeben 2 weeks ago ?

Die Zonen hatte ich eigentlich so, dass die nicht automatisch abgerufen werden.

Die werden ausschließlich über mammotion-pymammotion.0.devices.Luba-XX.zones.syncMap abgerufen, somit sollten die "100" Zonen von selbst nicht möglich sein.

Ich habe hier einen Adapter mit Luba 1 und Luba 2 laufen, hatte eben mal zum testen die Zonen neu gezogen, auch da habe ich nur meine 10 Areas die ich auch vorher hatte.

Dia-dro

@stolly82 sagte:

Hast du denn die aktuelle Version drauf freigegeben 2 weeks ago ?

Eigentlich schon -> v0.1.5.

Was mich auch noch irritiert:
Belade ich das nachfolgende Objekt mit dem nachfolgenden Inhalt, dann werden beim Betätigen vom Objekt "StartSelected" trotzdem mehrere Bereiche gemäht, obwohl im Payload eigentlich nur ein Bereich eingetragen war:

Ich gebe also im Objekt:

mammotion-pymammotion.0.devices.Luba-LABKL4PM.zones.startPayload

folgendes ein:

{
  "areas": [
    "1408453725693220568"
  ],
  "startImmediately": true,
  "bladeHeight": 35,
  "pathSpacing": 11,
  "pathOrder": 0,
  "cuttingPathMode": 0,
  "obstacleDetectionMode": 0,
  "cuttingPathAngle": 0,
  "cuttingPathAngleMode": 0,
  "crossingAngle": 0,
  "boundaryLaps": 2,
  "noGoZoneLaps": 0,
  "perimeterLaps": 2,
  "startProgress": 0,
  "collectGrassFrequency": 0
}

und aktiviere die ganze Sache mit:

mammotion-pymammotion.0.devices.Luba-LABKL4PM.zones.startSelected

Dann startet der Mäher, aber je nach dem, welche anderen Zonen über:

mammotion-pymammotion.0.devices.Luba-LABKL4PM.zones.zone_79817091525556033965.config.start

noch ausgewählt sind, auch die anderen Zonen ab.

Oder wie kann ich nach dem Füllen von "startPayload" nur den gewünschten Bereich mähen lassen? Ist hier nicht "StartSelected" das korrekte Objekt, zum Ausführen vom "startPayload"?

stolly82

Danke für die Rückmeldung, das ist so nicht gewollt.

Die >100 zusätzlichen Zonen-Objekte sollten eigentlich nicht entstehen. syncMap wird nicht automatisch dauernd ausgeführt. Der aktuelle Stand im Adapter ist aber so, dass nicht nur die echten Map-Areas, sondern zusätzlich auch Hashes aus dem aktuellen Work-/Status-Kontext mit in die Zonenliste übernommen werden. Wenn Mammotion/PyMammotion dort temporär andere Hashes meldet, landen die aktuell leider als zone_*-Objekte in ioBroker und werden bisher auch nicht automatisch wieder aufgeräumt.

Ich werde das so anpassen, dass nur noch echte Map-/Area-Hashes dauerhaft als Zonenobjekte angelegt werden bzw. dass fremde/stale Hashes nicht mehr alles zumüllen.

Zum zweiten Punkt mit startPayload:
Ja, startSelected ist grundsätzlich das richtige Objekt zum Starten. Aktuell ist es aber so, dass bei startSelected die bereits ausgewählten Zonen aus selectedAreas / zone_xxx.config.selected Vorrang haben. Das heißt: Wenn dort noch andere Bereiche ausgewählt sind, werden diese aktuell mit berücksichtigt – auch wenn im startPayload nur eine Area steht.

Heißt konkret:

startPayload alleine überschreibt die bestehende Auswahl bei startSelected aktuell nicht hart
Wenn du exakt eine Area aus dem Payload starten willst, müssen die anderen selektierten Zonen raus
Alternativ den direkten Start der einzelnen Zone über zone_<hash>.config.start nutzen

Das ist also eher aktuelles Verhalten / Bug als beabsichtigte Endlogik. Ich passe das noch an, damit startPayload.areas bei startSelected sauber und eindeutig verwendet wird.

Dia-dro

Ich denke, dann freue ich mich auf die nächste Version von dir... :-)
Danke nochmals für deine Bemühungen!

stolly82

@Dia-dro Sollte schon online sein :)

Dia-dro

Screenshot_2026-07-16 18.53.05_rgln1A.png

Hilf mir doch bitte kurz weiter. Hat sich der Link (https://github.com/DNAngelX/ioBroker.mammotion-pymammotion) geändert? Ich sehe nach wie vor nur v0.1.5

Community Forum

NEWS

[TEST] Mammotion – Adapter für Mammotion Luba / Yuka

Fixed!

Support us

358

33.0k

83.5k

1.3m