So apparently wyze has decided for me that the minimum amount of time a plug can be scheduled to be ON is 2 hours?? I have lamps that I want to come on at a set time and then turn off at sunrise, and also turn on at sunset and turn off at a set time. When trying to set the on or off time I just get a warning that a 2 hour minimum hasn’t been met and it won’t save my program. Excuse me? I don’t care if they’re on for 15 minutes, between the time I’ve scheduled and sunrise or sunset, that’s the time I want them to be on. I can set them in the winter, because there’s more dark hours, but if I try to edit the schedules now I can’t because I want them on at 5:30 am, off at sunrise, well that’s less than 2 hours now… I’m guessing they’ll never fix this, just like they never fix anything.
[Mod Note]:Your topic was moved to the #wishlist category since it involves a request for change to the Wyze application.
Note that this wishlist topic is not limited to Plugs. This request seeks to remove the restriction Wyze has applied to any Rule type where either start or end time is fixed and the inverse time is tied to variable sunrise or sunset.
Also not having the option on any of the plugs for multiple on/off times per day. That’s just stupid. I have plenty of digital plug in timers with up to 8 on/off per day available, yet these only allow for one?
I have a similar problem with bulbs… multiple schedules per day for multiple bulbs and lack of adequate rules organization in the app makes for one messy user interface.
As your issue is apparently an intended design “feature” vs a bug, I’d like to convert your topic to a wishlist item to effect change. I’d really like to see the 2-hour restriction removed. Mind if I make your topic a wishlist item?
I think I know why Wyze implemented this 2-hour restriction to Rules. The restriction only applies when either start or end time is fixed and the inverse time is tied to variable sunrise or sunset. Depending on the time of year rule/schedule was created and length of on/off window, start/end times could overlap over time. But this should be obvious when creating a schedule where one parameter is based on a variable (moving) time. A user will notice this problem if/when it occurs. There should be no restriction, especially considering we can circumvent via my 2 separate schedules example above.
I came to the same conclusion, that they are trying to keep you from setting an ‘unpredictable’ rule, like when the ON time ends up after the OFF time during certain times of the year, due to the sunrise and sunset times changing by date.
However, while a simple 2-hour restriction prevents them from doing the tougher calculation as to whether the rule actually flips for your location any time during the year, it is probably not enough to keep you from setting an unpredictable rule.
For instance, whereas the earliest to latest sunrise at my location (Midwest) is indeed around 2 hours, sunset varies by a little over 4 hours. However, it still applies the same 2-hour rule to sunset, and if you are in Alaska your sunrise may vary by almost 4 hours, and your sunset by 8! (Alaska is nuts for sunrise/sunset)
So they should probably drop that arbitrary restriction, although I’d bet that causes a little more of support headache for them when the rule does flip for someone.
However, you can work around it by doing what @seapup did and set a separate ‘on’ and ‘off’ rule. You can create as many of those as you want, there is no limit on the number of rules you can create for a device. It does become confusing after you create very many though, like @seapup said.
Well they should be able to tell if the end time ends up before the start time, then just don’t do the start thing. It’s not that complicated. Today it just ignored the shut off my light at the prescribed time because it finally ended up at less than 2 hours after sunset. What an annoyance.
Still would generate a support call because the rule didn’t fire off. But I agree, the more complicated calculation of making sure the rule was valid all year long for that location is the way to go. How often would they have to calculate that? Only when someone saves such a rule, which has to be seldom.
Thank you so much for letting us know the issue you are running into. We will look back to the original intention of designing the restriction here and optimize it accordingly.
Especially when you can do this which defeats the intent of their restriction:
