When & where is the next rocket launch worldwide?

#249

Have you thought about just using: $response.result[x].date_str

The Vega example above would return→ Jun 2020 . No additional formatting needed.

Edit: That is my plan for the tile string mentioned above.
#250

I do like that idea, but we have to be careful because even launches with full data will also have “date_str” in use.

I think the reason I was playing with “quickText” is because I really like the L- countdown there, and was trying to do something with that on known launch times.

#251

That is true, for example, the Florida launch scheduled tomorrow would return Jun 30

Excellent point

Using my boolean method, I would only be inserting the string whenever the data is estimated so anything with winOpen would be unaffected though the value would still exist.
#252

I know I promised everyone a double piston version of this piston, but with all of our discoveries, (estimates and last minute changes), I am really leaning towards only having a single gauge on my Dashboard.

I hope I am not letting anyone down with this decision… I still plan on improving this piston, but I think it would be ideal to have only one gauge, with basic info on hover for the next couple of launches…

#253

This is true. I actually don’t ever expect year to be 0 if there is an estimated date.

Most of the time the extra gauges do not add a lot but I do like the multiple gauges showing what is coming up in the next week. Putting it in the hover text most of the time is probably just as useful since so many future launches are estimated.

I don’t think you could let anyone down. You have pushed so many things in great directions. Really appreciate all you do for the community.

#254

LOL, yes… I meant that the time is ok to be estimated for a little while, as long as we know the day and month.

Thank you for this. I am a bit of a rebel, by nature, and like pushing the current boundaries into new realms… (IE: show me the “impossible”, and I’ll show you something that I have not tackled yet, LOL)

#255

I just updated my local piston… (taking @fieldsjm’s suggestion to the next level)
… but before I update this thread, how do you guys like the last 4 lines?

pic
pic.png242×614 28.8 KB

Note:
There’s no conversion on these later launches, so an early launch on the 10th, might actually be evening on the 9th (for your location). The proper time conversion kicks in once the data shifts to the first slot[0].

Note 2:
I dropped the (est) at the end of the string, because those extra characters forced a new line, and the results looked sloppy. I will just assume that all dates down there are estimates, and will only pay attention to the real times once the launch shifts to the top slot[0].

#256

I like this much better than what I was just playing with. I was experimenting with adding additional nfo lines. The issue is there are so many characters that the visual limit is really the next two launches. Yours is much more streamlined. Succinct yet complete.

My Current Tiles

image
image.png676×600 39.8 KB

#257

Thanks for the feedback… I have updated the original post with the latest improvements.

I guess a quick reminder for those updating:
I would change “6 past the hour” to another number, and consider adding a restriction to the voice alert…

#258

T-25 minutes to next launch!

EDIT: No voice over yet but countdown jumped back up to 30 minutes a little while ago…

#259

Almost complete with fuel load…

23%20PM
Screen Shot 2020-06-30 at 1.04.23 PM.jpg1824×1026 308 KB

EDIT: Winds confirmed good for launch T-3

#260

So incredible what these people do! The first stage steered itself autonomously to a landing in the middle of the Atlantic and hit the target.

12%20PM
Screen Shot 2020-06-30 at 1.20.12 PM.jpg2880×1800 518 KB

#261

So the delay screwed up my notifications and made me look at this again. Made some changes that I think might help. Can someone let me know any glaring issues?

For me the issue was that we had been past the initial notification window and that the delay had been changed after my last api pull/time calculation as well as before the next one. The trigger for “every hour at X minutes past” wouldn’t trigger again after the launch for me due to my X minutes past the hour setting.

This made me think back about when we first started this piston and an idea I had applied to an earlier version of the piston running every 20x minutes. The concept was that it appears every delay is at least 30x minutes into the future. So first of all I changed my interval to every 20x minutes. Secondly I didn’t want to spam the API though so I lowered the {hrsTolaunch} condition from 4 to 1.5. This should give me the time for the piston/time calcs to update in the event of another delay.

14%20PM
Screen Shot 2020-06-30 at 4.29.14 PM.png982×376 44.3 KB

Initially I had moved the “Always” block with the time calcs in with the first IF and API pull, but after making the change up top to the interval I placed it back where it was initially.

Lastly the other change I made is that my offset is less than the 20x minutes refresh so that it wouldn’t notify before a next change.

**Also, very awesome launch!! Was glad to be able to have caught that one!! :slight_smile: **

#262

With my piston above, this would only catch events happening within the next 30 minutes, or less… (90-60)

If you are hammering this every 20 minutes, it will catch events happening within the next 70 minutes, or less… (90-20)

(personally, I think moving to every 20 min is a bad move… Mine limits each day to 2-6 API pulls… Yours will pull triple that, and you will still miss last minute changes)

Remember, even NASA does not predict the weather, and the API owners need time to update the API. With both of these in mind, you can bet your last dollar that last minute changes will NOT be accurate here in webCoRE… (unfortunately, it’s the nature of the beast)

#263

You lost me there. Forgive me. With the piston set to “every hour at XX minutes past” it would not pull at the API and do the time calculation until that very trigger time as I understand it. So as the case was today the initial launch time of 3:55 EDT was updated to 4:25 EDT. My piston was set to run at 22 after the hour. So it was after the 3PM hour which still had the correct info but wouldnt have made it to the 4PM cycle since the rocket was already gone by then.

The way that I envisioned my changes to work is at the every 20x minute mark it runs the piston but only pulls at the API once a day and when {hrsTolaunch} is now a smaller window. Hence not hammering it as much if it was set to 4 and the 20x minute interval also.

If {hrsTolaunch} calculates to hours and compares to a value of 1.5 would it not only pull at the API once it crosses within that 1.5 hour window? So using an interval 20x minutes over 1.5 hours giving us 4x times at the most?

I could be way off hence why I defer to your expertise!

~~Edit. I figured out the “or less” part of your comment. I noticed that the {hrsTolaunch} is now a negative number. So for now I changed that condition to be {hrsTolaunch “is inside of range 1.5 and 0”.

And I am ok with that, at this point its more out of curiosity to learn for me! :sunglasses:

#264

I have no idea what you are running over there, but on my piston, this is false.
(if we need to troubleshoot your altered piston, please make a new thread for this)

On mine, “Every hour at 6 past” runs 24 times a day… but only pulls the API twice a day… The exception is, if {hrsToLaunch} is less than 4, it will update the API hourly during the final 2.9 hours.

There is absolutely nothing we can do prevent the launches from changing at anytime they please. But my piston will catch any change fairly quickly. (unless they bring the launch time forward, which so far, has not happened)

You will have 3 API pulls in the AM hour, and 3 in the PM hour… but you will have less opportunity to see a change than my original piston.

Yes, reducing 4 to 1.5 hours is a reduction, but yours will still pull two to three times more frequently than mine, with no extra benefit that I can see.

To elaborate, if your {hrsToRequest} is 3, and let’s say the launch is scheduled at 8PM, here are your API pulls for that day… The last column is when my piston pulls the API.

 3:06am  [yours]  [mine]
 3:26am  [yours]
 3:46am  [yours]
 3:06pm  [yours]  [mine]
 3:26pm  [yours]
 3:46pm  [yours]
 6:06pm           [mine]
 7:06pm  [yours]  [mine]
 7:26pm  [yours] 
                          7:30pm  [30 min notification using data from last API pull]
 7:46pm  [yours]
                          8:00pm  [Launch time = No piston run]
 8:06pm  [yours]  [mine]
 8:26pm  [yours]
 8:46pm  [yours]
 9:06pm  [yours]  [mine]

(if the API has not updated at this point, yours will continue pulling every 20 minutes… mine will pull every hour until the API updates)

… or, on a non-launch day:

 3:06am  [yours]  [mine]
 3:26am  [yours]
 3:46am  [yours]
 3:06pm  [yours]  [mine]
 3:26pm  [yours]
 3:46pm  [yours]

It actually only updates on the SECOND time it is inside that window… Which is why I subtracted 20 from yours (90-20=70) and 60 from an hourly timer (90-60=30)

You definitely want to use LESS THAN X.
If you only update from 0-1.5, it may take up to 11.9 hours to update after the launch…
(IE: whenever 3:06 rolls around next)

You know I always encourage this… I just want to encourage you to not make extra work for your SmartHome to try to overcome any delays in the API. The delays in the API are out of our hands entirely. This piston is not designed to fire off at the instant of launch… It is designed to give us a small warning, so we can watch the real action on the video feed somewhere else.

#265

The piston I am using is your latest publicly shared one. All I did was change that initial time trigger after it didnt work out for me today. I might not be explaining my point correctly. Allow me to use your described interval in another attempt.

Your piston runs “every hour at 6 past”, which like you said is 24 times per day, but only pulls twice from the API, plus the shortened window. For now I am ignoring the {hrsTolaunch} since that is a condition past that trigger. So using your piston setting here in a hypothetical situation here is what I think happened to me today.

1:06PM piston runs, doesnt pull from the API
3:06PM Piston runs and pulls API and verifies launch has been set for 3:40PM. piston updates the variables.
3:30PM The launch gets delayed by 30x minutes with a new launch time at 4:00PM
3:40PM piston sends notifications based on earlier API data
4:00PM launch happens
4:06PM piston runs again and pulls API

I’m still not sure that I am conveying it accurately. :persevere:

Understood by all means! The only thing that stands out to me is that in your example chart if any changes happen after 7:06PM the piston would have outdated data. It’s that window of the hour that I would be interested in narrowing, but as you have shown I wouldn’t want to do it at the expense of hammering the API.

Understood on this part, I did not calculate that portion of it.

Copy that! Makes sense (now).

Glad there is someone to point out the ledge to me! :joy:

As always, your insight and feedback are very much appreciated!

#266

This is a perfect explanation, and exactly how the piston was designed!
(well technically, it is designed to alert you in advance, not at the instant of launch)

At the 3:40 alert, you could have turned on the video feed for all the latest info and approaching launch.

Yes, I feel your frustration. Last minute changes throws a monkey wrench in to the mix.

I hope in the future, API’s can be “subscribed” to (like RSS feeds), so we can get automatic alerts when certain things happen. (push data instead of pull data)

But in the meantime, I still find most of this API quite useful.

#267

I think we are pretty safe here as we are triggering off the win_open which should be the earliest they can launch. They can only slip out from there, The only potential issue is the surprise china launches but nothing we can do about that.

I ended up moving the alert and notification into a separate piston. I created three global variables (alert time, alert message, and notification message) and then triggered on two things: Change of the alert message or “every notification time”. The change of the alert message run just updates the notification time so I am hoping that will catch any changes as they come up. This also moved one chunk out of my main piston.

#268

Off topic, but for the record, with this last launch, it took somewhere between 2 and 3 hours for the API source to update after the launch. (my piston pulled once per hour, but the API was slow to update)