When & where is the next rocket launch worldwide?

#178

Interesting…

From what I can see on my end, my piston did a fresh pull 3 hours before the launch (as expected). At that time, the China was still scheduled at [0] (2:04am UTC).

For some reason, my piston did NOT pull fresh data at the 2 or 1 hour mark…
(I’ll add new info to the log to figure out why)

Then, at the T-60 minute mark, the piston ran again (as expected) finally seeing the updated API. (Vega finally appeared) All of Vega was stored in the local variables…

This means, everything worked perfectly, except the piston did not update the schedule…
… and so, when the original time expired, it read off the current variables (Vega)

Or as SergL said:

I did not have my log set to full, but I wonder if the piston even came back from the 2 second WAIT.
(that line is a new addition to the code)

Edit:

I am tempted to tell my piston to ignore China completely, LOL

Edit2:

I made a slight change to my WAIT near the end.

pic

This should do two things. (1) Give a better view of the data as it is seen throughout the day… and (2) To make sure the piston returns successfully after the WAIT (to potentially, reset the wakeup time for the launch time)

Once I confirm, I will update my original post here.

#179

It’s a very interesting case. I know you pull data at 6 past the hour and the launch was at 5 past. I pull at 3 minutes past so for me:

3:03 - pull data because I set {hourToRequest} to 3 - hrsToLaunch=5:02 [not recalculated yet]
4:03 - no new data request - hrsToLaunch=4:02 [actual 3:02]
5:03 - no new data request - hrsToLaunch=3:02 [actual 2:02]
6:03 - new data pull - hrsToLaunch=2:02 [actual 1:02]

So I think I am going to change to start pulling at hrsToLaunch<4 to be sure I get more data points

What just hit me is that on the Every hour it only executes what is in the ‘every’ block. So the 30 minutes before hrsToLaunch likely takes a couple runs before it updates. The fact that hrsToLaunch changes only one pass before the notification is probably why it still ran at the previous time.

#180

Yes, it recently dawned on me that less than three could occasionally be 1.01 hours in the future.
(so setting it to < 4 should update between 2.01 and 3 hours prior to launch)
… depending on the precise minute of the launch, and the minute you choose to update.

PS. My update time is definitely not 6 past… That was my public piston upload time…
(IE: I do not want my piston to run when all the newbies pistons runs, hehe)

#181

I ended up going with round(hrsToLaunch,0)<=3. We’ll see how that goes.

Right now the launches keep getting delayed. I thought we would have one soon but that Vega keeps pushing out. :frowning:

#182

Anyone else get another erroneous early notification tonight?

#183

Yes. All my variables were set properly… but that formula was never updated after the launch rescheduled. (the irony is, that line of code originally came from your piston, @SergL… LOL)

(this is the problem with math in a trigger)

I need to recode a bit to convert that into a time ahead of time.

Stay tuned.

I changed my last block to this to test:

pic
pic.jpg699×153 12.9 KB

............... Send alert

By forcing it to run a bit early, it should recalculate the math used in the time…
(the >1 is just a safety net to prevent unwanted alerts)

#184

LOL!! Figures, it was going all too smooth! :slight_smile:

Understood, updating mine to mirror your temporary fix as well.

#185

The interesting thing is in my instance I have a spoken notification past the written one but it has never triggered erroneously. So it would seem that once it triggered the written portion (correctly or incorrectly) for some reason the verbal portion gets referenced the correct date/time?

#186

yea, that’s the tricky part with using math in a trigger…

  • The piston can’t trigger until it does the math…
  • … but it can’t do the math unless it is running…
  • … and cannot run until after it triggers…
    (or in this case, something else triggers it)
#187

I guess the timing worked out for me as I didn’t get any erroneous messages.

Rather than adding an early run, couldn’t you just check that (nextLaunch-$now)<=(minOffsetBeforeAlert+1) since that is updated hourly?

#188

True, but with all of the last minute API changes, that final time should really be updating more frequently…

Thinking outloud…

I wonder… if that last block was moved to the top… would it update the VoiceAlert time each hour?

Hmmm…

#189

Supposedly, it only runs what is within the ‘every’ but if it has to pass over it? Sounds like we need another experiment…

EDIT: Here is some more thinking out loud… What if the piston executed itself at the end of the every loop. It shouldn’t re-execute the every but should update the if date and time, right?

#190

Both of you are much further ahead in skill level on this than I am, but my thinking out loud is what if we add a do nothing block after the every and before all the written/verbal notifications that triggers off the same {nextLaunch}. Would that then subsequently fix the math for the following notifications below?

#191

That is the current predicament… Often, when a piston calls itself, there are double triggers.

This is essentially what I inserted yesterday.
(although I am tempted to change it to -720, or 12 hours)

Of course, we won’t know if it is successful unless China pulls a fast one again, LOL

Note to self:

My next version might use straight IFs instead of EVERY to remove the compartmentalization.

#192

Or Vega postpones again at the last minute…

I went with (nextLaunch-$now)<=(1-minOffsetBeforeAlert) as my test [since minOffset is negative]. Just have to wait for another ‘opportunity’ :slight_smile:

#193

I went in the opposite direction… By totally removing my math from that trigger.

This line updates hourly:
pic

… and my trigger is now:
pic

Perhaps overkill, but my logs should reveal more as time passes.

Note: {nle} stands for {nextLaunchEarly}
(I’m running out of space, LOL)

Rocket Launch Notifications via API
#194

To be more clear, I actually left the trigger as it was. I now have this:

04%20AM
Screen Shot 2020-06-19 at 9.43.04 AM.png1352×216 26.4 KB

So I let the trigger run but then verify we are actually within time of the latest next launch before sending alerts.

#195

Ahh yes… I see… Basically a stricter version of my IF {hrsTolaunch} is less than 1

Keep in mind though that if a rocket ever launches early, you will miss the alert unless that first line of math is recalculated ahead of time.

#196

nextLaunch always contains the most recent downloaded data. If something launches and it is not in nextLaunch, I would miss it anyway.

EDIT: Oh, sorry. I understand what you are saying now. Yes, that is true.

#197

So I ran across a couple new problems. This only showed up for me because I am displaying all launches within the next week. Turns out China has a new launch coming up but the date is only estimated. So, at first I was seeing this:

02%20PM
Screen Shot 2020-06-19 at 6.58.02 PM.png1036×382 55.9 KB

So it looked like the third launch had already happened. Took me a while to diagnose but it turned out the logic to identify an estimate was not working. I’m not sure why. I tried comparing to a null string and to the word “null” but neither seems to flag that there was no date in win_open. Finally I used length(win_open)>10 to identify a valid date and otherwise use the estimate. then I had to add logic to know that an estimate was being use because the time was still relatively close (<168 hours). Now I have this:

39%20PM
Screen Shot 2020-06-19 at 7.56.39 PM.png1030×384 50.9 KB

The other problem I am having is the piston stopped logging anything a day or two ago. Even when I set to full, nothing is being sent to the log. Will have to figure this one out.