@bobbyD perhaps this is a bug ā today I built a very simple rule with a certain time trigger (sunrise + 60 minutes), a few dimmer adjustments, then a "wait for certain time" event followed by a few more dimmer adjustments of the same dimmers. This rule should be very simple.
The sunrise + 60m trigger worked perfectly. However the wait for certain time event failed to trigger at 10:30pm when I set it and instead triggered at 10:30am. I thought ok classic fat finger or forgetfulness switching that dropdown right? 
Well not so much. I tried all I could but not matter how I adjusted that time to PM it would not stick. I even tried a reboot and then attempted to adjust it again to no avail. Finally typing 22 into the hours field and 30 into the minutes field indeed resulted in 10:30pm. I will know tomorrow night whether this actually worked 
My hub is running 2.2.0.128. I just saw that 2.2.0.130 dropped but nothing in the changelog suggests that this was fixed. Any ideas?
Two questions he'll probably end up asking. 
-
Is your hub set to use 12- or 24-hour time? Check Settings > Location and Modes, then look for Time Format.
-
What OS and browser versions are you using? (Internet Explorer and non-Chromium Edge are two known to be problematic, though time inputs are apparently pretty tricky regardless.) FWIW, the latest version of Firefox (76) on the lastest version of macOS Mojave (10.14.6) worked fine for me with 12- and 24-hour time (the latter of which does away with the standard time input, it appears).
Thanks for preempting! I can confirmā¦
- My hub is in 12 hour time
- MacOS 10.15.4 and Iāve tested from both Safari and Chrome running the latest stable versions.
To be clear the issue only occurs after committing the details. The drop down responds the way it should accepting the switch to PM. But after clicking Doneā¦ and the change is committed to the Hub when I return to check the wait it will incorrectly read AM. In the compiled rule code it also reads incorrectly after committing. Attempting to renter the time using 22 hours instead of 10 works every time to force PM no matter what is chosen in the AM/PM drop down.
Thanks,
Richard
I am noticing the same issue. Is this a known issue, and is the fix in the next release? Yes, entering the time as 22:00 for 10 PM works, but it isn't intuitive.
@bravenel
This is a 2 year old topic, so please show screenshot of what your problem is. Is your hub set for 24 hour time or for 12 hour time? You can set this on the Localization page in Settings.
12 Hour
I got it to accept the 10 PM by setting it to 22:00. Now, if I select AM, it stays PM.
Here is the entire rule.
I just tried it again using Chrome instead of Safari, and it works properly. It appears to be a bug in the Safari AM/PM drop down selector.
I have no problem with Safari setting the time to 10:00 PM.
Well, I have 2 work arounds, so I can live with it.
With Safari, you do have to hit the Update button.
Hitting Update is when it changes back to its previous setting. If AM, stays AM. If PM, stays PM. This works correctly on iOS, but not macOS. Weird.
I cannot set any PM time while using Safari. Clicking update changes it to AM. The hub is configured for 12hr time. It does work using Chrome. It does work in Firefox.
The MacBook Pro is an M1 chip model.
MacOS: 12.6.1
Safari: 16.1
Chrome: 107.0.5304.87
Hub: C-7 at 2.3.3.140
Rule Machine: 5.1
Known problem specific to newest Safari. We will get it sorted out.
