The cloud dashboard is working now.
1 Like
I got the following when I tried to update the time on a dashboard tile:
I'm trying to get a time into aconnector-variable to use in a legacy RM. This setup worked great before.
2.2.8-141 C7
Please try again with new build 143
Still not working here on local dash.
DateTime variables accessed via Variable Time on the dashboard seem to be working correctly on the dashboard when no date is applied, but there is still an issue when both a time and date are entered.
In the screenshot below, I manually entered 06:30 AM am on each tile, but the connector tile on the right is displaying 5:30 am. When I change the date to today, it displays the time correctly.
A related issue is also present in the RM5 display. If I delete the date entirely a 6:30 am value is shown as 5:30 am. I'll have to see what time it actually goes off with a test rule that isn't waking me up an hour earlier than I expect it to!
We know there is a bug in this release causing this. We will get it sorted.
3 Likes
Would this known bug also cause a date/time parsing error in RM5?
Context: I have a RM4 rule that sets a color temperature fade twice a day using a virtual dimmer. At sunrise, it starts to fade the dimmer up from 0 to 100 until noon. And at noon, it fades the dimmer down from 100 to 0 until sundown. Idea is to have this dimmer track to the circadian rhythm. I then use this virtual dimmer to set color temperature by bulb type throughout the house. Worked great for awhile!
Recently it stopped working. I’m getting the below error. I suspect this has to do with the time variable now including date. Could that be right? If so, will this error go away when you solve the bug you mention above, or do I need to use different logic to calculate time difference now that time variable includes date? I’ve also pasted the rule at the bottom of the thread.
app:2612021-07-29 11:40:46.942 pmerrorjava.time.format.DateTimeParseException: Text '9999-99-99T12:00:00.000-04:00' could not be parsed: Invalid value for MonthOfYear (valid values 1 - 12): 99 on line 6610 (method appButtonHandler)
Two questions:
- Have you updated to 2.2.8.145? If not please do so, as it had fixes for this error (if Rule-4.1 or Rule 5.0).
- Is this rule a Rule-4.1, Rule-4.0, or Rule 5.0?
Yes
I built it and it was working for awhile in 4.0, then I moved it recently to 5.0 to take advantage of hub variables. That’s when I hit the snag.
Could you please turn on Action Logging for that rule, and post the logs with a screenshot. Its hard to tell which one is throwing the error.
Never mind, I found it. Fix will be coming.
3 Likes
OK great. FWIW, I found that if I included the date alongside the time in the time variable, I could avoid the error. It was only when the time variable was date-less that it threw the error.
Yeah, found and fixed. Release coming soon...
1 Like
You guys are absolutely R I D I C U L O U S.
From finding an error to fixing in < one day. Never heard of a software company that operates that responsively. Yet again, I want you to know how much I appreciate how you folks operate.
1 Like
Why put off for 6 months what you can do in 15 minutes?
5 Likes
As of 2.2.8.151 all looks well with time variables again except when a date under DST is entered. It's definitely usable for me now, but if I enter a date prior to March 14, the variable decrements 1 hour from what I type in.
This is expected behavior. If you reference the time today (during DST) as an offset from UTC, that would be a different time before March 14. If you want an automation to run at 8:00 AM every day of the year, that will be a different actual time before March 14 than it was today.
Question about what to expect.
If I have "times" set (e.g., like alarms) for 8:00am (no dates)--will those change to a different hour when std. time hits in the fall?
I need to be at work at 9am--in whatever (CDT or CST) is current--so I need my alarm to go off at a given hour (and not move forward/backward an hour on the change).
What should I expect?
(I really wish they'd go to DST year around and stop this nonsense--there are so many things about the time change that screw things up. Like this--there really aren't ANY "perfect" answers that work in every case. smh)
1 Like
Hopefully, yes. They should.
Imagine you had an old fashioned alarm clock. You'd have to set it back in the fall on Saturday night, right? Your phone, your computer, and hopefully your hub do this on their own.
1 Like
In that case, I'd have the "alarm needle" set at (say) 8am.
Before I went to bed the night of the change, I'd spin the clock hand back from (say) 10pm to 9pm ("fall back") but the alarm would still go off at 8am the next morning since I didn't change the alarm needle.
It is a different UTC offset--but still "8am local time". Just trying to understand what to expect.
(as a System Administrator for >36 years, I've dealt with these time zone and leap year issues seemingly more years than not 
-- it's always something)
The interface is very confusing. I'm okay with the general concept, but when I try to make a variable equal March 13, 2021 at 6:00am and the variable stores as March 13, 2021 at 5:00am that doesn't make any sense.
Edit: Maybe I'm less okay now that I read the exchange above. Alarm clocks on my phone automatically update to match DST so that the hour stays the same. Are you saying that when DST starts again later this year my 6:00am alarm is going to go off at 7:00am?
