hencou / esphome_components Goto Github PK

Hi,
I now the following setup:

• 1st S2 remote is not paired with any light, I only intercept it's keypresses to control a wifi-enabled light via HomeAssistant.
• 2nd S2 remote is actually paired with the FUT038s controller

The MiLight hub (nodemcu + nrf24) flashed with esphome + your mi component is supposed to intercept the keypresses from the first S2, but is also paired with the FUT038s and can control the light. Here's the yaml I use (part of it):

mi:
  id: mi1  #optional
  ce_pin: D2 #required, default: 4
  csn_pin: D8 #required, default: 15
  reset_pin: 0 #optional, default: 0, only needed with LT8900 radio
  radio_interface_type: nrf24 #optional, default: nrf24, possible values: nrf24,lt8900
  packet_repeats: 50 #optional, default: 50, total of sended packets per command
  listen_repeats: 10 #optional, default: 20, amount of received packets needed for a incoming command from other remote
  state_flush_interval: 5000 #optional, default: 10000, time in miliseconds to send the latest state report to HomeAssistant
  packet_repeat_throttle_threshold: 200 #optional, default: 200, threshold to limit the amount of packets in a second
  packet_repeat_throttle_sensitivity: 0 #optional, default: 0
  packet_repeat_minimum: 3 #optional, default: 3
  enable_automatic_mode_switching: true #optional, default: false
  rf24_power_level: MAX #optional, default: MAX, possible values: MIN, LOW, HIGH, MAX
  rf24_listen_channel: HIGH #optional, default: LOW, possible values: LOW, MID, HIGH
  packet_repeats_per_loop: 10 #optional, default: 10, repeat packets sended per loop
  resend_last_command: false #optional, default: true, repeats the latest command after a random time between 2 and 3 seconds again
  rf24_channels: #optional, 1-3 values required when used, default: LOW-MID-HIGH, possible values: LOW, MID, HIGH
    - LOW
    - MID
    - HIGH
  on_command_received: #optional, useful to send remote commands to HA and process them further there in automations
    - homeassistant.event:
        event: esphome.mi_command_received
        data:
          device_id: !lambda "return format_hex(data.device_id);"
          group_id: !lambda "return data.group_id;"
          remote_type: !lambda "return data.remote_type.c_str();"
          command: !lambda "return data.command.c_str();"




light:
  - platform: mi #required
    device_id: 0xAB01 #required, hexadacimal value of MiLight id
    id: fake
    internal: True
    group_id: 1 #required, 1-4 or 1-8, depending on remote type
    remote_type: s2 #required, possible values: rgb_cct, rgb, cct, rgbw, fut089, fut091, fut020, s2
    default_transition_length: 0s #optional, but 0s gives a better behaviour instead the default 200ms
  # Set these to calibrate the color temperature of your light, measured with an external color temp. sensor or app
  # optional, [153, 370] mireds is the range miboxer uses internally ([6535, 2702] K)
    cold_white_color_temperature: 6500 K
    warm_white_color_temperature: 2700 K
# optional variables: all variables of ESPHome base light component

  - platform: mi
    name: MiBoxer
    id: miboxer
    device_id: 0xAB02
    group_id: 2
    remote_type: rgbw
    default_transition_length: 0s

button:
  - platform: mi
    id: pair
    name: ${friendly_name} pair
    device_id: 0xAB02
    group_id: 2
    remote_type: rgbw
    command: pair
    entity_category: config
  - platform: mi
    id: unpair
    name: ${friendly_name} unpair
    device_id: 0xAB02
    group_id: 2
    remote_type: rgbw
    command: unpair
    entity_category: config

The problem is:
If I have only the "fake" light enabled (the other is commented out) then all the keypresses from the first S2 are received correctly. But as soon as I enable the "miboxer" light the keypresses from the first S2 are very rarely received. And sometimes even the wifi connection is dropped and I need to reset the hub. However sending the commands to FUT038s works fine.
I've noticed that the first keypress always gets through, but later - very rarely. It's almost as if the receiver does not get cpu time to do the detection.
The logs (VERY_VERBOSE) don't show anything interesting, but I can attach them if needed.

I can try debugging this, but don't really know where to start. Is there any particular place I where should add traces to see what's going on?

Hi @hencou and great work!

I spent several hours (I do not even want to count them 🤦‍♂️) in trying to perfectionize and combine the mi lights with the rest of my home and I had great succes, I would say.

My Setup

• I am using the nodemcuv2 board with an nrf24 with external antenna. ESPHome 2023.9.0-dev
• I have a CCT remote and CCT controllers.
• I configured the milight hub to act as a fut091 remote, as suggested in another topic here, to avoid the weird behavior of unwanted delays or no response, when dimming or changing the temperature from HA. This works now as expected 👍
• The next issue I encountered was that I got no feedback from the cct remote on the MH, because for every group and device id, I had configrured the remote_type fut091. The workaround was to define further 'fake' groups with another device id and the remote_type cct. Now I'm catching almost all mi-remote commands, not everyone but good enough.

My intention
I tried to go a step further and implement an automation for the received mi light remote comand, to stay in sync with the states of the entities. Thus, as soon someone uses the remote (instead of HA) HA will know about it, but I got into some troubles.
The issue
My issue now is that when I press AND hold the brightness or temperature buttons (it doesn't matter which one; up, down, left right), the milight hub reports after the first command (which is still correct), multiple "night_mode" commands, until I release the pressed button.

[01:00:12][D][mi:067]: Received packet: 
cct packet received (7 bytes):
Request type  : 5A
Device ID     : 0158
b1            : 01
b2            : 0F
b3            : 25
Sequence Num. : EF
[01:00:12][D][mi:128]: Received Milight request: {"command":"temperature_down"}
[01:00:13][D][mi:067]: Received packet: 
cct packet received (7 bytes):
Request type  : 5A
Device ID     : 0158
b1            : 01
b2            : 1F
b3            : 26
Sequence Num. : 00
[01:00:13][D][mi:128]: Received Milight request: {"command":"night_mode"}
[01:00:13][D][mi:067]: Received packet: 
cct packet received (7 bytes):
Request type  : 5A
Device ID     : 0158
b1            : 01
b2            : 1F
b3            : 27
Sequence Num. : 01
[01:00:13][D][mi:128]: Received Milight request: {"command":"night_mode"}
.... 

It is interesting, because the b2 (which is the id of the specific command, I suppose) remains unchanged.
It may be related to some timing issues...?

my actual yaml configuration of the hub is not much different than the dafult example provided here:

external_components:
  - source: github://hencou/esphome_components
    components: mi
  
esp8266:
  board: nodemcuv2

# Enable logging
logger:
  level: DEBUG

# Enable Home Assistant API
api:
  encryption:
    key: "..."
  reboot_timeout: 24h
  services:                                                              #optional, only to show howto send json commands
  - service: mi_command                                                  #optional, only to show howto send json commands
    variables:                                                           #optional, only to show howto send json commands
      device_id: int                                                     #optional, only to show howto send json commands
      group_id: int                                                      #optional, only to show howto send json commands
      type: string                                                       #optional, only to show howto send json commands
      command: string                                                    #optional, only to show howto send json commands
    then:                                                                #optional, only to show howto send json commands
      - lambda: |-                                                       #optional, only to show howto send json commands
          const BulbId bulbId = {                                        //#optional, only to show howto send json commands
           device_id,                                                    //#optional, only to show howto send json commands
            group_id,                                                    //#optional, only to show howto send json commands
            MiLightRemoteTypeHelpers::remoteTypeFromString(type.c_str()) //#optional, only to show howto send json commands
          };                                                             //#optional, only to show howto send json commands
          id(mi1).write_state(bulbId, command);                          //#optional, only to show howto send json commands
ota:
  password: "..."

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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: ${device_name}
    password: !secret ap_password


# Example configuration entry - single controller
spi:
  clk_pin: GPIO14
  mosi_pin: GPIO13
  miso_pin: GPIO12
  
mi:
  id: mi1  #optional
  ce_pin: D2 #required, default: 4
  csn_pin: D8 #required, default: 15
  listen_repeats: 100 #optional, default; 20, amount of received packets needed for a incoming command from other remote
  state_flush_interval: 1500 # 0 on production Wemos # optional default; 10000 time in miliseconds to send the latest state report to HomeAssistant

  enable_automatic_mode_switching: false #optional, default; false
  rf24_power_level: MAX #optional, default; MAX, possible values; MIN, LOW, HIGH, MAX
  rf24_listen_channel: HIGH #optional, default; LOW, possible values; LOW, MID, HIGH  (btw.  I tried them all, no difference)
  resend_last_command: true #optional, default; true, repeats the latest command after a random time between 2 and 3 seconds again
  rf24_channels: #optional, 1-3 values required when used, default: LOW-MID-HIGH, possible values: LOW, MID, HIGH
    - LOW
    - MID
    - HIGH
  on_command_received: #optional, useful to send remote commands to HA and process them further there in automations
    - homeassistant.event:
        event: esphome.mi_command_received
        data:
          device_id: !lambda "return format_hex(data.device_id);"
          group_id: !lambda "return data.group_id;"
          remote_type: !lambda "return data.remote_type.c_str();"
          command: !lambda "return data.command.c_str();"
light:
  - platform: mi #required
    id: light_stairs #required
    name: ${light_stairs} #required
    device_id: 0x0200 #required, hexadacimal value of MiLight id
    group_id: 1 #required, 1-4 or 1-8, depending on remote type
    remote_type: fut091 #required, possible values; rgb_cct, rgb, cct, rgbw, fut089, fut091, fut020
    default_transition_length: 0s #optional, but 0s gives a better behaviour instead the default 200ms
... some more entries....
  - platform: mi # <=== this is one of the fake entries I made to be able to receive the cct remote commands again. I made one for every group, in the hope for snappier catch of the commands ?
    id: mi_remote_1
    name: "MI Remote"
    device_id: 0x0158  # this is actually the id of the real remote
    group_id: 1 
    remote_type: cct

Any help is appreciated!
Tank you & BR

Hi, excuse me for asking here, but can I use this with esp32? or is it only esp8266.

I've managed to get this going on an esp8266 with no webserver as that conflicts library version of ArduinoJson used by webserver, how do I specify which pins on an esp32?

Hi, really excellent work!!!!. is this a WiP?, not ready?.
Because I cannot get it to work. It connects to API in homeassistant, but pariing doesn't work.
I'm trying to use it with a FUT092 RGB-CCT.
I've use/used it with a wemos d1 mini. with sidoh/esp8266_milight_hub it works great, but this with esphome is more what I want/look for.

From serial "Opening settings file failed" but then it connects, I tried different boards. erase_flash etc etc...

Pairing in homeassistant doesn't work. it connects to board API when I press pair button but nothing happens, I had a look with tcpdump.

Hi, truly loving the native ESPhome version for those who do not have an MQTT setup.

I do have a feature request though, not withstanding that I might be doing something wrong.

This is the (working) mi configuration on an ESP32:

mi:
  listen_repeats: 3
  id: mihub
  ce_pin: GPIO16
  csn_pin: GPIO5
  reset_pin: 0
  state_flush_interval: 5000
  packet_repeats: 50 #75
  packet_repeats_per_loop: 10 #75
  radio_interface_type: nrf24
  rf24_power_level: MAX
  rf24_listen_channel: LOW
  rf24_channels:
    - LOW
    - MID
    - HIGH
  packet_repeat_throttle_threshold: 2000
  packet_repeat_throttle_sensitivity: 0 #40
  packet_repeat_minimum: 2
  enable_automatic_mode_switching: false  

I'd like to have a custom effect on a specific device/group id which I call Hue-Swing.

• You set the RGB/HSV color value,
• give it a time value (e.g., number hs_tt = 10s) and
• a 'Hue delta' (e.g., hs_amount=20).

While maintaining the currently set HSV saturation and value, the color of the light will then just

• linearly "fade" to the light's currently set Hue value plus the Hue delta,
• return to the currently set color ("center color"),
• linearly "fade" to the light's currently set Hue value minus the Hue delta,
• and return to the currently set color ("center color"),
  This should happen very slowly.

This is my light definition:

light:
  - platform: mi
    id: garden_test
    name: "Garden Test"
    device_id: 0xAAA1
    group_id: 1
    remote_type: rgb_cct
    default_transition_length: 5s
    effects:
      - lambda:
          name: Hue Swing (HS)
          // Make the transition time configurable by executing this request fast.
          update_interval: 0.1s
          lambda: |-
            static float curRed, curGreen, curBlue, curSat, curVal;
            static int curHue;
            static int state;
            static int counter;
            static BulbId bulbId = { 0xAAA1, 1, MiLightRemoteTypeHelpers::remoteTypeFromString("rgb_cct") };
            if (initial_run) {
              // Reset counters
              state = 0;
              // Get the current color as esphome::light::LightColorValues in the range [0.0, 1.0] ...
              auto currentValues = id(garden_test).current_values;
              curRed = currentValues.get_red();
              curGreen = currentValues.get_green();
              curBlue = currentValues.get_blue();
              // Transform the current color as HSV
              rgb_to_hsv(curRed, curGreen, curBlue, curHue, curSat, curVal);
              ESP_LOGI("effect-hs", "Starting Hue-Swing effect...");
              ESP_LOGI("effect-hs", "  * center: r=%1.4f g=%1.4f b=%1.4f | h=%03d s=%1.4f v=%1.4f", curRed, curGreen, curBlue, curHue, curSat, curVal);
            }
            // Do we need to do anything? Has the transition time from NUMBER expired and we need to set a new destination color?
            if (++counter < (int)(id(hs_tt).state * 10.0) && !initial_run) { return; }
            counter = 0;
            
            // Adapt transition length to slider value
            ESP_LOGD("effect-hs", "  * tl: %05d ms", (int)(id(hs_tt).state*1000.0));
            float r,g,b;
            char command[100];

            switch (state) {
              case 0:
                // Initial center value
                ESP_LOGD("effect-hs", "  * center: r=%1.4f g=%1.4f b=%1.4f | h=%03d s=%1.4f v=%1.4f", curRed, curGreen, curBlue, curHue, curSat, curVal);
                sprintf(command, "{\"color\":{\"r\":%d,\"g\":%d,\"b\":%d}, \"transition\":%d}", (int)(curRed*255), (int)(curGreen*255), (int)(curBlue*255), (int)(id(hs_tt).state));
                break;
              case 1:
                // Upper value
                hsv_to_rgb( (int)(curHue+id(hs_amount).state)%360, curSat, curVal, r, g, b);
                ESP_LOGD("effect-hs", "  * upper: r=%1.4f g=%1.4f b=%1.4f | h=%03d s=%1.4f v=%1.4f", r, g, b, (int)(curHue+id(hs_amount).state)%360, curSat, curVal);
                sprintf(command, "{\"color\":{\"r\":%d,\"g\":%d,\"b\":%d}, \"transition\":%d}", (int)(r*255), (int)(g*255), (int)(b*255), (int)(id(hs_tt).state));
                break;
              case 2:
                // Return to center value
                ESP_LOGD("effect-hs", "  * center: r=%1.4f g=%1.4f b=%1.4f | h=%03d s=%1.4f v=%1.4f", curRed, curGreen, curBlue, curHue, curSat, curVal);
                sprintf(command, "{\"color\":{\"r\":%d,\"g\":%d,\"b\":%d}, \"transition\":%d}", (int)(curRed*255), (int)(curGreen*255), (int)(curBlue*255), (int)(id(hs_tt).state));
                break;
              case 3:
                // Lower value
                hsv_to_rgb( (int)(curHue-id(hs_amount).state+360)%360, curSat, curVal, r, g, b);
                ESP_LOGD("effect-hs", "  * lower: r=%1.4f g=%1.4f b=%1.4f | h=%03d s=%1.4f v=%1.4f", r, g, b, (int)(curHue-id(hs_amount).state+360)%360, curSat, curVal);
                sprintf(command, "{\"color\":{\"r\":%d,\"g\":%d,\"b\":%d}, \"transition\":%d}", (int)(r*255), (int)(g*255), (int)(b*255), (int)(id(hs_tt).state));
                break;
            }
            id(mihub).write_state(bulbId, command);
            state = (state+1)%4;

Several Questions:

• I'm not using the auto call = id(garden_test).turn_on(); and then call.perform();, because that did not work.
• Instead, I sprintf() the command into a char buffer and give it to the mi component to send. It works, but likely not the right way?
• The transition field which works in the original MQTT based repo, does not work here.
• The ESPhome native default_transition_time also does not work.
• The light will adapt to the new color with a very small transition time, about 0.5s

Does that make sense?

Just in case another one also facing the update problems I had recently ... :D
Apparently, my device config was outdated.

Fixed it by commenting out

libraries:
  - milight: https://github.com/hencou/esphome-milight

under the esphome: key.

Checked the URL, was offline.
Checked, if project itself still is maintained.
Checked examples for any changes, found libraries entry missing in new config, removed it, worked :D

Btw. thanks for this great project.
Used MiLight Hub for years. But other than ESPHome, it is not rebooting when network is lost / falsely asumed to be intact, and therefore ESP chip disconnected often and went unresponsive.
I even submitted ab bug report on this to the MiLight Hub repo some years ago - the problem was not understood as such and the report was closed :p :D

Switched to your project a year or two ago, or so.
Since then no more problems.

I want to set 25 pcs (currently only 9 pcs) Mi-Light FUT064 LED panels at the same time and unfortunately there is a huge difference (1-2 seconds) between the panels when it's modifying.

Video:
https://youtu.be/GbGLZqP7tlQ

YAML file detail:

• platform: mi
  id: mi_light_living_room
  name: "Living room"
  device_id: 0xAB01
  group_id: 1
  remote_type: rgb_cct

LOG:
[15:45:28][D][light:035]: 'Living room' Setting:
[15:45:28][D][light:054]: Color brightness: 100%
[15:45:28][D][light:058]: Red: 0%, Green: 0%, Blue: 100%
[15:45:28][D][light:084]: Transition length: 0.2s
[15:45:28][D][mi.light:386]: Send Milight request: {"color_mode":"rgb","state":"ON","brightness":255,"color":{"r":253,"g":253,"b":255}}
[15:45:28][D][mi.light:386]: Send Milight request: {"color_mode":"rgb","state":"ON","brightness":255,"color":{"r":182,"g":182,"b":255}}
[15:45:28][D][mi.light:386]: Send Milight request: {"color_mode":"rgb","state":"ON","brightness":255,"color":{"r":54,"g":54,"b":255}}
[15:45:28][D][mi.light:386]: Send Milight request: {"color_mode":"rgb","state":"ON","brightness":255,"color":{"r":0,"g":0,"b":255}}
[15:45:28][D][mi.light:386]: Send Milight request: {"color_mode":"rgb","state":"ON","brightness":255,"color":{"r":0,"g":0,"b":255}}

Hello,

I recently learned about this project and I really like the idea of using esphome for my Home Assistant / Mi integration.
Up until now I am using sidoh's esp8266_milight_hub. Also a great project BTW...

However, while testing this ESPhome integration, it seems that it is not working correctly with fut089 remote's.
I can send commands towards lights from Home Assistant without issues, however commands from the remote itself do not make it into Home Assistant (the lights itself are triggered correctly off course).

Even more: when my ESPhome config only contains lights with fut089 as definition, debug mode does not show anything when pressing any button on the remote.
When I add a light with a remote_type: rgb_cct, that light is working correctly and the fut089 lights give something like this in debug mode when pressing on and off (on is making it into home assistant, off obviously not as it is detected wrong - it should be state: OFF).

As you can see: the packets are detected wrong: rgb_cct packet received (9 bytes)

[22:14:32][D][mi:067]: Received packet: 
rgb_cct packet received (9 bytes):
Raw packet: 84 54 73 A4 DA 45 79 DA 79 

Decoded:
Key      : 84
b1       : 25
ID       : 621D
Command  : 01
Argument : 01
Sequence : 5F
Group    : 01
Checksum : 32
[22:14:32][D][mi:128]: Received Milight request: {"state":"ON"}
[22:14:33][D][mi:067]: Received packet: 
rgb_cct packet received (9 bytes):
Raw packet: 40 98 3F D8 26 96 1A 26 5F 

Decoded:
Key      : 40
b1       : 25
ID       : 621D
Command  : 01
Argument : 0A
Sequence : 60
Group    : 01
Checksum : 88
[22:14:33][D][mi:128]: Received Milight request: {"command":"mode_speed_up"}

This is my (test) config:

substitutions:
  device_name: esphome-mi01
  friendly_name: esphome-mi01

esphome:
  name: $device_name
  friendly_name: $friendly_name

external_components:
  - source: github://hencou/esphome_components
    components: mi

esp8266:
  board: nodemcuv2

# Enable logging
logger:
  level: DEBUG

# Enable Home Assistant API
api:
  encryption:
    key: "<:)>"

ota:
  password: "<:)>"

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

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-Mi01 Fallback Hotspot"
    password: "<:)>"

captive_portal:

mi:
  id: mi1  #optional
  ce_pin: D2 #required, default: 4
  csn_pin: D8 #required, default: 15
  #reset_pin: 0 #optional, default: 0, only needed with LT8900 radio
  radio_interface_type: nrf24 #optional, default: nrf24, possible values: nrf24,lt8900
  packet_repeats: 50 #optional, default: 50, total of sended packets per command
  #listen_repeats: 3 #optional, default: 20, amount of received packets needed for a incoming command from other remote
  state_flush_interval: 5000 #optional, default: 10000, time in miliseconds to send the latest state report to HomeAssistant
  packet_repeat_throttle_threshold: 200 #optional, default: 200, threshold to limit the amount of packets in a second
  packet_repeat_throttle_sensitivity: 0 #optional, default: 0
  packet_repeat_minimum: 3 #optional, default: 3
  enable_automatic_mode_switching: false #optional, default: false
  rf24_power_level: MAX #optional, default: MAX, possible values: MIN, LOW, HIGH, MAX
  rf24_listen_channel: LOW #optional, default: LOW, possible values: LOW, MID, HIGH
  packet_repeats_per_loop: 10 #optional, default: 10, repeat packets sended per loop
  resend_last_command: true #optional, default: true, repeats the latest command after a random time between 2 and 3 seconds again
  rf24_channels: #optional, 1-3 values required when used, default: LOW-MID-HIGH, possible values: LOW, MID, HIGH
    - LOW
    - MID
    - HIGH
#  on_command_received: #optional, useful to send remote commands to HA and process them further there in automations
#    - homeassistant.event:
#        event: esphome.mi_command_received
#        data:
#          device_id: !lambda "return format_hex(data.device_id);"
#          group_id: !lambda "return data.group_id;"
#          remote_type: !lambda "return data.remote_type.c_str();"
#          command: !lambda "return data.command.c_str();"

light:
  - platform: mi
    id: light1
    name: testmi1
    device_id: 0x621D
    group_id: 1
    remote_type: fut089 
    default_transition_length: 0s

  - platform: mi
    id: light2
    name: testmi2
    device_id: 0x621D
    group_id: 2
    remote_type: fut089
    default_transition_length: 0s

  - platform: mi
    id: group1
    name: "Group1 test"
    device_id: 0x621D
    group_id: 0
    remote_type: fut089
    default_transition_length: 0s

  - platform: mi
    id: light3
    name: "testmi3"
    device_id: 0xC1A
    group_id: 1
    remote_type: rgb_cct
    default_transition_length: 0s

  - platform: mi
    id: light4
    name: "testmi4"
    device_id: 0xC1A
    group_id: 2
    remote_type: rgb_cct
    default_transition_length: 0s

  - platform: mi
    id: group2
    name: "Group2 test"
    device_id: 0xC1A
    group_id: 0
    remote_type: rgb_cct
    default_transition_length: 0s

Hello,

I have rgb_cct Wall switch ID:0x02CB and rgb_cct Remote Control ID:0x1F83. Both paired and manages same groups of Mi LED's.

Is it possible to configure like a "bridge" button, which can see ON/OFF if any of my Switch or remote control ON/OFF light???

Maybe another implementation? Like Syncing buttons... Just try to think... Any Ideas?

Ed

Hello,

when using Group 0 (all zones), when you turn it on, then setup brightness... turn it off and on again, brightness reset back to 0...

with other zones, 1, 2, 3 ,4 it's works as expected...

Ed

Hello! This problem has already been described previously, but I cant find it in issues.
CCT lamps turn on and off somewhat twitchy. RGBW works as should.
Here is the logs from console with turning on\off process of cct and rgbw.
I don’t understand where the commands to dim the brightness come from when turning the lamp on and off (CCT)

#CCT
00:06:05	[D]	[light:047]	State: ON
00:06:05	[D]	[mi:128]	Received Milight request: {"state":"ON"}
00:06:06	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}
00:06:06	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}
00:06:07	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}
00:06:07	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}
00:06:07	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}
00:06:07	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}
00:06:07	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}
00:06:08	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}
00:06:08	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}
00:06:08	[D]	[mi:128]	Received Milight request: {"command":"brightness_up"}


00:06:16	[D]	[light:036]	'Koridor_L4' Setting:
00:06:16	[D]	[light:047]	  State: OFF
00:06:17	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:17	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:17	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:17	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:17	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:18	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:18	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:18	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:18	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:19	[D]	[mi:128]	Received Milight request: {"command":"brightness_down"}
00:06:19	[D]	[mi:128]	Received Milight request: {"state":"OFF"}	

#RGBW

00:07:36	[D]	[light:047]	  State: ON
00:07:36	[D]	[mi:128]	Received Milight request: {"state":"ON"}
00:07:36	[D]	[mi:128]	Received Milight request: {"command":"set_white"}
00:07:37	[D]	[mi:128]	Received Milight request: {"brightness":255}

00:08:49	[D]	[light:036]	'Koridor_L8' Setting:
00:08:49	[D]	[light:047]	  State: OFF
00:08:49	[D]	[mi:128]	Received Milight request: {"brightness":0}
00:08:49	[D]	[mi:128]	Received Milight request: {"state":"OFF"}

Here is part of config for mi of esphome. WEB-server is enable (as far as I remember, a year ago the presence of this parameter caused a compilation error)

esphome:

   platformio_options:                     #optional, to set additional build flags
     build_flags:                          #optional, to set additional build flags
       - "-D USE_ESP32_ALTERNATE_SPI"      #optional, to use the alternate HSPI SPI bus instead of the default VSPI on an ESP32 board
       - "-D ALT_SPI_MISO_PIN=12"          #optional, if HSPI bus is used, alternate pins can also be defined
       - "-D ALT_SPI_MOSI_PIN=13"
       - "-D ALT_SPI_SCLK_PIN=14"
       - "-D ALT_SPI_SS_PIN=5"

external_components:
  - source: github://hencou/esphome_components
    components: mi


mi:
  
  id: mi1
  ce_pin: 4
  csn_pin: 5
  reset_pin: 0
  radio_interface_type: nrf24
  packet_repeats: 50
  listen_repeats: 20
  state_flush_interval: 5000
  packet_repeat_throttle_threshold: 200
  packet_repeat_throttle_sensitivity: 0
  packet_repeat_minimum: 3
  enable_automatic_mode_switching: false
  rf24_power_level: MAX
  rf24_listen_channel: LOW
  packet_repeats_per_loop: 10
  resend_last_command: false
  rf24_channels: #optional, 1-3 values required when used, default: LOW-MID-HIGH, possible values: LOW, MID, HIGH
    - LOW
    - MID
    - HIGH

light:
  - platform: mi
    id: Koridor_L4
    name: Koridor_L4
    device_id: 0x4
    group_id: 1
    remote_type: cct
    default_transition_length: 0s

  - platform: mi
    id: Koridor_L8
    name: Koridor_L8
    device_id: 0x8
    group_id: 2
    remote_type: rgbw
    default_transition_length: 0s

Thank you in advance

Very nice project!
Everything works great except when i choose a color with the colorwheel in HA. (bulb not changing colors, turns or stays white)

[22:08:58][D][light:035]: 'Test2' Setting:
[22:08:58][D][light:054]:   Color brightness: 8%
[22:08:58][D][light:057]:   Red: 25%, Green: 100%, Blue: 25%
[22:08:58][D][light:062]:   White: 7%
[22:08:58][D][light:084]:   Transition length: 0.2s
[22:08:58][D][mi.light:393]: Send Milight request: {"color_mode":"rgbw","state":"ON","brightness":71,"color":{"w":18},"white_value":18}
[22:08:58][D][mi.light:393]: Send Milight request: {"color_mode":"rgbw","state":"ON","brightness":71,"color":{"w":18},"white_value":18}
[22:08:58][D][mi.light:393]: Send Milight request: {"color_mode":"rgbw","state":"ON","brightness":71,"color":{"w":18},"white_value":18}
[22:08:58][D][mi.light:393]: Send Milight request: {"color_mode":"rgbw","state":"ON","brightness":71,"color":{"w":18},"white_value":18}
[22:08:58][D][mi.light:393]: Send Milight request: {"color_mode":"rgbw","state":"ON","brightness":71,"color":{"w":18},"white_value":18}

Maybe the Send Milight request syntax not complete?

I am currently using many milight bulbs for over 5 years. Initially I was using them with milight WiFi bridges integrating them into homebridge (and ultimately HomeKit) using the plugin - https://github.com/dotsam/homebridge-milight.

I later made custom milight hubs using https://github.com/sidoh/esp8266_milight_hub integrating them into homebridge using https://github.com/cflurin/homebridge-mqtt

I saw the implementation in esphome in this repo (I haven't ever used esphome till date but I have flashed tasmota ans used lots of devices) and found it interesting. I find the instructions to be elaborate but since I am not using home assistant (and I haven't used esphome too) I am at a loss to be able to implement this.

I am not sure if this is the right place to reach out for help with such fundamentals. But since I don't know of any other platform to reach out for this, I am trying here. If someone can help me implement this kindly let me know. As I am not a "techie" as such, I would be grateful to assign the project out on a freelance basis or anything else that works.

Hi, I just realized that there is an ESPHome version of MH - great work!

I already started to think about migrating, but I am looking for one specific option that I use in my current setup... can you check if it's possible to achieve with this code?

I have 2 types of lights @ home - RGBW and only White LED strips. I control all of them with RGB+CCT physical and MH remotes. When I expose these devices to HA, for White lights I only choose to expose on/off and brightness change functions, so when this device is passed further to HomeKit, I only have option to change brightness, and not color. This is how such device looks like in HA:

And here's the code of such light, with some parts disabled (only choose changing brightness and light effects):

light:
- name: "Bright @ Dinner Table [L]"
command_topic: milight/0x67B4/fut089/1
state_topic: milight/states/0x67B4/fut089/1
schema: json
qos: 1
optimistic: false
retain: true
color_temp: false
rgb: false
brightness: true
effect: true
effect_list: [night_mode]
availability_topic: milight/client_status
payload_available: 'connected'
payload_not_available: 'disconnected'

Is there any way to pick and choose functions like that in your project? It is great when you pass these devices to HomeKit - on my phone I don't have a color wheel for lights that are only white. And I retain compatibility with my physical remotes that I use to pair / unpair and control lights.

Have a feature request for you--I could probably clobber something together but my C++ is terrible.

Add a on_code_received trigger & callback to allow automations for remotes not bound to a bulb, similar to the RFBridge Component:

https://esphome.io/api/classesphome_1_1rf__bridge_1_1_r_f_bridge_received_code_trigger.html
https://esphome.io/api/classesphome_1_1rf__bridge_1_1_r_f_bridge_component.html#a8d44e0233fe8f3e405563d6ee5dbf849

Reason: this would allow for extra remotes to be used and events sent back to home assistant using ESPHome Automations.

For example (using RF Bridge as a reference):

mi:
  on_code_received:
    then:
      - homeassistant.event:
          event: esphome.milight_code_received
          data:
            key: !lambda 'return format_hex(data.key);'
            id: !lambda 'return format_hex(data.id);'
            command: !lambda 'return format_hex(data.command);'
            argument: !lambda 'return format_hex(data.argument);'
            group: !lambda 'return format_hex(data.group);'

After uploading/install the firmware the lights are flashing 2 times. Is this expected behavior? Is it possible to prevent this behavior?

Hi, I am trying to use your great mi component, but I only wanted the part with "on_command_received", so I stripped down the example yaml to this:

substitutions:
  device_name: mi-rf-remote-handler
  friendly_name: Mi RF Remote Handler

esphome:
  name: $device_name
  # platformio_options:                     #optional, to set additional build flags
  #   build_flags:                          #optional, to set additional build flags
  #     - "-D USE_ESP32_ALTERNATE_SPI"      #optional, to use the alternate HSPI SPI bus instead of the default VSPI on an ESP32 board
  #     - "-D ALT_SPI_MISO_PIN=15"          #optional, if HSPI bus is used, alternate pins can also be defined
  #     - "-D ALT_SPI_MOSI_PIN=14"
  #     - "-D ALT_SPI_SCLK_PIN=12"
  #     - "-D ALT_SPI_SS_PIN=4"

external_components:
  - source:
      type: local
      path: /components/hencou_esphome_components/components
    components: mi

esp8266:
  board: nodemcuv2

# Enable logging
logger:
  level: WARN

captive_portal:

mdns:

api:
  password: ""

ota:
  password: ""

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: true
  ap:
    ssid: $device_name
    password: !secret fallback_wifi_password

mi:
  id: mi1  #optional
  ce_pin: D2 #required, default: 4
  csn_pin: D8 #required, default: 15
  reset_pin: 0 #optional, default: 0, only needed with LT8900 radio
  radio_interface_type: nrf24 #optional, default: nrf24, possible values: nrf24,lt8900
  packet_repeats: 50 #optional, default: 50, total of sended packets per command
  listen_repeats: 20 #optional, default: 20, amount of received packets needed for a incoming command from other remote
  state_flush_interval: 5000 #optional, default: 10000, time in miliseconds to send the latest state report to HomeAssistant
  packet_repeat_throttle_threshold: 200 #optional, default: 200, threshold to limit the amount of packets in a second
  packet_repeat_throttle_sensitivity: 0 #optional, default: 0
  packet_repeat_minimum: 3 #optional, default: 3
  enable_automatic_mode_switching: false #optional, default: false
  rf24_power_level: MAX #optional, default: MAX, possible values: MIN, LOW, HIGH, MAX
  rf24_listen_channel: LOW #optional, default: LOW, possible values: LOW, MID, HIGH
  packet_repeats_per_loop: 10 #optional, default: 10, repeat packets sended per loop
  resend_last_command: true #optional, default: true, repeats the latest command after a random time between 2 and 3 seconds again
  rf24_channels: #optional, 1-3 values required when used, default: LOW-MID-HIGH, possible values: LOW, MID, HIGH
    - LOW
    - MID
    - HIGH
  on_command_received: #optional, useful to send remote commands to HA and process them further there in automations
    - homeassistant.event:
        event: esphome.mi_command_received
        data:
          device_id: !lambda "return format_hex(data.device_id);"
          group_id: !lambda "return data.group_id;"
          remote_type: !lambda "return data.remote_type.c_str();"
          command: !lambda "return data.command.c_str();"

Unfortunately this does not compile then, because:

In file included from src/esphome/components/mi/mi.cpp:1:
src/esphome/components/mi/mi.h:5:10: fatal error: esphome/components/light/light_state.h: No such file or directory
    5 | #include "esphome/components/light/light_state.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It seems the LightState package is not added automatically in such case, yet you still use it. I was trying to add an import line in init.py, but it still wasn't compiling...
Eventually I used the whole example yaml and this time it worked.

INFO Reading configuration /config/esphome/mi-test.yaml...
INFO Generating C++ source...
INFO Core config or version changed, cleaning build files...
INFO Compiling app...
Processing mitest1 (board: d1_mini; framework: arduino; platform: platformio/espressif8266 @ 2.6.3)

HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
Library Manager: Installing git+https://github.com/hencou/esphome-milight#main
git version 2.30.2
Cloning into '/data/cache/platformio/cache/tmp/pkg-installing-uvkecpyl'...
Library Manager: milight @ 0.0.2+sha.43e140a has been installed!
Library Manager: Installing dependencies...
Library Manager: Installing SPI @ *
Library Manager: Installing nrf24/RF24 @ *

Unpacking [------------------------------------] 0%
...
Unpacking [####################################] 100%
Library Manager: RF24 @ 1.4.2 has been installed!
Library Manager: Installing PathVariableHandlers @ *

Unpacking [------------------------------------] 0%
...
Unpacking [####################################] 100%
Library Manager: PathVariableHandlers @ 2.0.0 has been installed!
Library Manager: Installing ListLib @ *

Unpacking [------------------------------------] 0%
...
Unpacking [####################################] 100%
Library Manager: ListLib @ 1.0.0 has been installed!
Library Manager: Installing bblanchon/ArduinoJson @ *

Unpacking [------------------------------------] 0%
...
Unpacking [####################################] 100%
Library Manager: ArduinoJson @ 6.19.0 has been installed!
Library Manager: RF24 @ 1.4.2 is already installed
Library Manager: PathVariableHandlers @ 2.0.0 is already installed
Library Manager: Installing git+https://github.com/luisllamasbinaburo/Arduino-List
git version 2.30.2
Cloning into '/data/cache/platformio/cache/tmp/pkg-installing-tppzaa4w'...
Library Manager: ListLib @ 1.0.0+sha.a250c6e has been installed!
Library Manager: ArduinoJson @ 6.19.0 is already installed
Dependency Graph
|-- 0.0.2+sha.43e140a
| |-- 1.0
| |-- 1.4.2
| |-- 2.0.0
| |-- 1.0.0
| |-- 6.19.0
|-- 1.0
|-- 1.0
|-- 1.4.2
|-- 2.0.0
|-- 1.0.0+sha.a250c6e
|-- 6.19.0
|-- 1.2
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/api_connection.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/api_frame_helper.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/api_pb2.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/api_pb2_service.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/api_server.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/list_entities.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/proto.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/subscribe_state.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/user_services.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/api/util.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/binary_sensor/automation.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/binary_sensor/binary_sensor.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/binary_sensor/filter.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/button/button.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/esp8266/core.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/esp8266/gpio.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/esp8266/preferences.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/gpio/binary_sensor/gpio_binary_sensor.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/light/addressable_light.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/light/automation.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/light/esp_color_correction.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/light/esp_hsv_color.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/light/esp_range_view.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/light/light_call.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/light/light_json_schema.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/light/light_output.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/light/light_state.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/logger/logger.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/md5/md5.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/mdns/mdns_component.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/mdns/mdns_esp32_arduino.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/mdns/mdns_esp8266.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/mdns/mdns_esp_idf.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/mi/button/mi_button.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/mi/light/mi_light.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/mi/mi.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/network/util.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/ota/ota_backend_arduino_esp32.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/ota/ota_backend_arduino_esp8266.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/ota/ota_backend_esp_idf.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/ota/ota_component.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/socket/bsd_sockets_impl.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/socket/lwip_raw_tcp_impl.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/wifi/wifi_component.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/wifi/wifi_component_esp32_arduino.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/wifi/wifi_component_esp8266.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/components/wifi/wifi_component_esp_idf.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/core/application.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/core/color.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/core/component.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/core/controller.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/core/entity_base.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/core/helpers.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/core/log.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/core/scheduler.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/esphome/core/util.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/src/main.cpp.o
Generating LD script /data/mitest1/.pioenvs/mitest1/ld/local.eagle.app.v6.common.ld
Compiling /data/mitest1/.pioenvs/mitest1/libf5a/SPI/SPI.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/lib1cc/RF24/RF24.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/libdb9/PathVariableHandlers/TokenIterator.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/libdb9/PathVariableHandlers/UrlTokenBindings.cpp.o
Archiving /data/mitest1/.pioenvs/mitest1/libdb9/libPathVariableHandlers.a
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/CctPacketFormatter.cpp.o
Archiving /data/mitest1/.pioenvs/mitest1/libf5a/libSPI.a
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/FUT020PacketFormatter.cpp.o
Archiving /data/mitest1/.pioenvs/mitest1/lib1cc/libRF24.a
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/FUT02xPacketFormatter.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/FUT089PacketFormatter.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/FUT091PacketFormatter.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/MiLightClient.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/MiLightRemoteConfig.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/PacketFormatter.cpp.o
/data/mitest1/.piolibdeps/mitest1/milight/src/milight/MiLight/MiLightClient.cpp: In member function 'void MiLightClient::update(ArduinoJson::JsonObject)':
/data/mitest1/.piolibdeps/mitest1/milight/src/milight/MiLight/MiLightClient.cpp:350:48: error: 'ArduinoJson::JsonVariant' has no member named 'isUndefined'
const bool isBrightnessDefined = !brightness.isUndefined() || !level.isUndefined();
^
/data/mitest1/.piolibdeps/mitest1/milight/src/milight/MiLight/MiLightClient.cpp:350:72: error: 'ArduinoJson::JsonVariant' has no member named 'isUndefined'
const bool isBrightnessDefined = !brightness.isUndefined() || !level.isUndefined();
^
/data/mitest1/.piolibdeps/mitest1/milight/src/milight/MiLight/MiLightClient.cpp: In member function 'uint8_t MiLightClient::parseStatus(ArduinoJson::JsonVariant)':
/data/mitest1/.piolibdeps/mitest1/milight/src/milight/MiLight/MiLightClient.cpp:457:11: error: 'ArduinoJson::JsonVariant' has no member named 'isUndefined'
if (val.isUndefined()) {
^
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/PacketQueue.cpp.o
Compiling /data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/PacketSender.cpp.o
*** [/data/mitest1/.pioenvs/mitest1/liba94/milight/milight/MiLight/MiLightClient.cpp.o] Error 1
========================= [FAILED] Took 26.87 seconds =========================

I'm trying to get this working on a new bridge prototype using a WT32-ETH01 board which is an ESP32 board with Ethernet. My problem is I need to get the NRF24 module to use alternate pins and an alternate SPI bus (hspi bus), as the normal VSPI default is not available due to the ethernet module and exposed pinout.

The NRF24 module allows the use of an alternate SPI bus, but I'm having trouble translating the C++ code to figure out where I would add the changes. Also, ESPHome allows the definition of an SPI bus, and I was wondering how hard it would be to configure the mi component to use an SPI bus defined elsewhere in ESPHome.

NRF24 Module Alternate SPI Bus (near bottom of page): https://nrf24.github.io/RF24/md_docs_arduino.html
Overloaded Radio->begin method: https://nrf24.github.io/RF24/classRF24.html#a388fa99b0400ce0cd887f742ef53192b
ESPHome Custom SPI Component: https://esphome.io/custom/spi.html
ESPHome SPI Bus: https://esphome.io/components/spi.html

Desired Pinout:

#define MY_CE 2
#define MY_MISO 15
#define MY_MOSI 14
#define MY_SCLK 12
#define MY_SS   4

Any help would be greatly appreciated.

The current ESPHome component supports the execution of some commands using either a switch or a button.

This can relatively easily be exposed as a service to be used in HA, e.g. something akin to:

    - service: mi_command
      variables:
        device_id: int
        group_id: int
        type: string
        command: string
      then:
        - lambda: |-
            const BulbId bulbId = {
              device_id,
              group_id,
              MiLightRemoteTypeHelpers::remoteTypeFromString(type.c_str())
            };
            id(mi_component).handleCommand(bulbId, command.c_str());

However, this is not expansive enough to allow the command from Mi events captured from some device using the on_command_received to then be straight up forwarded as-is to some other device/group/type.

If possible it'd be awesome to have a service available (or just a public C++ function that could then be called/used akin to the above) that can take any Mi JSON command string for a given device+type+group and (if relevant for a given light) update the state and send out the message for the light to change to that state.
This would allow something like https://github.com/sidoh/esp8266_milight_hub/wiki/Using-Milight-Remote-with-HomeAssistant#configure-hass to be realized.

Failing to compile with latest changes.

I tried wiping the build folder and cleaning build files to make sure it wasn't a caching issue.

ESPHome v2022.5.0

src/esphome/components/mi/light/mi_light.cpp: In member function 'virtual void esphome::mi::MiLight::setup_state(esphome::light::LightState*)':
src/esphome/components/mi/light/mi_light.cpp:93:61: error: 'to_string' is not a member of 'std'
           state_->add_effects({new light::LambdaLightEffect(std::to_string(i), [=](bool initial_run) -> void {
                                                             ^
src/esphome/components/mi/light/mi_light.cpp:93:61: note: suggested alternative:
In file included from src/esphome/core/preferences.h:6:0,
                 from src/esphome/core/application.h:6,
                 from src/esphome/components/api/api_connection.h:4,
                 from src/esphome.h:3,
                 from src/esphome/components/mi/light/mi_light.cpp:1:
src/esphome/core/helpers.h:256:20: note:   'esphome::to_string'
 inline std::string to_string(const std::string &val) { return val; }
                    ^
src/esphome/components/mi/light/mi_light.cpp:98:12: error: no matching function for call to 'esphome::light::LightState::add_effects(<brace-enclosed initializer list>)'
           });
            ^
In file included from src/esphome/core/application.h:34:0,
                 from src/esphome/components/api/api_connection.h:4,
                 from src/esphome.h:3,
                 from src/esphome/components/mi/light/mi_light.cpp:1:
src/esphome/components/light/light_state.h:127:8: note: candidate: void esphome::light::LightState::add_effects(const std::vector<esphome::light::LightEffect*>&)
   void add_effects(const std::vector<LightEffect *> &effects);
        ^
src/esphome/components/light/light_state.h:127:8: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'const std::vector<esphome::light::LightEffect*>&'
Compiling /data/esp32-milight-bridge/.pioenvs/esp32-milight-bridge/src/esphome/components/restart/button/restart_button.cpp.o
*** [/data/esp32-milight-bridge/.pioenvs/esp32-milight-bridge/src/esphome/components/mi/light/mi_light.cpp.o] Error 1
========================= [FAILED] Took 22.35 seconds =========================

Hello,

is it possible to read signal from remote control? my assumption it should be possible with:
on_command_received:
- homeassistant.event:
event: esphome.mi_command_received
data:
device_id: !lambda "return format_hex(data.device_id);"
group_id: !lambda "return data.group_id;"
remote_type: !lambda "return data.remote_type.c_str();"
command: !lambda "return data.command.c_str();"

but it's not working. Maybe I'ts my mistake.

Wanted to recommend that you split the milight folder into a separate repository and structure it like a PlatformIO library.

Reason: this allows you to include the library from GitHub in your ESPHome config instead of needing to copy it to the directory manually and update it every time changes are made to the repo.

I've already created a test repo and tested this method using the following snippet:

esphome:
  name: $device_name
  platform: ESP8266
  board: d1_mini
  libraries:
    - milight=https://github.com/shbatm/esphome-milight#main

The only issue I found was that I had to directly incorporate the color conversion functions instead of referencing the esphome.h functions -- the way PlatformIO compiles the library, using this as is would mean adding the full esphome library as a dependency for only these two functions.

I made the repo for the library here: https://github.com/shbatm/esphome-milight; I'd be happy to transfer ownership to you if you want to use this method.

Thanks again for all the work!

Hi, I have this nice little remote RGBCCT and it seems it almost works with your mi component (rgb_cct remote type).

Out of 4 physical buttons I get response on 3 of them (see the pictures):

• ON - seems to match, I get:

[17:26:54][D][mi:067]: Received packet: 
rgb_cct packet received (9 bytes):
Raw packet: 1C BC F1 F5 02 6D CC 02 37 

Decoded:
Key      : 1C
b1       : 25
ID       : 94DA
Command  : 01
Argument : 01
Sequence : 9A
Group    : 01
Checksum : 84
[17:26:54][VV][api.service:184]: send_homeassistant_service_response: HomeassistantServiceResponse {
  service: 'esphome.mi_command_received'
  data: HomeassistantServiceMap {
  key: 'device_id'
  value: '94da'
}
  data: HomeassistantServiceMap {
  key: 'group_id'
  value: '1'
}
  data: HomeassistantServiceMap {
  key: 'remote_type'
  value: 'rgb_cct'
}
  data: HomeassistantServiceMap {
  key: 'command'
  value: '{"state":"ON"}'
}
  is_event: YES
}

• OFF - not a match (different command), but keypress is decoded:

[17:28:38][D][mi:067]: Received packet: 
rgb_cct packet received (9 bytes):
Raw packet: F4 E4 59 CD 6A CA 25 6A AD 

Decoded:
Key      : F4
b1       : 25
ID       : 94DA
Command  : 01
Argument : 0A
Sequence : 9B
Group    : 01
Checksum : F6
[17:28:38][VV][api.service:184]: send_homeassistant_service_response: HomeassistantServiceResponse {
  service: 'esphome.mi_command_received'
  data: HomeassistantServiceMap {
  key: 'device_id'
  value: '94da'
}
  data: HomeassistantServiceMap {
  key: 'group_id'
  value: '1'
}
  data: HomeassistantServiceMap {
  key: 'remote_type'
  value: 'rgb_cct'
}
  data: HomeassistantServiceMap {
  key: 'command'
  value: '{"command":"mode_speed_up"}'
}
  is_event: YES
}

• Color icon button - not a match (different command), but keypress is decoded. Also the group id is different then with the rest:

[17:33:13][D][mi:067]: Received packet: 
rgb_cct packet received (9 bytes):
Raw packet: C1 F1 2C 8C F9 C5 42 FA DB 

Decoded:
Key      : C1
b1       : 25
ID       : 94DA
Command  : 01
Argument : 14
Sequence : 9D
Group    : 01
Checksum : 3F
[17:33:13][VV][api.service:184]: send_homeassistant_service_response: HomeassistantServiceResponse {
  service: 'esphome.mi_command_received'
  data: HomeassistantServiceMap {
  key: 'device_id'
  value: '94da'
}
  data: HomeassistantServiceMap {
  key: 'group_id'
  value: '15'
}
  data: HomeassistantServiceMap {
  key: 'remote_type'
  value: 'rgb_cct'
}
  data: HomeassistantServiceMap {
  key: 'command'
  value: '{"state":"OFF"}'
}
  is_event: YES
}

• Brightness(?) button - no reaction, no keypress decoded (there is even no "Received packet" log).

There is also a touch wheel that seems to be correctly decoded, giving value "mode" in range 0-100:

[17:36:20][D][mi:067]: Received packet: 
rgb_cct packet received (9 bytes):
Raw packet: 24 B4 09 FD FE 36 D8 FA F4 

Decoded:
Key      : 24
b1       : 25
ID       : 94DA
Command  : 05
Argument : 56
Sequence : 9E
Group    : 01
Checksum : D9
[17:36:20][VV][api.service:184]: send_homeassistant_service_response: HomeassistantServiceResponse {
  service: 'esphome.mi_command_received'
  data: HomeassistantServiceMap {
  key: 'device_id'
  value: '94da'
}
  data: HomeassistantServiceMap {
  key: 'group_id'
  value: '1'
}
  data: HomeassistantServiceMap {
  key: 'remote_type'
  value: 'rgb_cct'
}
  data: HomeassistantServiceMap {
  key: 'command'
  value: '{"mode":86}'
}
  is_event: YES
}

I will try using all possible remote types and see if any of them gives better result.

is this code ready/doable for a ESP32?

Since the latest updates of ESPHome i have some trouble with updating and/or compiling the Milight component.

This is the errorcode:
Compiling .pioenvs/esphome-web-56b5a8/src/esphome/components/mi/MiLightRadioConfig.cpp.o src/esphome/components/mi/GroupAlias.cpp: In static member function 'static void GroupAlias::saveAliases(Stream&, const std::map<String, GroupAlias>&)': src/esphome/components/mi/GroupAlias.cpp:56:17: error: call of overloaded 'write(int)' is ambiguous stream.write(0); ^ In file included from /data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/Stream.h:26, from src/esphome/components/mi/GroupAlias.h:1, from src/esphome/components/mi/GroupAlias.cpp:1: /data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/Print.h:61:20: note: candidate: 'virtual size_t Print::write(uint8_t)' virtual size_t write(uint8_t) = 0; ^~~~~ /data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/Print.h:62:12: note: candidate: 'size_t Print::write(const char*)' size_t write(const char *str) ^~~~~ *** [.pioenvs/esphome-web-56b5a8/src/esphome/components/mi/GroupAlias.cpp.o] Error 1 ========================= [FAILED] Took 20.18 seconds ========================= ===== [ERROR] /config/esphome/esphome-web-56b5a8.yaml =====

I've nothing changed in the yaml file and settings. Can anyone help me out with this?