sidoh / esp8266_milight_hub

Replacement for a Milight/LimitlessLED hub hosted on an ESP8266
MIT License
935 stars 220 forks source link

LED Strip RGBW controller command problems #596

Open fermentfan opened 4 years ago

fermentfan commented 4 years ago

Describe the bug

When sending an already turned on milight RGBW light strip controller (currently in RGB mode) the following payload, to change the color:

{"state":"ON","level":100,"hue":245,"saturation":90}

The light strip will only update its brightness level & sporadically switch to white color if repeated

The same payload works with RGBW bulbs. The culprit I found is the state parameter. If I leave it out it changes the color:

{"level":100,"hue":245,"saturation":90}

Steps to reproduce

Just send the payload to a Milight RGBW light strip controller

Expected behavior

Just for the color to change

Setup information

Firmware version

1.9.2 & 1.10.5 tested

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

{
  "firmware": "milight-hub",
  "version": "1.10.5",
  "ip_address": "192.168.0.248",
  "reset_reason": "Software/System restart",
  "variant": "nodemcuv2",
  "free_heap": 16632,
  "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": 8,
    "http_repeat_factor": 20,
    "auto_restart_period": 0,
    "mqtt_server": "xxx",
    "mqtt_username": "xxx",
    "mqtt_password": "xxx",
    "mqtt_topic_pattern": "milight/commands/:device_id/:device_type/:group_id",
    "mqtt_update_topic_pattern": "",
    "mqtt_state_topic_pattern": "milight/states/:device_id/:device_type/:group_id",
    "mqtt_client_status_topic": "",
    "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": "Off",
    "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":
    [
        23418,
        41605,
        41908,
        51050
    ],
    "gateway_configs": [],
    "group_state_fields":
    [
        "state",
        "level",
        "hue",
        "saturation",
        "mode",
        "color_temp",
        "bulb_mode"
    ],
    "group_id_aliases": {}
}
sidoh commented 4 years ago

Hi @DennisVonDerBey,

Thanks for the detailed bug report!

Sounds like the issue is the LED controller behaves strangely when the "on" and "color" commands are sent in rapid succession. Am I understanding correctly? A quick way to confirm would be to enable the mqtt_update_topic_pattern setting and inspect the log of commands sent.

If this is the case, it's going to be a bit tricky to solve without introducing issues elsewhere. It's dangerous to ignore the state command. If we're told to turn the bulb on, we should always make an attempt to turn it on. Even if the internal state suggests the bulb should be off, state could be out of sync.