I use the Alarm Clock plug in to fire the radio in the morning. Not ideal but better than the previous solution of having a timed scene that I needed to update. (Our getting up time is somewhat variable)
What I’d like to do is have the heating come on at a set time before the alarm (as opposed to the current rather primitive fixed time)
I can pull the currently set alarm time correctly (for example 07:15:00) and assign it to a variable. (Obviously! That’s simple even for me!)
What I’m stuck on is effectively the condition that says 'If it’s after 60 minutes before 07:15:00) then perform these activities.
The other approach I’ve tried is creating another variable and trying to subtract an hour from it but got stuck there as well.
Is it possible, and if so, can I get a pointer in the right direction?
I’ve read that again, and I confess I am none the wiser
I have used the expression to store the time in a variable: (AlarmTime) but I am at a loss as to how I can reference that in the Reactor conditions (which was my intention)
I’m on the road right now. LuaXP, the expression parser that Reactor and SiteSensor uses, needs an extra function to make this easy. But I can’t add it until I get back…
So now, you need to pluck the alarm time from the Alarm Clock plugin, whatever it is set for currently, take it apart, and construct a new time that’s 60 minutes earlier. Assuming the Alarm Clock plugin returns the HH:MM:SS format you used in your earlier post, you can pass that directly to time() and get a timestamp on the current day. Subtract 3600 from that to get it an hour earlier (timestamps are in seconds).
Just one thing I’ve not managed to find is the group refresh? Where’s that set? If I hit the drop down on the group I can’t see anything that looks like it would check every minute, but that’s going to be me, isn’t it.
Ref the Alarm Clock, the short answer is nothing. I had a scene set, but changing that each night was a significant PITA in terms of how many steps it took and I couldn’t do it on the iOS App (bug that the only activity was to run an OS Execute, and the App decided there were no activities)
So the alarm clock plug in is much easier to set in terms of it takes about 10 seconds and a couple of clicks. No reload. Still can’t set it from the App, though
Any other suggestions would be great? I doesn’t look like I can edit Reactors from the App either?
A bit of lateral thinking here…brain bubble.
How about using Alexa or Google (your choice of VA) to set the Alarm, create a scene to send a trigger to reactor when it goes off?
Sounds simple, bet it won’t be…
You have to create a condition group called “Refresh” (or anything, really, I just chose that name–maybe that choice was confusing) with an Interval condition in it. The interval condition firing every minute will cause the variables to be updated when nothing else would otherwise update them (since there are no device conditions or other stimulus in the logic here), so that “heaton” specifically checks again the current time–we want “heaton” to update frequently. You have to use an interval condition for this because Reactor cannot “see through” your logic and make time edges to schedule to, as it does for its own date/time conditions. “Other logic plugins” just automatically check every minute no matter what when using a comparison to the current time (“now”), but I regard this as an inefficient choice to enforce on the user–better, in my view, to give a mechanism to allow it to work that way rather than forcing it to work that way.
This continues to be a limitation of the Vera mobile apps. I think it’s unlikely you’ll ever be able to do configuration from the mobile apps for Reactor and any other plugin that uses JavaScript tabs as part of its interface. The best we could hope for is access to the plugin devices’ “dashboard card” controls–the basic controls you see on the Devices list in the web interface. These are built from JSON data, even in the web UI. But Vera doesn’t honor its own definition format for these basic controls in the mobile apps, which has been a sore point for me for a long time. If it did, you’d at least have the “Reset” and “Trip” buttons, the “enable/disable” toggle, and the status message on the ReactorSensors in the mobile apps. I understand why they likely would never implement the JavaScript tabs, but the dashboard controls and their definition are a really small subset of simple data-driven presentations that would be relatively easy to duplicate in any environment–even if it wasn’t done perfectly to match the web UI, it could still be functional.
So the Interval doesn’t actually need an activity? Just needs to go True every minute or so?
I just tried and updated the Alarm clock and went into the Reactor.
It had already updated the AlarmTime variable to 04:50:00 (don’t ask)
also the HeatON variable (which I defined as time(AlarmTime) - 4500) as 1574739300 which is epoch of 03:35:00 but this morning.
But my interval was set for 15 minutes, so not sure if things had updated because I checked the status and it will correctly set HeatOn just after 00:00:00 GMT to be 03:35:00z 11/27/19?
Thanks, as ever, for dealing with the newbie
I’m not even going to mention the App again. Certainly wasn’t a criticism of Reactor! Any other suggestions for Apps would be great.
Reactor would have seen the change to the Alarm Clock variable because of the getstate() there, that triggered an update/re-eval.
Yes, the interval condition just needs to exist. It’s periodic state change will cause the re-eval of the variables and conditions. No actions/activities needed.
Yes, after midnight it will use tomorrow’s date… because the time value from Alarm Clock has no date component, LuaXP’s updated time() parser just uses the current date, which after midnight is then tomorrow 11/27. That is, time("12:00") is noon today whenever you evaluate it today, and it will be noon tomorrow any time you evaluate it tomorrow.
where next?
