Variable help: Set variable 2 hours after trigger


#1

1) Give a description of the problem
Need helping correcting variable to send in message

2) What is the expected behaviour?
Send message that command will execute 2 hours after trigger time

3) What is happening/not happening?
triggerTime variable logs time when event happens
executeTime - unsure how to add 2 hours to trigger time.
Message is being sent with trigger time that was saved.

**4) Post a Green Snapshot of the piston!

5) Attach logs after turning logging level to Full
I don’t think logs are necessary as the pistons works but my variables are written wrong.


#2

addMinutes() or addHours should do it

https://wiki.webcore.co/Functions#Date_and_time_functions


#3

I updated to
time executeTime = {triggerTime, addHours(2)}

it is adding 4 hours. I also tried with addMinutes(120), same result.

triggerTime = 2:18pm
executeTime = 6:18pm


#4

Should be like this… executeTime = addHours(triggerTime,2)

Example:
(expression) addHours($now,2) »»» (datetime) 1619825649385 (expression) formatDateTime(addHours($now,2)) »»» (string) Fri, Apr 30 2021 @ 4:34:18 PM MST


#5

Thank you so much!


#6

If it’s not too much trouble, I have 1 more question. Different scenario but same topic

If triggerTime is $now, eventTime is set for 4am (the following day) is it possible to write into the command that event will trigger in X hours:minutes?
I’m guessing I’ll have to use formatDuration?


#7

Yes, formatDateTime() will do it. The details are in the wiki also. Let me know if you get stuck.

Edit: Sorry, misread that post. Yes formatDuration sirius give you your target formatting.


#8

I am completely stuck. Using the same piston as before to test

This pistons works but returns a time value of 16hr and X minutes. It should only be 8-ish hours.

I tried using datetime for the triggerTime variable device type but it logs the date as 5/1/2021(tomorrow) with correct (current) time.
Then I have the problem of not knowing how to set the execute time using the datetime for 4AM the next day.
I could not figure out the formatDateTime() syntax.

BTW, thank you so much for your help and patience!!!


#9

That is interesting, I’ll try and play with it also after I get done installing my eufy doorbell :slight_smile:


#10

After a few trial and errors… I noticed the values for times were not being stored correctly and this is what I came up with after some debugging.


#11

That seems to work. A couple questions…

  1. Will the date in the executeTime var update to the following day automatically (so that this can be used daily)

  2. What did the log info do?


#12
  1. No, I just hardcoded the info for testing.
  2. The log was used for debugging to see what the variables contain.

#13

Thanks for the lesson! I’m still learning.

So how would I make the execute variable work for daily use?


#14

Hmm, after execution, you can add another task addDays(executeTime,1). Today’s value is 5/2/21 at 4AM, after the execution, it should change it to 5/3/21 4AM ready for the next day.


#15

Edit: posted the wrong piston


#16

I’m still working on this.

The hard coded executeTime was not working with the addDays(executeTime,1). Best I can figure is because this is not run daily. It works great if I go in and manually change the executeTime before running the piston.
I’d really like it to calculate for me though.
I replaced the hard coded executeTime and added an if section for before and after midnight to set the executeTime variable. This works if executed after midnight but not before midnight. (For testing purposes, I changed the trigger times). The earlyAlarmTime variable is not giving me the correct value when the times span midnight. Which throws off the tts variables. Is this even possible?

5/22/2021, 2:06:09 AM +898ms
+84ms ║trigger Sat, May 22 2021 @ 2:06:09 AM MST
+93ms ║execute time Sun, May 23 2021 @ 4:00:00 AM MST
+107ms ║early alarm Thu, Jan 1 1970 @ 6:53:50 PM MST
+118ms ║display time May 23 4:00 AM
+138ms ║tts time Sat, May 22 2021 @ 2:06:10 AM MST
+159ms ║alarm will go off in 1 day, 1 hour, and 53 minutes.
5/22/2021, 2:06:08 AM +338ms
+186ms ║before Sun, May 23 2021 @ 4:00:00 AM MST


#17

For reference, this is what the logs show when I run it after the trigger time

5/22/2021, 2:23:16 AM +455ms
+88ms ║trigger Sat, May 22 2021 @ 2:23:16 AM MST
+99ms ║execute time Sat, May 22 2021 @ 4:00:00 AM MST
+114ms ║early alarm Sat, May 22 2021 @ 1:36:43 AM MST
+127ms ║display time May 22 4:00 AM
+148ms ║tts time Sat, May 22 2021 @ 2:23:16 AM MST
+171ms ║alarm will go off in 1 hour and 36 minutes.
5/22/2021, 2:23:15 AM +300ms
+99ms ║after Sat, May 22 2021 @ 4:00:00 AM MST


#18

Maybe I am not following what you are doing, but in both cases the ttsTime seems to be correct, though you are logging an already formatted duration string as if it were a datetime so just get the current date and time output by default.

Similarly earlyAlarmTime seems to have the right value as a duration but seems to look odd when formatted as a date and time instead. That is because the zero time (‘epoch’) is 00:00:00 UTC on 1st Jan 1970. When you add the earlyAlarmTime to that in your first example you get 01:53:00 UTC on 2nd Jan but that has to be corrected to MST so it ends up as 6:53pm on the 1st.

When you do that with 01:36:00 UTC on the 1st Jan things get confused as you can’t convert that to MST without going back before the epoch. So you end up with a fusion of today’s date and the UTC time just to give you something.

So as far as I can tell your problem is with your log statements.