-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long press is almost always activates night mode (unsupported button/device?) #714
Comments
The packet handler is here: 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. |
On the original bulbs, which button long-press sets the device to night mode? |
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. |
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. |
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. |
@ccutrer Did you noticed any change on your LED strip when you pressed those with the long-press? Did anything change? |
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. |
Oh wait, long-press S+ does the same as S- on my single-output strip controller (turns them off and then back on). |
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):
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:
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.
The text was updated successfully, but these errors were encountered: