Aqara

Talks to an Aqara/Xiaomi hub (M1S/M2/M3/E1, and similar) over its own local LAN protocol - UDP multicast discovery, then unicast JSON commands to the hub's own port. A configured hub has its own separately-tracked sub-devices joined underneath it, added by hand once the hub itself is connected.

Adding a hub

Devices & Services > Aqara > "Add hub" also appears in a "Discovered" tab automatically - the same UDP multicast step the protocol itself defines for discovery. Sub-devices are added by hand under a connected hub (no discovery step for those). State refreshes on a 10-second poll, not a live push connection.

Read-only by default. Write control needs your hub's own local network security key, obtained from the Aqara/Mi Home app's Developer Mode setting - without it, sub-devices still show live state, just nothing to control.

What's supported

Contact & motion sensors - magnet/contact sensors and PIR motion sensors.
Temperature & humidity sensors.
Wired wall switches and smart plugs.
RGB lights - on/off, brightness, hue/saturation color, and color temperature.

Any other sub-device model still connects and shows its own raw data as generic read-only sensors, rather than being rejected outright. Wireless buttons are a known gap - they report momentary clicks with no persistent state to read back, a shape Athena's entity model doesn't have anywhere yet. Every supported entity works with Dashboard cards and Automations exactly like any other integration, though not the History page's own multi-entity graphs.

This integration is unverified against real hardware - every wire format is confirmed against the official Aqara local-API reference, but no real hub was available to connect to during development.