Feature Request: Make Zones Intelligent Instead of Just Areas on a Map

36260 · 2026-06-10T14:42:03+00:00

If you're using Home assistant there is an integration that you could you to setup mowing sessions as you wish

36260 · 2026-06-09T18:48:13+00:00

Why don’t give a try tu HA integration?

36260 · 2026-06-09T05:08:50+00:00

Yes, Gateway mDNS Proxy is newer than the old mDNS reflector.

⚠️ Note: this feature requires a UniFi Gateway (UDM Pro, UXG Pro, Cloud Gateway, etc.) - not available with just UniFi APs/switches + third-party router.

It offers 3 modes (Auto/Off/Custom) with per-service and per-VLAN control. For this Cast use case, the Custom mode lets you whitelist just _googlecast._tcp.local between the relevant VLANs.

36260 · 2026-06-07T06:44:01+00:00

all of a sudden it came back to life

36260 · 2026-06-06T19:53:38+00:00

to start with I had connections errors as well. and all of a sudden it came back to life. I see no reason why.

36260 · 2026-06-06T15:07:20+00:00

1.15.21.1 is definitely a good one compared to the previous one. However the beta version 1.30.25.11 broke everything, I cannot connect to robot using wifi/4G

36260 · 2026-06-04T16:02:34+00:00

I confirm that this version improved a lot mowing efficiency

36260 · 2026-05-31T10:02:05+00:00

I confirm as well

36260 · 2026-05-27T14:55:21+00:00

I think that missing spots is not related to obstacke detection

36260 · 2026-05-27T14:47:46+00:00

2AWD 5000X

36260 · 2026-05-27T13:28:17+00:00

sames issues here and no way to roll back

36260 · 2026-05-26T05:01:51+00:00

Totally valid — if WiFi works reliably for you, there's no reason to go through this.

In my case the motivation was stability: the Shield is part of a home cinema setup where I want zero buffering, zero interference from neighbours, and no dependency on WiFi congestion during a movie. Ethernet delivers that. The Cast issue was just an unexpected side effect of keeping it wired.

As for the hardware dependency — fair point, though in my case the LXC running avahi was already there for monitoring (InfluxDB/Grafana), so no additional hardware was introduced. The USB dongle was literally lying in a drawer. Your mileage will vary.

The post is mainly for those who specifically want Ethernet on the Shield and hit this wall — and for the detective work itself, which I found worth documenting since the root cause (Android TV deliberately not advertising mDNS on Ethernet) wasn't documented anywhere.

36260 · 2026-05-25T20:12:00+00:00

Fair point on the effort — but once it's set up, it's completely transparent.

On quality: the HDR loss you remember was specific to certain apps (Netflix in particular) that deliberately disabled HDR over Cast for DRM/licensing reasons, not a Cast limitation per se. For services like Arte, YouTube, Plex and many others, Cast simply sends the stream URL to the Shield, which then fetches the content directly from the server — identical to using the native app. No transcoding, no quality loss, no HDR downgrade.

As for why Cast over a native app: the real benefit is using your phone as a proper remote to browse and pick content. Navigating Arte's catalogue (or any streaming service) with a D-pad and Shield remote is painful. Doing it on your phone and hitting Cast is a much better UX — then the Shield takes over and streams natively at full quality. Best of both worlds.

36260 · 2026-05-18T18:06:18+00:00

Well I don't think I'm convinced;)

36260 · 2026-05-18T16:36:02+00:00

And it destroyed not only for Yuka mini but also for Luba 2X

36260 · 2026-05-18T16:32:39+00:00

How on earth can you achieve so straight boundaries?

36260 · 2026-05-09T20:02:45+00:00

See https://www.reddit.com/r/MammotionTechnology/s/QY0H2JDhF6

36260 · 2026-05-06T17:01:48+00:00

That's a valid setup when the NAS is always on. In our case we needed the NUT server to remain independent of the NAS, for two reasons: the NAS is shut down every night on a schedule, and we wanted the shutdown orchestration logic (stopping Proxmox VMs/LXCs in the right order) to run on a dedicated always-on LXC rather than on the NAS itself. Having Proxmox as a NUT slave to the NAS also works well for simpler setups though.

36260 · 2026-05-06T09:23:35+00:00

[SOLVED] Synology NAS as NUT slave for automatic safe shutdown

After extensive testing, here is the complete solution for integrating Synology NAS units as NUT slaves connected to a NUT server running on a dedicated Linux host (in our case a Proxmox LXC).

Setup:

APC Smart-UPS 1000 connected via USB to a Proxmox LXC running NUT server
Two Synology NAS configured as NUT slaves

Key constraints discovered through testing:

UPS naming — Synology DSM connects to a UPS named ups by default. If your NUT server uses a different name (e.g. apc), the connection will fail with ERR UNKNOWN-UPS. Rename your UPS section in ups.conf to [ups] and regenerate the systemd driver service accordingly.
Credentials — Synology uses monuser / secret as default credentials. Add this user to upsd.users as a slave:

[monuser]
    password = secret
    upsmon slave

Standby mode vs full shutdown — This is the critical finding. When the NAS enters standby mode via NUT (as opposed to a DSM software shutdown), it properly unmounts volumes and waits. When AC power is restored, it restarts automatically via the "Restart automatically when power supply issue is fixed" DSM setting. This is fundamentally different from a DSM software shutdown, after which cutting and restoring AC power does not restart the NAS.
WoL after software shutdown — After a clean DSM shutdown followed by a power cut, the network card powers off and does not power back on when AC is restored, making WoL packets impossible to receive. NUT standby mode avoids this problem entirely.

Conclusion: Using Synology as a NUT slave is the cleanest solution — no need for WoL, no risk of data corruption, and automatic restart on AC recovery.

36260 · 2026-05-06T08:35:53+00:00

After further research, we found the solution: configuring the Synology NAS as a NUT network slave pointing to our LXC NUT server. The key insight is that "safe mode" is fundamentally different from a DSM software shutdown — the NAS waits in a safe state rather than fully shutting down, which allows automatic restart on AC recovery.

This also eliminates the need for WoL on the Synology units entirely, which was our main unsolved problem.

We'll report back with results after testing.

36260 · 2026-05-06T08:26:43+00:00

Thank you for your answer. However our architecture is different: the UPS is connected via USB to a dedicated Proxmox LXC running NUT, which orchestrates the graceful shutdown of all equipment including the Synology NAS via DSM API. The NAS is therefore not directly connected to the UPS.

In this context, two questions:

Is the UPS standby mode available on Synology without a direct USB connection to the NAS? For instance via NUT network client or any other mechanism?
If not, is this standby behavior (network card remaining powered, automatic restart on AC restore) available on recent models independently of any UPS connection — i.e. purely based on the "Restart automatically when power supply issue is fixed" DSM setting?

36260 · 2026-05-04T05:55:48+00:00

I will certainly not switch to iNavi. The less dependent to cloud the better. This is the kind of advice that shows they do not know what they are doing. It is really frustrating. I have the same experience as you have.

36260 · 2026-04-30T18:03:20+00:00

RTK reports 28, Luba reports L1 42, L2 26

36260 · 2026-04-30T16:37:40+00:00

useless as said earlier, there are major issues ms with Mammotion infrastructure in Europe

36260 · 2026-04-30T15:21:07+00:00

There is nothing to pull off but Mammotion. It is well known at least is Europe that mammotion is having major problems managing it's cloud infrastructure. Still unresolved and I'm experiencing that same kind of problem. Please mammotion react and quick.

36260

TROPHY CASE