Please add time=now to the the variable time difference function:
Also, what variable types are supported? It appears that the 'time difference' function is not exposed for a variable of type=time but is for type=number.
I'm lost. Why is downstairsTempLowAge negative? Now minus a time in the past should be positive shouldn't it?
Because you are setting the difference in the wrong direction. Try swapping timeNow and the time variable in the set 'downstairsTempLowAge. It subtracts the first time from the second time.
But, I think that code may have a serious flaw in it... Looking into it.
What version of Rule is this?
That's not intuitive. 9-4 isn't -5
Rule-4.1
It would certainly help if the UI showed what to expect, namely second time minus first time.
Apparently not everyone's intuition has the same expectation. The author's expectation was that the earlier time comes first, and the later time second. Your comparison with 86400000 misses the "minutes of difference" label. That's 60,000 days worth of minutes.
Rule-4.1 doesn't have the problem I see with Rule 5.0.
So much for 2.2.8 being done?
I've swapped the order of the operands and converted 864000000 milliseconds to 1440 minutes.
Thank you.
Ha! Discovering bugs in a large software system is inevitable, an ongoing process...
1 Like
86 400 000 milliseconds is the amount of milliseconds in 24 hours (one day). When I view the rule you posted I wondered if you are confusing a Number variable being set to the current unix time (user selectable to either seconds or milliseconds) and time variables.
When I am doing something similar to this, I don't bother with time variables and just use number variables that get set to the current unix time (in seconds) and then just regular variable math (with number variables) to find differences in time.
So 86 400 seconds was instantly recognizable as the amount of seconds in a day.
I am sure many users do this differently and everyone will have their own preference, although I imagine it is probably best to tackle either with number variables being set to unix time or time variables. I would get confused if I tried combining them.
The action he is using works in terms of minutes.
Yes, but in the rule posted he checks the variable that was earlier set in minutes to check if it is greater than 86400000. Like you said earlier that is 60 000 days worth of minutes. So I wonder where he came up with the idea to use the number 86400000, probably wasn't thinking about that many days. 86400000, just happens to be the exact amount of milliseconds in a day and if you where setting number variables to current unix time in milliseconds (which you can do in HE), I figured that was were the number came from. (I actually use the number 86400 in several of my rules, but I set my unix time in seconds not milliseconds) It would be a fairly odd coincidence if its not.
Either way, I am happy the OP has it figured out and maybe the 86400000 derived from something else.
Yes, obviously he was thinking about Unix time. A subset of our users are familiar with Unix time, and the majority are probably not. For mere mortals minutes makes a fairly good thing to be measuring, as opposed to doing math with 60000 and what not. Don't you think?
I agree 100% Bruce, and apologize if my post seems obtuse. Sometimes typing in forums is difficult to convey expression. I only mentioned it cause I figured the OP was playing around with that subset of users using Unix time since he referenced that particular number. And to me his rule seemed to inappropriately mix the two.
I don't envy your job in trying to create "time" variables and all that would be involved with that and making it work the way a typical user would expect. I wouldn't even know where to start. For me being able to set number variables to the amount of elapsed seconds since a specific time in history and then doing regular variable math with the variables is simplest. Personally, I am not proficient in programming and/or unix, but I do teach high school mathematics so the math I find easy.
I often think that some of the things I do with Hubitat, could probably be created in simpler ways, but it doesn't take me that long to create stuff and it works so I don't really care. Here is one example of my number variable math using unix time:
The nice thing about my dashboard filter timers is that if I don't change them in time, they start to display negative numbers, LOL.
My mistake was taking on dates, hence DateTime instead of just Time. Time is easy, but DateTime is a royal mess. Some user posed a reasonable use case for wanting a variable date/time, so in I plunged. Dates and times are just messy. Under the covers, when a user enters a time through a browser, a Unix-like date-time string is created, one that looks like this:
2021-08-07T12:39:12.012-0700
That represents 12:39 PM today in Arizona. Notice that it has .012 seconds tacked on, so it's actually a transform of Unix time, complete with timezone refinement. It's been an agonizing path to get all of this to come out right. Adding in DST is like the icing on the cake. We have yet to successfully pull off the transition into or out of DST without off-by-an-hour mistakes, although our hopes are high for the next one in November.
2 Likes
I believe it, although I am not a programmer and do not write software, I have always thought that time and all the ways it needs to be considered in a product like HE, could quickly become somewhat of a nightmare, especially considering that the average user probably doesn't appreciate just how difficult certain aspects of dealing with time can get.
1 Like
