wierd behavior, when receiving remote commands

theyo-tester commented 9 months ago

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

hencou commented 9 months ago

Hi,

I expect this is the same issue as this one: https://github.com/hencou/esphome_components/issues/22 The command is not always correctly parsed, but corrected in code later on.

WHat you can do: test with the "on_command_received" part in yaml as shown in the example: https://github.com/hencou/esphome_components/blob/main/example_milight.yaml Does this shows you the right commands in HomeAssistant events?

theyo-tester commented 9 months ago

Thank you for the response, hencou. In HomeAssistant I see the same wrong events. In fact this how the issue popped out, because I triggered with those events in the automation and they were night mode commands instead of "brightness up", for instance.

EDIT: I also removed or changed all light entries in the yaml file from fut091 to cct, to have only one type of remote inside and did not exceed 4 entries. I receive now the packages more reliable (less commands get lost), but still, the issue persists; As soon as I long press ANY button, the esph module interprets it as "Received Milight request: {"command":"night_mode"}"

hencou / esphome_components

wierd behavior, when receiving remote commands #33