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

[Norb 0]

LUBA 2 AWD 3000X + RTK:

• Installation des Adapters hat funktioniert (hatte schon vorher Python 3.13 drauf)
• nach Eingabe des Accounts und starten des Adapters, wurden der Luba + RTK erkannt und einiges in den Objektstrukturen abgelegt
• nach syncMap wurden auch relativ schnell die Zonen geladen

sieht bis dato sehr gut aus

Wenn sich der Rasen wieder von der Hitze erholt hat, teste ich mal die einzelnen Funktionen.

Erstmal vielen lieben Dank für Deine Bemühungen.

[Dia-dro]

@Thomas-Braun sagte:

Die Angabe der Versionsnummer im Paketnamen ist falsch.
Edit: Und das Paket 'python3-distutils' wird es vermutlich nicht mehr geben. Also nicht über entsprechende Meldungen wundern.

Die Installation von Python scheint immer noch nicht zu funktionieren.
Wenn ich die Sache richtig verstanden habe, liegt mein Problem daran, dass auf meinem Raspberry Pi 3 nur Debian 12 installiert und somit nur Python 3.11 verfügbar ist.
Da ich auf Grund vieler IOBroker-Abstürze den Raspberry Pi 3 durch einen Pi 5 mit 8GB ersetzen werde, warte ich auf die Lieferung des neuen Pis und werde die Installation direkt auf diesem installieren und mich sobald als möglich wieder zurück melden.

[Thomas Braun]

@Dia-dro

Richtig. Das aktuelle stable release (dann inkl. Python 3.13) ist Debian 13 'Trixie'.
Bringt die Kisten doch bitte beizeiten auf einen aktuellen Stand...

[Dia-dro]

@Thomas-Braun sagte:

Richtig. Das aktuelle stable release (dann inkl. Python 3.13) ist Debian 13 'Trixie'.
Bringt die Kisten doch bitte beizeiten auf einen aktuellen Stand...

Werde ich machen...

[stolly82]

@Norb-0

FRAGE

Luba 2 > Zonen
Wie sind die Namings bei dir? Hast du die Zonen benannt?

Der Luba 2 der mir freigegeben wurde ist leider seit gestern offline und ich konnte das nicht testen.

Luba 1 hat leider noch keine Namen für die Zonen (die heissen dann Bereich 1 - xx).

Daher nehme ich als Fallback die selbe Logik wie im HomeAssistent, also Area 1 - xx nach Reihenfolge, was leider nichts mit den "Bereich 1 - x" aus der App zu tun hat.

Ich habe in der neuen Version jetzt aber noch die Zonen Meta- Daten eingespielt, damit man das zumindest anhand der m2 sehen kann.

[Norb 0]

so sehen die Zonen bei mir aus:

[stolly82]

@Norb-0 OK, DANKE

Du hast Namen

PERFEKT!

[Norb 0]

Eine Sache ist mir noch aufgefallen, ich erhalte keine Plans mehr nach "Sync plans".
Mit der Vorgängerversion (0.1.4) hat das noch funktioniert. Ich weiß nicht ob mein Limit überschritten ist oder es am Adapter liegt.

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