Problems with philips.light.sread1 // Different MCU commands?

[V4n1X]

I discovered this project and try to implement it on a: philips.light.sread1
Hardware is: Xiaomi MHCW03P module
The MiOT Spec page should be: philips.light.sread1
But I guess it is incomplete, the ambient, nightcare etc are not listed and are availble to control with the Xiaomi Miio HomeAssistant Integration.
This is the log from the HA integration:

['power', 'bright', 'notifystatus', 'ambstatus', 'ambvalue', 'eyecare', 'scene_num', 'bls', 'dvalue']
['on', 100, 'off', 'on', 100, 'off', 1, 'on', 0]

Detecting chip type... ESP8266
Chip is ESP8285
Features: WiFi, Embedded Flash
Crystal is 26MHz
MAC: 
Stub is already running. No upload is necessary.
Detected flash size: 2MB

I use the following ESPHome Config:

Details

# https://home.miot-spec.com/spec?type=urn:miot-spec-v2:device:light:0000A001:philips-sread1:1
# https://home.miot-spec.com/spec?type=urn:miot-spec-v2:device:light:0000A001:philips-sread2:1
# https://home.miot-spec.com/spec?type=urn:miot-spec-v2:device:light:0000A001:philips-sread6:1

# To fix OTA problems I currently use that fork
external_components:
  source: github://9R/esphome-miot@main

esphome:
  name: light-2-philips-desklamp
  friendly_name: Light-2-Philips-Desklamp

esp8266:
  board: esp01_1m

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "removed"
  reboot_timeout: 0s
  services:
    - service: mcu_command
      variables:
        command: string
      then:
        - lambda: 'id(miot_main).queue_command(command);'

ota:
  - platform: esphome
    password: "removed"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Light-2-Philips-Desklamp"
    password: "removed"

captive_portal:

time:
  - platform: homeassistant
    id: homeassistant_time

# Testing purpose only
web_server:
  port: 80

uart:
  tx_pin: GPIO15
  rx_pin: GPIO13
  baud_rate: 115200
  debug:
    direction: BOTH
    dummy_receiver: false
    after:
      delimiter: "\n"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

miot:
  id: miot_main
  miot_heartbeat_siid: 0
  miot_heartbeat_piid: 0

switch:
  - platform: "miot"
    miot_siid: 2
    miot_piid: 1
    name: "Power"
    icon: mdi:power

number:
  - platform: "miot"
    miot_siid: 2
    miot_piid: 2
    name: "Brightness"
    min_value: 1
    max_value: 100
    step: 1

MCU identification and load of the module is ok:

[21:06:40][C][miot:119]: MIoT:
[21:06:40][C][miot:121]:   Model: philips.light.sread1
[21:06:40][C][miot:123]:   MCU Version: 0024
[21:06:40][C][miot:125]:   Time: AVAILABLE

Got MCU UART communication:

[21:06:42][D][uart_debug:158]: <<< "net\r"
[21:06:42][D][uart_debug:158]: >>> "cloud\r"
[21:06:42][D][uart_debug:158]: <<< "get_down\r"
[21:06:42][D][uart_debug:158]: >>> "down none\r"
[21:06:42][D][uart_debug:158]: <<< "get_down\r"
[21:06:42][D][uart_debug:158]: >>> "down none\r"

Sometimes I get timeouts:
[21:06:44][E][miot:086]: Timeout while receiving from MCU, dropping message 'get_do???'

Log when it tries to get the current state from the MCU:

[21:06:59][D][miot:140]: Queuing MCU command 'get_properties 2 1 2 2'
[21:06:59][D][uart_debug:158]: >>> "down none\r"
[21:06:59][D][uart_debug:158]: <<< "get_down\r"
[21:06:59][D][uart_debug:158]: >>> "down get_properties 2 1 2 2\r"
[21:07:00][D][uart_debug:158]: <<< "result \r"
[21:07:00][D][uart_debug:158]: >>> "ok\r"
[21:07:00][D][uart_debug:158]: <<< "get_down\r"
[21:07:00][D][uart_debug:158]: >>> "down none\r"

Now the interesting part:
If I operate the device on the buttons I get the following communication:

[21:07:09][W][miot:352]: Unknown command 'props'
[21:07:09][D][uart_debug:158]: <<< "props power \"on\"\r"
[21:07:09][D][uart_debug:158]: >>> "ok\r"
[21:07:10][W][miot:352]: Unknown command 'props'
[21:07:10][D][uart_debug:158]: <<< "props dim 40\r"
[21:07:10][D][uart_debug:158]: >>> "ok\r"
[21:07:12][W][miot:352]: Unknown command 'props'
[21:07:12][D][uart_debug:158]: <<< "props dim 100\r"
[21:07:12][D][uart_debug:158]: >>> "ok\r"
[21:07:14][W][miot:352]: Unknown command 'props'
[21:07:14][D][uart_debug:158]: <<< "props eyecare \"on\"\r"
[21:07:14][D][uart_debug:158]: >>> "ok\r"
[21:07:15][W][miot:352]: Unknown command 'props'
[21:07:15][D][uart_debug:158]: <<< "props eyecare \"off\"\r"
[21:07:15][D][uart_debug:158]: >>> "ok\r"
[21:07:16][W][miot:352]: Unknown command 'props'
[21:07:16][D][uart_debug:158]: <<< "props amb \"on\"\r"
[21:07:16][D][uart_debug:158]: >>> "ok\r"
[21:07:19][W][miot:352]: Unknown command 'props'
[21:07:19][D][uart_debug:158]: <<< "props amb \"off\"\r"
[21:07:19][D][uart_debug:158]: >>> "ok\r"
[21:07:33][W][miot:352]: Unknown command 'props'
[21:07:33][D][uart_debug:158]: <<< "props power \"off\"\r"
[21:07:33][D][uart_debug:158]: >>> "ok\r"

And this is the output if i try to use the switches with the siid and piid from the miot spec:

[21:27:53][D][switch:012]: 'Power' Turning ON.
[21:27:53][D][miot:140]: Queuing MCU command 'set_properties 2 1 true'
[21:27:53][D][uart_debug:158]: >>> "down none\r"
[21:27:53][D][uart_debug:158]: <<< "get_down\r"
[21:27:53][D][uart_debug:158]: >>> "down set_properties 2 1 true\r"
[21:27:53][W][miot:352]: Unknown command '5get_down'
[21:27:53][D][uart_debug:158]: <<< "5get_down\r"
[21:27:54][D][uart_debug:158]: >>> "ok\r"

Anyone a clue how can I fix that?

[cristianchelu]

MiIO vs MiOT

Unfortunately, this device is using the older "MiIO" protocol, which is not supported by this component.

The new "miot" protocol uses integer ID's for service/properties (properties_changed 1 2 3), while the older has device-specific labels and values, as evidenced by props amb "off". The protocols used are incompatible, and a new project would need to be created in order to convert these older devices.

For identification, you can see the "miio2miot" tag on the philips.light.sread1 MiOT spec search results. I also have an unsupported "Mi Smart Antibacterial Humidifier" collecting dust because of this. Notice in this link how the deerma.humidifier.jsq has the tag miio2miot while the newer deerma.humidifier.jsq5 has the tag miot-local. Why they felt the need to release a whole new product instead of a firmware update is beyond me 😄

ESP8266 quirks

Sometimes I get timeouts:
[21:06:44][E][miot:086]: Timeout while receiving from MCU, dropping message 'get_do???'

The ESP8266 is too weak to handle 2 serial ports in parallel, causing lost characters (??).

One serial port is from the uart used by this component

uart:
  tx_pin: GPIO15
  rx_pin: GPIO13
  baud_rate: 115200

miot:
  id: miot_main

while the second serial port is enabled by default by the logger component of esphome. This is fixed by adding baud_rate: 0 to the logger block:

logger:
  level: DEBUG
  # Important: Disable UART1 logging to avoid hardware errors on main UART0
  baud_rate: 0

... but that's not going to help having an unsupported device.

[V4n1X]

Thanks for that clarification, so I found probably the config settings for that old model spec: hass-xiaomi-miot

I am sadly not that firm with C++, only with python, but I will take a look, if I can manage to do at least some progress, I still have a few old devices, that would be to sad to throw away.

I also came across that protocol: "miio2litter" do you know anything about that maybe?

    'philips.light.sread2': {
        'miio_specs': {
            'prop.2.1': {'prop': 'power', 'setter': True, 'format': 'onoff'},
            'prop.2.2': {'prop': 'bright', 'setter': True},
            'prop.2.3': {'prop': 'scene_num', 'setter': True, 'dict': {
                'None': 0,
                'Child Reading': 1,
                'Adult Reading': 2,
                'Computer': 3,
            }},
            'prop.3.2': {'prop': 'ambstatus', 'setter': True, 'format': 'onoff'},
            'prop.3.3': {'prop': 'ambvalue', 'setter': True},
            'prop.3.4': {'prop': 'notifystatus', 'setter': True, 'format': 'onoff'},
            'prop.3.5': {'prop': 'eyecare', 'setter': True, 'format': 'onoff'},

[cristianchelu]

miio2litter is miio2miot after autocorrect, I assume.

It's a compatibility layer, as far as I know, so that you can use integrations like "Xiaomi Miot Auto" with older devices. However that's with the original firmware. The HA integrations speak miot with SIIDs/PIIDs, but by the time they reach the device the messages are already get_props eyecare and set_props ambstatus \"on\", etc.

To use the device under esphome with truly open firmware someone has to implement the miio protocol as an external component.

As you may have seen, the miio protocol is a bit more of a wild west, so harder to create a component for :/ , and too different from miot to just add support in this project.

[vartom]

For my project( dmaker.airfresh.t2017), I made the following patch for this old type of commands.
https://github.com/vartom/mipurifier-esphome/tree/MJXFJ-300-G1
Maybe this will help you in your project.