esp8266_milight_hub icon indicating copy to clipboard operation
esp8266_milight_hub copied to clipboard

since 1.10.6 repeated presses on the same remote button are no longer send to MQTT

Open wertzui opened this issue 3 years ago • 6 comments

Describe the bug

1.10.6 introduced the MQQT debounce delay. With 1.10.5, repeated presses of the same remote button would be send to the MQTT state topic. Since 1.10.6 the state topic is not send again, but only the update topic is sent. THis breaks the workflow described below.

Steps to reproduce

  1. Turn on the light through the remote
  2. Turn off the lights through the openHAB, using the Web Interface or the Amazon Echo
  3. Wait at least the milliseconds defined in the config (500ms default)
  4. Turn on the lights again
  5. Nothing happens, because the openHAB binding relies on the state topic which is not updated (only the update topic is updated)

Expected behavior

state topic is updated and light will turn on

Setup information

  • Milight Remote (T1-4 or B1-4, any will work)
  • MQTT Broker (Mosquitto)
  • OpenHAB
  • Any light which is not directly controlled through the remote, but goes the route remote => MQTT => openHab => light (e.g. Hue, ArtNet, ...)
  • Amazon Echo (optional)

Firmware version

1.10.6 and 1.10.7 show this bug 1.10.5 is the last version which does not have this bug

Output of http://milight-hub.local/about

{
  "firmware": "milight-hub",
  "version": "1.10.5",
  "ip_address": "192.168.0.86",
  "reset_reason": "Software/System restart",
  "variant": "nodemcuv2",
  "free_heap": 18024,
  "arduino_version": "2_4_2",
  "queue_stats": {
    "length": 0,
    "dropped_packets": 0
  }
}

Output of http://milight-hub.local/settings

{
  "admin_username": "",
  "admin_password": "",
  "ce_pin": 16,
  "csn_pin": 15,
  "reset_pin": 0,
  "led_pin": -2,
  "radio_interface_type": "nRF24",
  "packet_repeats": 50,
  "http_repeat_factor": 1,
  "auto_restart_period": 0,
  "mqtt_server": "192.168.0.69",
  "mqtt_username": "",
  "mqtt_password": "",
  "mqtt_topic_pattern": "milight/commands/:device_id/:device_type/:group_id",
  "mqtt_update_topic_pattern": "milight/updates/:device_id/:device_type/:group_id",
  "mqtt_state_topic_pattern": "milight/states/:device_id/:device_type/:group_id",
  "mqtt_client_status_topic": "milight/status",
  "simple_mqtt_client_status": false,
  "discovery_port": 48899,
  "listen_repeats": 3,
  "state_flush_interval": 10000,
  "mqtt_state_rate_limit": 500,
  "packet_repeat_throttle_sensitivity": 0,
  "packet_repeat_throttle_threshold": 200,
  "packet_repeat_minimum": 3,
  "enable_automatic_mode_switching": false,
  "led_mode_wifi_config": "Fast toggle",
  "led_mode_wifi_failed": "On",
  "led_mode_operating": "Off",
  "led_mode_packet": "Flicker",
  "led_mode_packet_count": 3,
  "hostname": "milight-hub",
  "rf24_power_level": "MAX",
  "rf24_listen_channel": "LOW",
  "wifi_static_ip": "",
  "wifi_static_ip_gateway": "",
  "wifi_static_ip_netmask": "",
  "packet_repeats_per_loop": 10,
  "home_assistant_discovery_prefix": "",
  "wifi_mode": "n",
  "default_transition_period": 500,
  "rf24_channels": [
    "LOW",
    "MID",
    "HIGH"
  ],
  "device_ids": [
    26734,
    27036,
    30757
  ],
  "gateway_configs": [
    
  ],
  "group_state_fields": [
    "state",
    "level",
    "hue",
    "saturation",
    "mode",
    "color_temp",
    "bulb_mode"
  ],
  "group_id_aliases": {
    
  }
}

Additional context

wertzui avatar May 10 '21 09:05 wertzui

version 1.10.6 I have IOBroker with build-in (plugin) MQTT, both state and update are set when changes happen. MQTT for MiLight hub is only used for timer commands (On/Off), as IOBroker has a Pluin for MiLight hub. But I tried out this issue anyway.. turn off: state = {"state":"OFF","brightness":110,"bulb_mode":"color","color":{"r":255,"g":66,"b":69},"device_type":"rgb_cct"} update = {"state":"OFF"}

turn on: state = {"state":"ON","brightness":110,"bulb_mode":"color","color":{"r":255,"g":66,"b":69},"device_type":"rgb_cct"} update = {"state":"ON"}

change brightness: state = {"state":"ON","brightness":125,"bulb_mode":"color","color":{"r":255,"g":66,"b":69},"device_type":"rgb_cct"} update = {"state":"ON"} -> expected {"brightness":125} It is updated, but to {"state":"ON"}, not to brightness

If all you need is "state" (or command), on my system it works OK.

Linkenelis avatar May 20 '21 18:05 Linkenelis

Are you sending the commands from IOBroker through MQTT to a MiLight Bulb, or sending the commands from a MiLight Remote through MQTT to IOBroker?

My Problem is the second one here, as a tap on the MiLight remote does not result in the MQTT state topic for that remote button getting updated. If it is ObenHAB, IOBroker or anything else reading the MQTT topic does not matter, as there is no update send from the MiLight Hub to the MQTT topic.

wertzui avatar May 20 '21 19:05 wertzui

From IOBroker using UDP to Milight-hub, then reading MQTT. but still not the same :-) I wil try the T4...

Linkenelis avatar May 20 '21 19:05 Linkenelis

Hmmm. I have 2 devices in MiLighthub device 0x1 and 0x2. The wallswitch (a T4) reports on 0x2227 state and update in the same manner as the MiLight-hub

mqtt.0 -> milight -> state (update and command are also this level) -> 0x01, 0x02 and 0x2227 below each -> group ID 1 to 4 + All

This is happening... in settings: milight/state/:device_id/:group_id in mqtt: milight/:device_id/state/:group_id

Linkenelis avatar May 20 '21 20:05 Linkenelis

Oh same for update..

Linkenelis avatar May 20 '21 20:05 Linkenelis

Oops sorry! got things mixed up...

I tried group 1 on the T4 (device_id = 0x2227

I put a screenshot, so there can be no mistakes 2021-05-21 103353

Linkenelis avatar May 21 '21 08:05 Linkenelis