Der neue Monatsrückblick für Mai und Juni 2026 ist online!

[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]

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

[stolly82]

@Dia-dro

Habe nur keine neue Versionsnummer gegeben, ist aber neu ;-)

[Dia-dro]

@stolly82

Mit der aktualisierten Version zeigt sich ein sonderbares Verhalten:

IMG_1805.mov

Dieser Vorgang wiederholt sich einige male...

[eLichte]

Meine Erfahrungen mit dem neuen Adapter:

Ich habe ioBroker in Docker auf Unraid laufen. Mithilfe der KI (ich selbst wäre niemals darauf gekommen) habe ich es geschafft, Python 3.13 in einen persistenten Pfad (unter appdata) im Container zu kompilieren.

Im Mammotion-Adapter habe ich diesen Pfad eingetragen. Das funktioniert, auch nach einem Container-Update.

Mein Yuka Mini 2025 wird erkannt, Zeitpläne und Zonen werden geladen. Allerdings starte ich den Yuka nicht über diese Zonen.

Zum Verwalten meiner zwei Rasenflächen hatte ich schon von Anfang an (also bereits vor ioBroker) zwei Zeitpläne mit allen Einstellungen für die jeweilige Fläche in der App angelegt. Den Autostart hatte ich jedoch deaktiviert, weil ich lieber manuell starte. Die Zeitpläne konnten in der App jederzeit auch manuell gestartet werden.

Erfreulicherweise werden die beiden Zeitpläne jetzt auch in ioBroker erkannt, jeweils mit einem "start" Datenpunkt. Das funktioniert bei mir bisher problemlos.

[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.