# meross_lan: keeping Meross smart plugs off the vendor cloud

> meross_lan is a Home Assistant custom integration for Meross devices that talks to them over HTTP on your LAN, over a local MQTT broker, or over the vendor's own cloud brokers, and it can pair devices to a private broker so they never talk to Meross infrastructure at all. It suits Home Assistant users who own Meross hardware and want local control, and the awkward part is the device key, a secret held in the Meross cloud profile that you have to recover from the manufacturer app if you bind locally.

**krahabb/meross_lan** — Home Assistant integration for Meross devices

- Repository: https://github.com/krahabb/meross_lan
- Stars: 755 · Forks: 74
- Language: Python
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/krahabb-meross-lan

## Three communication layers behind one integration

meross_lan is a Home Assistant integration for Meross devices, and the interesting part is the second sentence of the project description. Despite its name, at the origin this was a project to only support LAN connectivity, but it now supports several communication layers.

The list is direct HTTP connection in the LAN for any reachable device, a local MQTT broker, the one configured in Home Assistant, and the Meross cloud MQTT brokers.

That last entry is the one that changes the character of the tool. The name says LAN, but the integration can also reach the devices through the vendor's own public MQTT brokers, using the public Meross MQTT brokers, and it has done so since the release named Cloudy, which the README gives as 4.0.0. So the project is not strictly a local-first tool; it is a tool that can be local, and whose origin was local, but which retains a path to the vendor infrastructure.

The two main use cases are described as follows.

The first is to keep your devices paired with the official Meross App and its cloud infrastructure while communicating with them directly over HTTP. The stated benefit is greater flexibility and less configuration pain, because there is no MQTT pairing to set up and configure for those devices. The integration side-communicates over HTTP, or over cloud MQTT, to the devices and polls them for status updates.

The second is to bind your devices to your private MQTT broker so as to completely disconnect them from the Meross infrastructure and interact only locally. The project is honest that this could prove to be a pain, and links a discussion on the subject.

The project is written in Python, MIT licensed, and the last push was on 2026-10-19. The topic tags name HACS and homeassistant, which is the distribution channel as much as the platform.

## Installing through HACS or by copying the component directory

There are two installation routes, and the manual one is short enough to state exactly.

Through HACS, you go to `HACS -> Integrations` in the Home Assistant frontend, search for Meross LAN and hit Install. You then have to restart Home Assistant so it recognises the new integration.

Manually, you download and copy the `custom_components/meross_lan` directory into the `custom_components` folder on your Home Assistant installation. The README notes that depending on the type of installation you might have to follow specific instructions, and that this is working for a standard core installation but should work for any other flavour. The practical point it makes is to remember to set the appropriate ownership and access rights on your copied files so the Home Assistant user running your instance is able to read and execute the integration code. Then restart Home Assistant to let it play.

The ownership detail is the one that catches people out. A component directory copied in as root with the wrong permissions loads, and then fails in ways that look like a bug in the integration rather than a filesystem permission problem.

The repository layout backs the manual route up. There is a `custom_components/` directory at the root, alongside `hacs.json` for the HACS metadata, a `command.py`, a `scripts/` directory, a `tests/` directory, `requirements_dev.txt` and `requirements_test.txt`, a `setup.cfg` and a `pyproject.toml`.

Two entries in that listing are unusual enough to be worth naming. There is an `emulator/` directory and an `emulator_traces/` directory, which together suggest the project can run against a captured or recorded protocol exchange rather than only against real hardware. That is a meaningful development aid for a protocol integration, since it removes the need for a physical plug on the desk to reproduce a failure. The `pyproject.toml` excludes `emulator_traces` from the pyright type checking set and includes `custom_components`, `emulator` and `tests` in it, and it configures black targeting py311 and isort with the black profile, with `custom_components.meross_lan` and `tests` as known first party modules.

## Discovery through dhcp, and the manual route when it fails

Setup is where the first real friction appears, and the README describes it accurately.

Once installed and restarted, your Meross devices should be automatically discovered by the Home Assistant `dhcp` integration, and will then pop up in the integrations panel ready to be configured. If devices are not automatically discovered, the advice is to power them off for 10 seconds and then power them back on, and a notification that new devices have been discovered should appear in notifications.

That advice is a tell. The discovery mechanism is DHCP, which means the integration is watching the network for the devices announcing themselves rather than polling a fixed address list. It also means discovery works only for devices on a network the Home Assistant instance can see the DHCP traffic for, and it means a device with a static address or on another segment may never appear.

To add devices or a Meross cloud account manually, you go to `HA->Settings->Devices & Services->Add Integration->Meross LAN` and choose what is appropriate.

What happens next depends on how the device is configured. For devices paired to the Meross cloud account, which the README calls the common use case when you buy and configure the devices with the manufacturer app, you can add the configuration manually or let it be discovered. Configuring a Meross cloud account greatly simplifies the configuration of devices, since this automatically downloads all of the needed information from the Meross account. You can still manually add devices without the cloud account login, but the guide warns you would need the device key, which is a secret stored in your Meross profile.

For devices privately MQTT bound to the same broker that Home Assistant is configured with, the device is only automatically discovered as soon as it publishes a new message to the broker. You then need to enter the same device key you configured when tinkering with the device rebind configuration tools.

The device key is the through-line in both cases, and it is the constraint that decides how offline you can really go.

## The device key, and why the local-only setup is harder than it sounds

The device key is used to sign messages according to the official Meross protocol behaviour. The setup guide explains what that means in practice and where the key comes from.

When manually configuring a device entry you can set the host address and the device key. The device key should be prefilled with a known key from other devices if you have already configured any before, which tells you that the key is per device but the configuration flow lets you reuse one for convenience.

If you enter a wrong or empty key, a menu asks whether you want to manually retry entering a different key or whether you want to recover the key from your Meross account. And the guide explains why recovery works: if your device is still paired to the Meross App, that is the way to recover the device key, since it is managed by the Meross App and saved in your cloud profile.

So the honest picture is this. The integration's name and its promise of local communication are real, and the HTTP path in particular needs nothing from the cloud at runtime. But the initial pairing of a device is managed by the manufacturer app, and the credential that lets you talk to the device lives in the vendor's cloud profile. Full disconnection from Meross infrastructure is possible via private MQTT binding, but you need that key, and getting it may mean using the app and the account at least once.

The host address setting has its own wrinkle, and the README is specific about it. Provide the IP address or a valid network host name, and when you set the IP address, try to ensure it is stable and not changing between reboots, otherwise the integration could lose access to the device. Starting from version 2.7.0, any dynamic IP change should be recognised by meross_lan, so you no longer have to fix that manually. The recognition exists, but the advice to prefer a stable address has not been withdrawn, which suggests it is still the safer path.

The rest of the settings are available once a device is set up the first time, by hitting CONFIGURE on the device entry from the meross_lan page and then Configure from the menu.

## Protocol auto-failover between HTTP and MQTT

The protocol option is the most technically interesting setting, and it is where the integration does something the other Home Assistant integrations for this hardware typically do not.

The software can communicate both over HTTP directly to the device or through an MQTT broker. When you configure an entry by IP address, whether manually or through DHCP discovery, it usually prefers to talk HTTP for obvious reasons, but it can nevertheless automatically switch to MQTT if it recognises that it is available, by sensing MQTT messages flowing through.

If you set Auto, or leave the field empty and unconfigured, you get this automatic failover switch in both directions between HTTP and MQTT, trying to always ensure the best available transport is used to communicate. If you force it, either HTTP or MQTT, no automatic protocol switching occurs and the integration will only talk that protocol for that configuration entry. The guide adds a caveat in brackets: some minor exceptions are in place at the moment and some commands are tried over HTTP first anyway.

That caveat is worth weighing, because it means the forced mode is not quite as absolute as the description suggests. Some commands still go over HTTP first even in a forced MQTT configuration.

The polling option sets the polling period, with a default of 30 seconds, and devices are generally polled to update their status. The optimisation described is that if the device is connected through MQTT, many general status update requests are automatically dropped, because the integration can rely on the device's PUSH behaviour. The notes say that this works if you set the protocol accordingly, and the sentence is cut off in the available text.

That optimisation is the reason the transport choice matters for more than reliability. Over MQTT, a device that pushes its own state changes means the integration does not need to ask, so the 30 second poll is mostly for the cases where nothing is arriving. Over plain HTTP, the poll is the only mechanism, so it is the accuracy of your state in Home Assistant that depends on that interval.

## Between the official integration and a full MQTT rewrite

The comparison worth making is with the other two routes to controlling Meross hardware from Home Assistant.

The first is the vendor's own integration, if one exists in the form you would otherwise use. The general shape of the trade is the one every cloud-connected device integration presents: the manufacturer path works with a single account, updates reliably, and puts your devices behind a vendor service. The local path gives you control, keeps the traffic on your network, and makes the device work when the internet does not. The cost of the local path is the device key, the rebinding procedure and, on this project, a beta version number.

The second alternative is to abandon the Meross app entirely and pair the devices to your own broker with a dedicated tool, then treat them as ordinary MQTT devices in Home Assistant. The project links a pairer app and a wiki page for the MQTT binding procedure, and it also says private MQTT binding could prove to be a pain, with a link to a discussion. That comment is telling, because it tells you that the local-only path is the harder one and that the project is not hiding that.

The third option, which is not really an option, is to write your own integration. The repository shows what that involves: a custom component, an emulator to develop against, a test suite, and configuration for black, isort, pylint and pyright. The pyright configuration sets typeCheckingMode to basic, and the pylint configuration disables a specific list of checks including broad-except, broad-exception-raised, global-statement, import-outside-toplevel, invalid-name, missing-class-docstring, missing-function-docstring and protected-access. That list is a description of the project's own style decisions, and it is a good indicator of how a protocol integration handles a device that occasionally answers with something unexpected.

The one thing meross_lan offers that neither alternative does is the option to leave the pairing alone. The device stays paired to the official app, so it keeps working with the app, keeps getting firmware updates through the vendor path, and the integration simply side-communicates. For a household where some people use the phone app and others use Home Assistant, that is the arrangement that avoids an argument.

The version numbers deserve a mention too. The listed releases are v6.0.0-beta.2 from 2026-10-11, v6.0.0-alpha.4 from 2026-06-22 and v6.0.0-alpha.3 from 2026-05-03, so the current major line is in beta, which tells you the 6.0 series is still settling.

## Conclusion

Adopt meross_lan if you own Meross hardware and want Home Assistant to control it locally rather than through the vendor's cloud, because the integration polls devices directly over HTTP and can keep the devices paired to the official app while doing so. Do not adopt it if you need a fully offline setup without ever touching the Meross account, because private MQTT binding still needs the device key, which the Meross app holds, and check first which protocol you want, since forcing HTTP or MQTT removes the automatic failover the integration otherwise performs.

## FAQ

### What communication methods does meross_lan support?

Direct HTTP connection in the LAN for any reachable device, a local MQTT broker as configured in Home Assistant, and the Meross cloud MQTT brokers. It has supported the public Meross brokers since the release named Cloudy, which is 4.0.0.

### How do I install meross_lan in Home Assistant?

Through HACS, go to HACS then Integrations, search for Meross LAN and hit Install, then restart Home Assistant. Manually, copy the custom_components/meross_lan directory into the custom_components folder and set the ownership and access rights so the Home Assistant user can read and execute the code, then restart.

### What is the device key and where do I get it?

It is used to sign messages according to the official Meross protocol behaviour. If a device is still paired to the Meross App, the key is managed by the app and saved in your cloud profile, so you can recover it from your Meross account, or you can reuse a known key from a device you already configured.

### How do I switch meross_lan between HTTP and MQTT?

The protocol option defaults to Auto, which senses whether MQTT is available and fails over in both directions between HTTP and MQTT. If you force HTTP or MQTT, no automatic switching happens for that entry, though some commands are still tried over HTTP first.

### Why are my Meross devices not discovered?

Discovery relies on the Home Assistant dhcp integration, so a device that does not announce itself will not appear. The README suggests powering the device off for 10 seconds and back on, and you can always add devices manually through Settings, then Devices and Services, then Add Integration, then Meross LAN.

### Is meross_lan still being maintained?

The repository is not archived and the last push was on 2026-10-19. The listed releases are v6.0.0-beta.2 from 2026-10-11, v6.0.0-alpha.4 from 2026-06-22 and v6.0.0-alpha.3 from 2026-05-03, and the code is MIT licensed.

## Sources

- [Issues](https://github.com/krahabb/meross_lan/issues)
- [krahabb/meross_lan on GitHub](https://github.com/krahabb/meross_lan)
- [License: MIT](https://github.com/krahabb/meross_lan/blob/master/LICENSE)
- [README](https://github.com/krahabb/meross_lan/blob/master/README.md)
- [Releases](https://github.com/krahabb/meross_lan/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/krahabb-meross-lan