Mammotion-HA puts a robot mower under Home Assistant, over BLE, Wi-Fi or the vendor cloud

What the integration actually controls

Mammotion-HA allows you to control and monitor Mammotion products, for example robot lawn mowers, using Home Assistant, and the feature list is concrete.

You can start, stop, pause and dock the mower. You can monitor the mower's status, with mowing, charging and idle given as examples, and you can view the battery level. You can start a mow based on configuration, and you can start an existing scheduled task. The README also notes support for Spino pool cleaners, which broadens the device range beyond mowing.

The roadmap shows what has been built and what has not. Bluetooth support, Wi-Fi support including SIM 3G and 4G, camera stream, scheduling, maps, firmware updates and automations are all ticked. Mapping and zone management is the one named item left unticked, with a More entry after it.

That single unticked box is the honest scope statement for the whole project, and it is the same thing the map offset feature exists to work around. A mower with satellite map tiles and RTK GPS coordinates will often have its position drawn several metres away from where the machine actually is, so the integration exposes two number entities, map offset latitude and map offset longitude, that shift the pin north or south and east or west in metres. Values are saved automatically and survive restarts, and typical offsets are within plus or minus 20 metres.

That is a mitigation, not the zone editor the roadmap is still waiting on.

The device protocol lives in PyMammotion, not in this repository

The architecture is a clean split, and it is worth understanding before you judge what the integration can do.

This integration uses the PyMammotion library to communicate with Mammotion mowers. PyMammotion provides a Python API for controlling and monitoring Mammotion robot mowers via MQTT, Cloud and Bluetooth. The dependency list pins it exactly, at pymammotion==0.10.11, alongside homeassistant>=2026.10.0, autotyping>=24.3.0 and pyagorartc==0.2.3.

So the Home Assistant repository handles entities, services, config flow and the dashboard surface, while the transport and protocol work sit in a separate library with its own release cadence. If a mower model behaves oddly, the first place to look is PyMammotion, not the integration.

The three transports are also the source of the two connection modes the README describes. Bluetooth support means talking to the mower over BLE, which needs a local proxy rather than a cloud round trip. Wi-Fi support, including SIM 3G and 4G cards, means the mower is reachable on your network or through its own connection. The MQTT and cloud paths are what PyMammotion provides for the vendor's hosted services.

The package metadata gives the language level and the test story. Python 3.14.2 or newer is required, the project targets Python 3.14 in mypy and pylint, and the test suite runs under pytest-homeassistant-custom-component with asyncio in auto mode, because that plugin ships autouse async fixtures which need the same mode Home Assistant core uses for its own suite. Coverage is measured with branch coverage over the custom_components/mammotion source.

Installing through HACS as a custom repository

The integration is not in the default HACS store, so the first step is adding the repository by hand. The README gives the sequence in full.

Go to HACS, then Integrations, and click the three dots in the top right corner. Select Custom repositories. In the Repository field, paste `https://github.com/mikey0000/Mammotion-HA`. For Category, select Integration. Click Add. You can then search for Mammotion within HACS and install it.

After installation you restart Home Assistant, then go to Settings, Devices and Services and click Add Integration to configure Mammotion. There is no pip install step here, which is normal for a Home Assistant custom integration, since HACS copies the code into the custom_components directory of your configuration.

Two prerequisites are listed before that, and the first one is a warning in bold. Home Assistant Minimum Version 2026.1.0.

The second prerequisite is the one people miss: a second account with your mower shared to it, for using Wi-Fi. The README explains why, and the reason matters because it is destructive in a small way: if you use your primary account it will log you out of your mobile app. Sharing the mower from a secondary account keeps the vendor app usable.

The third prerequisite is optional: a Bluetooth proxy for Home Assistant, with an ESP32-S3 mini and a USB-A to USB-C 0.3 m data cable listed as the parts. That is the path for BLE-only setups, where the mower has no network route of its own and the proxy forwards the Bluetooth traffic into Home Assistant.

The configuration problem in this integration is the account and the region

The troubleshooting section is short and points at two specific things.

The first is a discovery quirk: sometimes using the account number works instead of email address when adding via discovery, and the README admits it does not know why. That is the sort of detail that only appears in a project that has been debugged against real devices by real users, and it is worth knowing before you spend an evening on it.

The second is a network one, and it is the item to check first in most cases: a connection timeout to the host `https://api.link.aliyun.com/living/account/region/get`, with the fix given as unblock china. The vendor's account region lookup lives on an Aliyun endpoint, so a network that blocks traffic to Chinese hosts, or a DNS or firewall rule that does, will cause exactly this timeout. The same point is repeated in the troubleshooting list, where the recommendation is to make sure you are not blocking China.

The remaining troubleshooting steps are the ordinary ones: verify the Bluetooth proxy setup with Home Assistant, ensure the mower is connected to your home network and accessible from Home Assistant, and restart Home Assistant to see whether the problem persists.

The order matters. If the timeout appears, no amount of restarting fixes it, because the failure is at the network boundary and not in the integration. Confirm reachability of that host first, then work through the rest.

Dashboard plugins extend the integration into maps and editing

The project maintains three companion HACS dashboard plugins, and this is where it becomes more than a set of entities.

Mammotion Assets is a repository of images and scripts for displaying mowers on a map: mower card backgrounds, side-profile images, map icons, RTK and dock assets, and a geojson.js script that renders mowing areas with labels.

Mammotion GeoJSON Map Plugin is a Lovelace resource that renders GeoJSON mowing areas on the map with area names and zone labels.

Mammotion SVG Pick and Place is the most ambitious of the three. It is an interactive Lovelace card for placing, editing and deleting SVG pattern tiles on the mower's map directly from the dashboard. You load an SVG, drag it into position, scale and rotate it, then send it to the device in one click through the `mammotion.svg_add` service.

That third plugin is worth pausing on, because it points at a capability that has nothing to do with just monitoring. Sending a pattern to the device from a dashboard is a write path into the mower's navigation system, and it exists even though zone management is still unticked on the roadmap. The distinction is that pattern tiles are a discrete object the device accepts, whereas zone management is about the mower's own boundary configuration.

The plugin repositories are separate from the integration repository, so installing them is a second HACS operation each, and the README lists them with their own custom repository links rather than folding them into one package.

Beta releases, an unknown licence and a maintained but young project

The release history deserves a close reading. The three most recent releases are v0.6.19-beta4 on 2026-10-19, v0.6.19-beta3 on 2026-10-17 and v0.6.19-beta2 on 2026-10-17, and the last push to the repository was on 2026-10-19. The repository is not archived.

Three beta builds of the same version number in three days is a signal about the workflow: the maintainer is releasing continuously while the version stays in beta, rather than cutting numbered releases per change. The version string in pyproject.toml is 0.6.19-beta4, which matches the tag.

The README states plainly that the integration is still a work in progress, that you may encounter unfinished features or bugs, and that issues should be opened on the GitHub repository. That is an honest statement, and it means you should expect change between beta builds.

Licence is the part to look at carefully. The repository's licence field is recorded as unknown, and there is no licence badge or statement in the README body. For a Home Assistant custom integration that you copy into your own configuration, this matters less than it would for a library you redistribute, but it is still the kind of gap worth raising before you depend on it.

The surrounding tooling is a sign of a serious workflow for a project of this size. There is a .pre-commit-config.yaml, a .yamllint.yaml, a mypy.ini, ruff and pylint configuration, a uv.lock, a FUNDING.yml, a crowdin.yml for translations and a scripts/ directory, and the translations are managed through Crowdin with contributions arriving as pull requests.

Where Mammotion-HA is the wrong choice

There are three reasons to look elsewhere.

The first is the beta status. If you are running Home Assistant for a household that depends on the mower finishing the lawn, three beta builds a week is a moving target, and the README does not promise stability for unfinished features.

The second is the transport dependency. The integration's reach depends on the device being reachable by one of three paths, and each has a cost. The cloud and MQTT paths require the vendor's servers, including the Aliyun region endpoint that is a documented failure point behind a firewall. The Bluetooth path requires an ESP32-S3 proxy and a cabling exercise. The Wi-Fi path requires a shared second account, which is a workaround born out of the vendor app logging you out.

The third is scope. Zone management is not implemented, and if your requirement is per-zone mowing schedules, this integration does not cover it and the vendor app remains necessary.

The realistic alternative is to stay inside the Mammotion app and expose the mower to Home Assistant indirectly, through whatever the vendor app offers for external control, or to use a different integration ecosystem entirely if your needs are basic. What Mammotion-HA adds over the vendor app is automation: starting a mow when nobody is home, reacting to the battery level, docking on a schedule. If you do not need that, the plugin repositories and the offset entities are effort without payoff.

For a user who does need automation and already runs HACS with custom repositories, the offset entities are the clearest evidence of the project's value, because they exist precisely to fix a display problem that the vendor app does not address.

Editorial conclusion

Mammotion-HA fits a Home Assistant user with a Mammotion mower who wants the device in dashboards and automations rather than only in the vendor app, and who is willing to install an integration from a custom HACS repository. It does not fit a deployment that needs a stable contract, since every listed release is a beta and the README calls the integration a work in progress with unfinished features. Install it through HACS with the repository URL `https://github.com/mikey0000/Mammotion-HA`, and check the connection to `https://api.link.aliyun.com/living/account/region/get` before assuming a configuration failure, because the README identifies blocked access to that host as the cause of a timeout.

Frequently asked questions

Official sources

1. Issues
2. mikey0000/Mammotion-HA on GitHub
3. README
4. Releases