sidoh / esp8266_milight_hub

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

MQTT configuration is turning off all the lamps #251

Closed EdgardosReis closed 6 years ago

EdgardosReis commented 6 years ago

Hello! First of all thanks for this awesome project.

So, about my issue, I really don't know where this problem came from. Actually I think that is not an issue with this project but I cannot explain either...

I've this 3 groups for now: Desk lamp model FUT015 (8W RGB+CCT) : 0x1112/rgb_cct/4

Living Room Back a bunch of FUT103 (4W GU10 RGB+CCT):
0x1112/rgb_cct/2

Bedroom Ceiling FUT105 (12W RGB+CCT): 0x1131/fut089/1

I've this configured in Home Assistant as MQTT lights and an Automation to forward the commands from milight remote to update HASS states. Something identical of the configurations described in the guides of this project.

My HASS lights configuration:

light: 
  - name: "Bedroom Ceiling"
    command_topic: milight/commands/0x1131/fut089/1
    state_topic: milight/states/0x1131/fut089/1
    <<: &MILIGHT_PARAMS
      platform: mqtt_json
      color_temp: true
      rgb: true
      brightness: true
      optimistic: false
  - name: "Living Room Back"
    command_topic: milight/commands/0x1112/rgb_cct/2
    state_topic: milight/states/0x1112/rgb_cct/2
    <<: *MILIGHT_PARAMS
  - name: "Desk"
    command_topic: milight/commands/0x1112/rgb_cct/4
    state_topic: milight/states/0x1112/rgb_cct/4
    <<: *MILIGHT_PARAMS

and forward automation:

- alias: MiLight Forwarder
  trigger:
    platform: mqtt
    topic: "milight/updates/0xD86/rgb_cct/+"
  action:
    - service: mqtt.publish
      data_template:
        topic: "milight/commands/0x1112/rgb_cct/{{ trigger.topic.split('/')[4] }}"
        payload_template: >
          {{ trigger.payload }}

Everything is working fine except for the weird behavior of the Desk lamp. when i have this 3 groups turned on and I switch Desk lamp off from the Milight remote or from HASS front end, all the other 2 groups turn off also.

This is the mqtt topics published when I turn off this lamp:

milight/updates/0xD86/rgb_cct/4
milight/commands/0x1112/rgb_cct/4
milight/states/0xD86/rgb_cct/4
milight/updates/0x1112/rgb_cct/4
milight/states/0x1112/rgb_cct/4
milight/commands/0x1112/rgb_cct/4
milight/commands/0x1131/fut089/1
milight/commands/0x1112/rgb_cct/2
milight/updates/0x1112/rgb_cct/4
milight/updates/0x1131/fut089/1
milight/updates/0x1112/rgb_cct/2
milight/states/0x1131/fut089/1
milight/states/0x1112/rgb_cct/2

0xD86 is the deviceId from my milight remote and makes no sense for me the topics from line 6 to the end. It seems that something is triggering the "commands" topic of all the configured HASS ligths.

Any idea of what's happening?

sidoh commented 6 years ago

I cannot think of a reason that either HASS or espMH would behave this way.

Are you able to turn some debug logging on for your MQTT broker? Would be helpful to see what's sending the messages.

EdgardosReis commented 6 years ago

mosquitto.log So, the last lines in the file are the turn off desk lamp from milight remote: Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/updates/0xD86/rgb_cct/4', ... (15 bytes)) milight/updates/0xD86/rgb_cct/4 {"state":"OFF"} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/states/0xD86/rgb_cct/4', ... (103 bytes)) milight/states/0xD86/rgb_cct/4 {"state":"OFF","brightness":255,"color_temp":370,"bulb_mode":"white","color":{"r":255,"g":255,"b":255}} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/commands/0x1112/rgb_cct/4', ... (15 bytes)) milight/commands/0x1112/rgb_cct/4 {"state":"OFF"} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/updates/0x1112/rgb_cct/4', ... (15 bytes)) milight/updates/0x1112/rgb_cct/4 {"state":"OFF"} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/states/0x1112/rgb_cct/4', ... (103 bytes)) milight/states/0x1112/rgb_cct/4 {"state":"OFF","brightness":255,"color_temp":370,"bulb_mode":"white","color":{"r":255,"g":255,"b":255}} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/commands/0x1112/rgb_cct/2', ... (16 bytes)) milight/commands/0x1112/rgb_cct/2 {"state": "OFF"} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/commands/0x1112/rgb_cct/4', ... (16 bytes)) milight/commands/0x1112/rgb_cct/4 {"state": "OFF"} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/commands/0x1131/fut089/1', ... (16 bytes)) milight/commands/0x1131/fut089/1 {"state": "OFF"} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/updates/0x1112/rgb_cct/2', ... (15 bytes)) milight/updates/0x1112/rgb_cct/2 {"state":"OFF"} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/updates/0x1112/rgb_cct/4', ... (15 bytes)) milight/updates/0x1112/rgb_cct/4 {"state":"OFF"} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/updates/0x1131/fut089/1', ... (15 bytes)) milight/updates/0x1131/fut089/1 {"state":"OFF"} Client mosqsub|17504-core-ssh received PUBLISH (d0, q0, r0, m0, 'milight/states/0x1112/rgb_cct/2', ... (102 bytes)) milight/states/0x1112/rgb_cct/2 {"state":"OFF","brightness":92,"color_temp":368,"bulb_mode":"white","color":{"r":255,"g":255,"b":255}}

But nothing new here probably, please tell me if this isn't what you need. home-assistant.log this is the log of home assistant after restart with debug severity for mqtt component. (I turned on bedroom and living room lights to do the test)

if I remember correctly, there are lamps that repeat the transmitted signal to increase the range, but I'm not finding nothing about that now and if all that they do is repeat the signal, there would be no reason for this to happen I guess.

rjsachse commented 6 years ago

Seems very weird. The only this i can think of to help find where the issue is coming from is to subcribe milight/updates/0x1131/fut098/1 & press a button on the remote to see if espMH has been told to turn on bulb.

I had it setup like you before and worked but now i just made a simple python script that reads the remote and then i can assign any light to it. I have 3 milights 1 yeelight 1 aiThinker bulb all controllable from the milight remote.

Is there a reason you can't just pair the remote to the globes? I only used the remote forwarder auotmation to controll other non milights.

Does it make any difference if you remove " " from the trigger topic?

EdgardosReis commented 6 years ago

Sorry for the late response, I just managed to sit in front of the computer now. When I turn on the Desk lamp, the behavior is normal, that is, the topics are as expected. the topics that I previously posted are all the topics subcribed to milight/#.

I've the remote paired to the bulbs but I wanted to update the state of the bulbs in home assistant. I need it to some automations where I have to know if the bulb is turn on or off.

I tried some no sense and desperate things like many deviceId variations, changing the order of the lamps in HASS lights configuration but obviously didn't work. If I put in the automation hardcoded the zone number of the Living Room lamps (zone 2) as expected it only updates in hass the state of that zone, If I put Desk lamp (zone 4) it starts the behavior. As soon as I disable the automation, turning on or off Desk lamp from the remote or HASS don't affect the other lamps.

removing the " " didn't solve. Same behavior.

Thank you for the replies. If you or anyone have any idea or if you want me to do any test please tell me because my knowledge of the mqtt protocol or home assistant is very limited and I'm out of ideas.

EdgardosReis commented 6 years ago

I found the source of the problem, nothig related with the ESP or the lamp itself. It still doesn't make sense for me but at least I'm not stuck. Well, this bulb had a simple and straightforward automation: Turn this specific bulb at a specific time. As soon as I disabled this automation no more weird behavior (after some random and nonsense tests I've done, didn't remember to test this... damn). Next step, find the correction to the automation.

Thank you sidoh and rjsachse for the replies

rjsachse commented 6 years ago

Thanks for the update, hope it all works in the end for you.

You can close this issue now.

sidoh commented 6 years ago

Glad you got it working, @EdgardosReis!

Thanks @rjsachse :)