search

sidoh / esp8266_milight_hub

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

Long press is almost always activates night mode (unsupported button/device?) #714

Open golddragon007 opened 3 years ago

golddragon007 commented 3 years ago

Hello,

I don't have Mi light devices I have only the remotes and I write automation to control WLED devices with them, so I don't know if this is the correct behaviour or not, but I have the following Mi Light 8 zone device (identified as FUT089): image Where if I long press any of the following: W (white mode), ON, OFF, S- (mode speed down), S+ (mode speed up) then I will receive night mode, which is really strange for the last 3 buttons. From the Command/Argument stand of point in the packet, they are all different. If the original device doesn't go into night mode in any of those cases, is it possible to remove it from the MQTT message and replace it with something else?

Another interesting case would be for this use case if I would be able to overwrite the command name (in MQTT) from the UI per controller and then I can use it for different function the long presses of those buttons.

Then I have the following device, which is identified as FUT091: image Here similar happens, any on/off button that I press long will send night mode. But here there's MQTT message randomness also. Let's say I long-press the first time the zone 1 on or off button, and I will get the night mode command on zone 0. Then I long press on zone 2 and I get it in zone 1 the command, but only the long press. If after these, I long-press zone 4 I get it in zone 2 the command... Then to make it more confusing, sometimes (in rare cases) I get into the correct zone the command. Also sometimes I receive in this case messages to the milight/(updates OR states)/0x0/rgb_cct/1 topic.

sidoh commented 3 years ago

The packet handler is here:

https://github.com/sidoh/esp8266_milight_hub/blob/master/lib/MiLight/FUT089PacketFormatter.cpp

Might be because night mode is prioritized above speed up/down.

I unfortunately don't have a lot of free time for this project right now. I'd encourage you to try playing with this packet parser if you think something is amiss. I'd happily review a PR.

golddragon007 commented 3 years ago

On the original bulbs, which button long-press sets the device to night mode?

sidoh commented 3 years ago

I think long-pressing the "ON" button sends the bulbs into night mode. I have a physical FUT089 and some FUT015s to test with, but won't be able to dig them out until the weekend.

golddragon007 commented 3 years ago

https://youtu.be/4dSXTsVApw8?t=215 according to this the night mode should be on long OFF press... This will mess up really the states here.

ccutrer commented 3 years ago

Can confirm that long-press ON, S-, M, or S+ on a FUT089 does not send my LED strip (FUT036 - single color), or two different bulbs (FUT066 and FUT062) into night mode, but long-press OFF does. I also have some FUT039 RGB+CCT strip controllers, but they're not hooked up yet. No reason to assume they'll act differently. I'll try to test out the PR soon.

golddragon007 commented 3 years ago

@ccutrer Did you noticed any change on your LED strip when you pressed those with the long-press? Did anything change?

ccutrer commented 3 years ago

Long-press ON does nothing (besides turn it on if it's not). Long-press S+ does nothing. Long-press M very quickly goes through the available modes (i.e. just repeats the command). Long-press S- is slightly more interesting - the bulbs turn off for a second, and then go back to their previous state, but only when in white or color mode - when in scene mode it doesn't do anything.

ccutrer commented 3 years ago

Oh wait, long-press S+ does the same as S- on my single-output strip controller (turns them off and then back on).