5
Features that will not be implemented
Li Shuzhen edited this page 2025-12-04 14:58:12 +08:00

Binding a temperature sensor with an air conditioner outlet (aka, ac partner)

Home Assistant entities generated by xiaomi_home are strictly bound to device IDs. At present, there is no feasible or reliable way to make one entity display data coming from two or more different physical devices.

Bridging entities from Home Assistant into Mi Home APP

xiaomi_home is designed to import Xiaomi IoT devices into Home Assistant. Importing Home Assistant entities into Mi Home APP should be handled by another integration, just like HomeKit Bridge integration for Apple Home APP. Here we call this integration "MiHome Bridge".

However, developing MiHome Bridge to bridge entities which are generated by other IoT platform devices would expose Xiaomi to significant legal risk. Controlling devices from other IoT platforms within Mi Home APP without authorization from the device and the platform brand significantly increases the risk of infringement. Therefore, we have no plan to develop this integration.

Camera video stream

The camera video stream is encrypted using P2P encryption, with the encryption key negotiated between the Mi Home APP and the camera device. xiaomi_home is an untrusted client and cannot negotiate the video encryption key with the device, so it cannot fetch the camera video stream.

Importing devices from automotive space

Devices within the vehicle interior may impact driving and therefore require higher levels of safety and privacy than ordinary IoT devices. Consequently, such devices shall not be imported into xiaomi_home which is an untrusted client.

Importing mobile devices

Mobile phones, smart watches and smart bands contain user sensitive data. xiaomi_home cannot comply with the high-level privacy requirements for such personal devices. So xiaomi_home does not support importing mobile devices.

Setting multiple properties in one command message

MIoT-Spec-V2 protocol allows setting multiple properties in one command message. For example yeelink.light.bslamp1, you can turn on the light, set the brightness to 50% and set the color temperature to 3000K in one command message as follows:

{"id":1234,"method":"set_properties","params":[{"did":"2262","piid":1,"siid":2,"value":true},{"did":"2262","piid":2,"siid":2,"value":50},{"did":"2262","piid":4,"siid":2,"value":3000}]}

However, not all IoT devices support processing this type of message. Even if a device is capable of handling messages that contain multiple property settings, the number of property values it can process at one time varies from device to device. If the number of property values to be set in a single command message exceeds the device's capability, the device may crash or exhibit other anomalies.

The only certainty is that all devices can handle the command message that sets only one property value. It is extremely rare for a device to function only when multiple property values are set in one command message. If the device fails to operate properly when command messages are sent one by one, with each command setting only one property, then the device does not comply with the MIoT-Spec-V2 protocol standard.

After weighing the pros and cons, we decide that xiaomi_home only supports sending command messages that set only one property value at a time.

Vacuum robot map

The vacuum robot map is encrypted by a key negotiated between the Mi Home APP and the device, like the camera video stream. xiaomi_home is an untrusted client and cannot negotiate the map encryption key with the vacuum robot, so it cannot fetch the vacuum robot map.

WiFi speaker conversation history

The conversation history is stored on the WiFi speaker service cloud, not MIoT service cloud, and it cannot be delivered by the MIoT-Spec-V2 protocol message. xiaomi_home can only access MIoT service interfaces by OAuth 2.0 token obtained from the OAuth authorization server. WiFi speaker service interfaces are not accessible with this token.