So a time GV is a number representing the number of seconds from 1/1/70, correct? So it's really a date AND a time, right? So shouldn't the cell in the value column of the global variables table show the date as well as the time? And you can only enter a time, not a date so how do you enter a future or past time? Or am I missing something obvious?
No, it's not a date and time, it's a time. For example, if you set a variable to 3:15 PM, you could use that variable in a Certain Time trigger. It would trigger every day at 3:15 PM.
If you need to trigger a rule on a specific day/time, you can use the “Periodic Schedule” trigger. That one has a lot of options, including a Cron String.
Ok. During a search though the forum messages, I thought I read that "time" is the number of seconds since 1/1/70. So it's the number of seconds (or milliseconds?) from midnight of the current day?
No, I'm comparing times in a conditional.
The GV 'BackYardMotionSuppressedUntil' is set elsewhere. If I want to disable motion alerts while I'm cutting the grass for example, I would set 'BackYardMotionSuppressedUntil' to something like now() + 120 minutes (the end goal is it being set by a button click on a wife-friendly dashboard).
So if a time GV only represents an interval from midnight rather than an absolute time, then this logic won't work. Suppose I set 'suppressed until' to 1 am and a motion alert goes off at 11 pm, I presume 11pm >= 1am evaluates to true, and my logic here is faulty.
Why no datetime GVs? I could do this easily in Webcore, but I really want to give RM a shot, particularly as I can set the value of a GV with an http GET.
Interesting that it seems I can set this GV using an UTC value in an http /setVariable GET call to the RM connector associated with the GV, but the call failed when I just passed a time (e,g, "01:23 am").
BTW, I know there's other ways I could skin this cat. Maybe disable the rule and set something to reenable it, but this seemed the simplest way to go about it.
Another option would be to have a switch that when turned off, turns on after a set time (Ex.: 120 minutes). That could be setup instead of the rule that adds time to the variable.
With this setup, your wife just needs to turn on a switch.
Sorry for the confusion. A time variable does not represent an interval from midnight, it represents a time of day. Perhaps it's best if you think about two close but different uses of time: One is a specific time of day (5:00 PM), and the other is a duration of time (expressed as hours, minutes, seconds or milliseconds).
It sounds as though you are wanting an automation that is based on duration, not time of day. For what you want to do, aren't you wanting to disable something and then re-enable it after a duration? You can use Delay, or Wait for Event Elapsed Time to re-enable something having disabled it, without really caring what time this happened. So one way to do that is to have whatever rule begins the disablement to set the Private Boolean of this other rule to false (or a Global Variable), wait for the duration, and then set it to true. In the rule that is to be disabled it could simply test Private Boolean (or GV) and exit the rule if false.
Or, even simpler, as suggested above. pause the rule, wait the duration, and then resume the rule.
3 Likes
Creating a Global Variable (number) and then making a rule to set this variable to "current time" in "seconds" will result in the variable becoming the current unix time, which is the elapsed time since January 1st, 1970. It will display this number as the number of seconds elapsed since 1970 or the amount of milliseconds elapsed since 1970 your choice in RM. I use this feature in some GV calculations for filter changes. Here are the screen shots to illustrate it:
The test rule I made
The result
Current Unix time: https://time.is/Unix
Don't know if this feature will help you accomplish what you want, but it is there if you need it.
1 Like
"Interval" was probably the wrong word to use. But "time of day" is in essence a point in time represented by some period of elapsed time past midnight. "9 am" means nothing without everyone agreeing on its meaning of 9 hours past midnight. For one time to be greater than another it has to be further away from midnight than the other, otherwise > and < expressions with time operands would be meaningless, wouldn't they? Anyhow, not to pick nits but I understand now what the "time" type conceptually represents.
Yes, and the way I did it (if there were a datetime type) seems to me to be the simplest and most bullet proof way of doing so. There is nothing to enable or disable, just a simple boolean test at the time the event takes place. Assuming of course, that the value of GVs persist between hub reboots.
The methods you and Sebastien propose require two actions; one to disable and a future action to reenable. But there's no guarantee that that future action will actually occur. In the unlikely but possible case that the hub goes down, the reenabling event might not fire. Coding it like that creates an edge case and I'm sure you've been bitten by nasty difficult to debug edge cases before. I certainly have.
As a practical matter we're not controlling a nuclear reactor here, so I guess I'll have to take one of these approaches. Out of curiosity, why isn't there a datetime type? Do you not want to deal with 64 bit variables?
Perfect. Thank you very much.
- No one has ever asked for it in automations, before you.
- There are not many use cases that need it (yours is not a good example of a use case that needs it).
This isn't intended to be a "coders" environment, but an system to setup automations. It's a bit pedantic to suggest that 9:00 AM represents an interval since midnight -- only someone used to programming in a Unix time environment would think that. For the rest of us, 9:00 AM is just a time of day we're interested in having something happen.
Whoa, if not, then the entire hub system is for nought! That's what it does, schedule things to happen reliably in the future. Many, if not most, automations rely on this. E.g., turn the lights off after 1 minute of no motion.
1 Like
What if I wanted something different to happen in a lighting rule while I was on vacation and I know I'm going on vacation the week of June 28? How would I write such a conditional in RM?
I have a webcore piston that controls my porch and garage lights (Sengled RGBW). From Thanksgiving through new years they're red and green. During Memorial Day and July 4th they're red, while and blue. Other times of the year, they're white. How would I code that in RM without datetime vars? This is a real automation, silly as it might seem.
Fair enough, but you do have to be a "coder" to some degree if you're going to write rules using variables, expressions, conditionals, etc. But yes, when I saw the time data type I'm thinking of time_t or DateTime (I'm a Windows guy, not all that comfortable around *nix).
Well sure, that's the happy path. But if I schedule lights to go off in 1 minute and the hub goes down in 50 seconds, will the event fire once the hub is restarted? If yes, then my assumptions are incorrect. If no, then the switch is left in an undesired state and the longer the delay interval, the greater the chances that the future event won't fire. The way I coded it requires no future action for correct operation 100% of the time.
I supposed I've conditioned myself to try and see all the things that can go wrong. and code for those possibilities even if they're unlikely to happen. Again I do understand it's not a coders environment, but good coding practices result in a more reliable system nonetheless.
But you must have a datetime type internally for scheduling purposes, no? Or are you just periodically decrementing counters and firing events when its counter reaches zero? That wouldn't survive a reboot, would it?
Yeah, and you can do it the way you want, just not with a time variable. You can put now() into a number variable in seconds (forget millis). Then add to it the number of seconds you want until the re-enablement. In your rule that you showed, grab now() into a variable, and compare the two variables.
Seriously, the hub is reliable (saying this from 4 years experience with it in my house); schedules are reliable. I used to run ST, and schedules were a joke. What a mess that was! I'm just saying that if you can't rely on the hub to do it's thing, then the entire discussion is pointless.
There are a number of ways to deal with this, none of which require a time/date object per se.
-
One way would be to have a "vacation" mode, and have automations deal differently with that mode. It is possible to schedule rules to fire at specific date/time events.
-
Another way would be to have separate automations for vacation, that are normally paused. RM can pause other rules, and resume those, again from a specific date/time trigger (see Periodic).
-
It is also possible to test a condition of "between two dates", as well as "between two times". I have a rule that puts a certain shade down around sunset, but only between April and August.
1 Like
Just to be clear, I'm not suggesting in any way that HE isn't reliable. I'm also a long time ST user .
Unfortunately I still have to run my ST hub until HE works a secondary zwave controller, but that's another topic. Using ST and "reliable" in the same sentence should be a punishable offense and I can't wait until the day my ST gets unplugged for good.
Sure, but the hub can't protect itself against external events. If I set an event to fire in a few hours and a fw update comes out and I apply it (not considering that I may have pending events) will the missed events still fire after a reboot? Or the power goes out for a sec and my UPS battery decides to die at that instant. Been there. Momentary outages are common down here in S Fla, especially during hurricane season, and batteries usually die at the worst possible time.
Will missed events fire when the hub restarts? It would be helpful to know what does and doesn't persist across reboots.
That's helpful, hasn't considered doing it that way. Will keep that in mind.
Would still like to see datetime vars 
but I understand there's only so many hours in a day.
Yes, unless the event happens during the time the hub is down. Schedules are preserved across reboots, but something scheduled during time the hub is down is not fired later.
You'd have to show a compelling use case....
