search

sidoh / esp8266_milight_hub

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

Update states are not sent in the same way when the device is on/off #716

Closed golddragon007 closed 3 years ago

golddragon007 commented 3 years ago

Describe the bug

One of the two messages is missing (from the update MQTT channel) between the on and off state: saturation or color_temp. Device: FUT089 remote panel.

Steps to reproduce

  1. Press off
  2. touch color wheel
  3. touch left slider -> saturation received
  4. touch W
  5. touch left slider -> saturation received It can happen depending on the off state that in both cases the color_temp will be received.

Expected behavior

  1. Press on
  2. touch color wheel
  3. touch left slider -> saturation received
  4. touch W
  5. touch left slider -> color_temp received

Setup information

Firmware version

1.10.7

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

{
"firmware": "milight-hub",
"version": "1.10.7",
"ip_address": "",
"reset_reason": "External System",
"variant": "nodemcuv2",
"free_heap": 16048,
"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": 4,
"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": "",
"mqtt_username": "",
"mqtt_password": "",
"mqtt_topic_pattern": "milight/: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": "stat/milight",
"simple_mqtt_client_status": false,
"discovery_port": 48899,
"listen_repeats": 3,
"state_flush_interval": 10000,
"mqtt_state_rate_limit": 500,
"mqtt_debounce_delay": 500,
"mqtt_retain": false,
"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": "Slow blip",
"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": "homeassistant",
"wifi_mode": "n",
"default_transition_period": 500,
"rf24_channels": [
"LOW",
"MID",
"HIGH"
],
"device_ids": [],
"gateway_configs": [],
"group_state_fields": [
"state",
"status",
"brightness",
"level",
"hue",
"saturation",
"color",
"mode",
"kelvin",
"color_temp",
"bulb_mode",
"computed_color",
"effect",
"device_id",
"group_id",
"device_type",
"oh_color",
"hex_color"
],
"group_id_aliases": {}
}

Additional context

I'm in the progress to control the WLED device with the FUT089 remote panel. It would be nice if the received signals would not change depending on if I pressed the ON or OFF before that. If this was made because of the legacy devices then it would be nice if I would be able to turn it off on the device level.

sidoh commented 3 years ago

Your "steps to reproduce" and "expected behavior" look identical to me -- am I missing something?

State is not updated when bulbs are in the "OFF" state, meaning the MQTT state topic will not be refreshed when you send state-changing commands while the bulb is off. This is because physical bulbs cannot have their state changed while off. I do not think it makes sense to change this behavior, if I'm understanding correctly.

If you're attempting to use the FUT089 as a remote for a non-milight device, you might consider using the MQTT updates topic, rather than the MQTT state topic. The updates topic is a very raw translation of the actual milight command packets, and is not influenced by state.

More information is in the MQTT section in the README:

https://github.com/sidoh/esp8266_milight_hub#updates

I'm going to close, but please let me know if I've misunderstood. Happy to continue discussing.

golddragon007 commented 3 years ago

Hello,

Yes, I use the update topic, and you missed this part: image

The circled part is the difference between the two states (on and off) in the MQTT update topic.

Also if the original bulb doesn't support the turn on if the colour or other received, then maybe the update topic shouldn't be sent, because if somebody using that for their implementation, they will mess up their states.

sidoh commented 3 years ago

You shouldn't be getting any updates while the bulb is off.

Can you please paste a full MQTT log (including commands and state updates)?

sidoh commented 3 years ago

Think of the updates topic as a raw stream of packets sent or intercepted. It does not consider state. If you're seeing differences in the update topic, it's almost certainly because the remote is doing something different.

Maybe it has its own state that isn't updated if the bulb is supposed to be off.

golddragon007 commented 3 years ago

No, it seems that the ESP sends the wrong message.

If the state is off then the ESP doesn't change the message for the Command 07 Argument 00 from saturation to color_temp if I switch the mode from color to white. While if the state is on it works fine.

State off (read bottom to top)

{"saturation":100}
fut089 packet received (9 bytes):
Raw packet: 9B 54 DF CD CD AE 14 E4 D5 

Decoded:
Key      : 9B
b1       : 25
ID       : 137F
Command  : 07
Argument : 00
Sequence : 0F
Group    : 00
Checksum : AC

{"saturation":100}
fut089 packet received (9 bytes):
Raw packet: 9F 50 D3 D9 C9 A2 21 D8 B2 

Decoded:
Key      : 9F
b1       : 25
ID       : 137F
Command  : 07
Argument : 00
Sequence : 0E
Group    : 00
Checksum : 9F

{"command":"set_white"}
fut089 packet received (9 bytes):
Raw packet: 40 98 90 76 26 7C 7F 25 88 

Decoded:
Key      : 40
b1       : 25
ID       : 137F
Command  : 01
Argument : 14
Sequence : 0D
Group    : 00
Checksum : 51

{"saturation":100}
fut089 packet received (9 bytes):
Raw packet: 99 19 95 FF DB C1 AB E3 87 

Decoded:
Key      : 99
b1       : 25
ID       : 137F
Command  : 07
Argument : 00
Sequence : 0C
Group    : 00
Checksum : AB

{"saturation":100}
fut089 packet received (9 bytes):
Raw packet: AA FD C2 3D E8 BC 38 A9 93 

Decoded:
Key      : AA
b1       : 25
ID       : 137F
Command  : 07
Argument : 00
Sequence : 0B
Group    : 00
Checksum : 97

{"hue":7}
fut089 packet received (9 bytes):
Raw packet: 33 BC 67 65 3A 11 91 4C AE 

Decoded:
Key      : 33
b1       : 25
ID       : 137F
Command  : 02
Argument : 05
Sequence : 0A
Group    : 00
Checksum : 0F

State on (read bottom to top)

{"color_temp":370}
fut089 packet received (9 bytes):
Raw packet: E2 C5 6A 75 B0 84 F3 71 36 

Decoded:
Key      : E2
b1       : 25
ID       : 137F
Command  : 07
Argument : 00
Sequence : 16
Group    : 00
Checksum : 6A

{"command":"set_white"}
fut089 packet received (9 bytes):
Raw packet: 9C 3C EC 1A 82 E0 CB 81 C8 

Decoded:
Key      : 9C
b1       : 25
ID       : 137F
Command  : 01
Argument : 14
Sequence : 15
Group    : 00
Checksum : B5

{"saturation":100}
fut089 packet received (9 bytes):
Raw packet: 26 81 3E C1 6C 38 CD 25 8C 

Decoded:
Key      : 26
b1       : 25
ID       : 137F
Command  : 07
Argument : 00
Sequence : 14
Group    : 00
Checksum : 1C

{"hue":4}
fut089 packet received (9 bytes):
Raw packet: B8 20 18 EE AB 17 F1 AD 92 

Decoded:
Key      : B8
b1       : 25
ID       : 137F
Command  : 02
Argument : 03
Sequence : 13
Group    : 00
Checksum : CF
sidoh commented 3 years ago

Ah, sorry. I think I'm following what's going on now. Hopefully this helps clear it up:

Because of all of this, there's not a way to solve the problem you're getting at without completely nuking the ability to keep assumed bulb state in sync for FUT089.

This is just a shitty limitation of the underlying protocol.

Let me know if I've misunderstood, and apologies for the extended back and forth. Sometimes it takes me a while to dredge up the necessary context.