Note to self…
I just noticed a graphical bug that has no impact on reliability, but noting it here for future reference.
The hover text at the moment starts with:
╔ China in 48 hrs ╗
╚ (Mon @ 12:4 PM) ╝
This second line is only for display purposes, and translates to local time of 12:04pm
(I do not have the room to add logic for an extra zero, and the math is still spot on, so I am leaving it for this version)
It should only be noticed on about 17% of launches… (:00 thru :09)
No logic required. You just need an extra ‘m’ in the {time} format string:
------------------------------------------------------------v
formatDateTime(nextLaunch,"E @ h:mm a")
EDIT: I forgot you use this longhand version but still just need an extra ‘m’:
----------------------------------------------------------------------------------------------------------------------v
' @ 'formatDateTime(nextLaunch,"h")':'formatDateTime(nextLaunch,"mm")' 'formatDateTime(nextLaunch,"a")
My expression above produces the same result in a shorter form.
MORE EDIT: If you use the shorter form above, you need to remove the formatDateTime for day of week from the piston state expression. I combined them. I also created a new variable {longTime} with ‘EEEE’ to use for the voice alert.
I’m suddenly getting double hover text. Have you seen this before? It doesn’t happen with my day length gauges.
Double hover is when your Dashboard has not fully refreshed.
(although I have never seen it in multiple colors before)
When I see double hover text, I hit Ctrl-F5 to do a hard refresh.
(it always clears it up)
Note: This will not execute the piston… It’ll just re-draw the Dashboard images.
Yup, but I still got the notification for the thursday Vega launch. "NextLaunch’ variable is correct for thursday but it still just notified me, maybe a fluke in last minute API change where the notification was already scheduled based off the delayed Chinese launch?
Yes, I was just trying to make sense of it myself. Once thing I note, the launch was at 7:05 for me and I was updating at 3 minutes past the hour so it didn’t start pulling new data until just over one hour before launch.
6/15/2020, 6:33:59 PM +75ms
+1ms ╔Received event [Las Vegas].time = 1592271240000 with a delay of -925ms
+2879ms ║Vega launching in 30 minutes
+2886ms ║Setting up scheduled job for Mon, Jun 15 2020 @ 7:03:00 PM PDT (in 1738.04s), with 1 more job pending
+2895ms ╚Event processed successfully (2895ms)
6/15/2020, 6:02:59 PM +70ms
+1ms ╔Received event [Las Vegas].time = 1592269380000 with a delay of -930ms
+1273ms ║API pulled = An Arianespace Vega rocket will launch the Small Spacecraft Mission Service (SSMS) POC mission on Friday, June 19, 2020 at 1:51 AM (UTC).
+1461ms ║API pulled = A SpaceX Falcon 9 rocket will launch the Starlink-10 mission on Monday, June 22, 2020 at 10:20 PM (UTC).
+1825ms ║API pulled = A SpaceX Falcon 9 rocket will launch the GPS III SV03 (Columbus) mission on Tuesday, June 30, 2020 at 7:55 PM (UTC).
+2038ms ║API pulled = A China Long March 3B rocket will launch the Beidou-3 GEO-3 mission. The launch date is currently targeted for June, 2020 (UTC).
+2289ms ║API pulled = An ISRO GSLV-II rocket will launch the GISAT-1 mission. The launch date is currently targeted for Q2 2020 (UTC).
+3201ms ║Setting up scheduled job for Mon, Jun 15 2020 @ 6:34:00 PM PDT (in 1857.73s), with 1 more job pending
+3208ms ╚Event processed successfully (3208ms)
6/15/2020, 5:02:59 PM +66ms
+0ms ╔Received event [Las Vegas].time = 1592265780000 with a delay of -935ms
+924ms ║Setting up scheduled job for Mon, Jun 15 2020 @ 6:03:00 PM PDT (in 3600.011s), with 1 more job pending
+932ms ╚Event processed successfully (932ms)
6/15/2020, 4:02:59 PM +134ms
+0ms ╔Received event [Las Vegas].time = 1592262180000 with a delay of -867ms
+1178ms ║Setting up scheduled job for Mon, Jun 15 2020 @ 5:03:00 PM PDT (in 3599.689s), with 1 more job pending
+1186ms ╚Event processed successfully (1186ms)
6/15/2020, 3:02:59 PM +92ms
+1ms ╔Received event [Las Vegas].time = 1592258580000 with a delay of -908ms
+1243ms ║API pulled = A China Long March 3B rocket will launch the Beidou-3 GEO-3 mission on Tuesday, June 16, 2020 at 2:11 AM (UTC).
+1445ms ║API pulled = An Arianespace Vega rocket will launch the Small Spacecraft Mission Service (SSMS) POC mission on Friday, June 19, 2020 at 1:51 AM (UTC).
+1645ms ║API pulled = A SpaceX Falcon 9 rocket will launch the Starlink-10 mission on Monday, June 22, 2020 at 10:20 PM (UTC).
+1838ms ║API pulled = A SpaceX Falcon 9 rocket will launch the GPS III SV03 (Columbus) mission on Tuesday, June 30, 2020 at 7:55 PM (UTC).
+2037ms ║API pulled = An ISRO GSLV-II rocket will launch the GISAT-1 mission. The launch date is currently targeted for Q2 2020 (UTC).
+3037ms ║The next launch is scheduled for Mon, Jun 15 2020 @ 7:04:00 PM PDT (4 hrs)
+3037ms ║Beidou-3 GEO-3
+3037ms ║China plans to launch Long March 3B, from Xichang Satellite Launch Center, China, on pad TBD.
+3037ms ║A China Long March 3B rocket will launch the Beidou-3 GEO-3 mission on Tuesday, June 16, 2020 at 2:11 AM (UTC).
+3037ms ║null
+3037ms ║Tags: Navigation Satellite, No Live Video Expected, Series: BeiDou-3
+3046ms ║Setting up scheduled job for Mon, Jun 15 2020 @ 4:03:00 PM PDT (in 3597.863s), with 1 more job pending
+3062ms ╚Event processed successfully (3062ms)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.
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.
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.
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)
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. 
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:
............... 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)
LOL!! Figures, it was going all too smooth! 
Understood, updating mine to mirror your temporary fix as well.
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?
yea, that’s the tricky part with using math in a trigger…
trigger until it does the math…triggers…triggers it)
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?
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…