Rocket Launch (Dual Piston fork)

#1

I took a quick cut at splitting @WCmore’s latest piston into two. I created one for calculations and the other for gauge and notifications. Interestingly, with checks and storing the global variables and the repeat variation, the calculations piston is still 18 chunks (same as the original). The gauge and notifications is 10 chunks. I used 7 global variables as seen at the bottom of the every loop in the calculations piston. Initialization of each piston is accomplished by pressing ‘test’ twice. Once to set the interval to 1 minute and the second to kick it off. After that it automatically adjusts to 4 hours nominal, 2 hours within 16-20 hours of launch and 20 minutes for the last 6-8 hours before launch (variation is based on the extra loop at old interval before actual update and random time of execution based on when started). Still needs clean up removing unused variables, etc. I am sure there is some optimization that can be performed but it’s a first cut.

Launch%203a
Launch 3a.png1178×2641 639 KB

Launch%203b
Launch 3b.png1178×1938 422 KB

EDIT: Updated pistons with @WCmore suggestions

EDIT 2: Found more errors. Pistons updated again-sorry!

When & where is the next rocket launch worldwide?
#2

Looking pretty good @guxdude, but two quick observations about your first pic…

First, since you removed the tiles, there is no need for {locS} up top or anywhere else…

Second, in your modified piston, (in the “Log twice a day” block),
it could potentially not log those details for days on end.
(IE: every 120 min may not fall in the 7am or 5pm hour)

You could resolve this during the final day by changing it to:
IF $hour is less than 2

  • This will log eight times on the day of launch
  • This will log twice a day at 120m intervals…
  • Note: at 240m intervals, there is still a 50% chance it won’t log at all

Maybe it would be better if that log was only written when there was a change noticed…

#3

Removed this and also {t} based on seeing it never got initialized so obviously no longer used in the first piston. I also removed all the uninitialized variables from the second piston (except for {null}). A lot of variables in the second piston were no longer needed. I had copied the original piston twice so had everything in both to start.

I changed to put the log outside the every and just have it log at noon every day. Not something I expect to look at most of the time. If others want more frequency, they can update.

Side note, the first piston is now only 17 chunks.

I updated both pistons in my post above.

#4

Note to self: With free-space to code properly, I think the most important thing to fix is the:
+ '0'
which will return an error as soon as the months get into double digits…
(Oct 1 thru Dec 31)

pic
pic.jpg739×48 9.37 KB

This was only my temporary solution to the month currently being returned in single digit.
(6 vs 06)

Untested, but I wonder if webCoRE would translate all of these properly?

2020-06-04T00:55Z   <-- We know this one works
2020-6-4T00:55Z     <-- Removed leading zeros
2020-012-04T00:55Z  <-- Added an extra zero out of curiosity

If the first two work, then the (+ '0') will not be a concern. I will just base it on the indexOf(“T”)

#5

EDIT: This one works:

format("%04d-%02d-%02dT05:00Z", integer($response.result[x].est_date.year), integer($response.result[x].est_date.month), integer($response.result[x].est_date.day))

For the current null values, it gives: 0000-00-00T05:00Z

#6

Realized this same problem existed for the request of new data. Updated to request new data in the first repeatMinutes period of the day.

35%20PM
Screen Shot 2020-05-31 at 11.08.35 PM.png906×216 21.3 KB

I updated above. Most recent import codes are yorto and tvrun

EDIT: Found another error. Now that I deleted un-initialized variables, I see I forgot the vehicle name so had to add another global to pass that for the gauge display.

#7

It’s coming along very nicely…

#8

Is there any interest in a second gauge for the next-next launch? All the data is there, would just need another set of global variables (too bad there aren’t global lists). Any pother features missing?

I did incorporate the change of the gauge for <10 hours to launch.

#9

For me personally, there is not an interest for a second gauge…
(but I wouldn’t mind if some of [1]'s basic data was in the log, or hover text)

#10

Kinda like that idea. Out of curiosity since I have never really dealt with tiles before, can it show more than 1x data point? For example have two needle indicators?

#11

I would love this too!
(and customizable needles (semi-transparent would be awesome)… and more than 3 colors… and 2 char tick marks… and…)

Sorry… I got carried away,…
*takes a deep breath*

There may be undocumented info that I am unaware of, but as far as I know, these are the current limitations for Google’s gauges as displayed in webCoRE:

  • One (identical red) needle per gauge
    (although you can remove the needle by pointing to a non-numerical)
  • We can use a maximum of three colors
  • There can be white space on either side of any color
  • Colors can overlap, with the later code “winning”
  • Overlapped colors are not blended, but the tick marks are harder to see
  • If you customize majorTicks, each will display as a single character
  • The dial can go low to high, or visa versa
  • 3+ dataPoints are visible on each gauge. (needle number & header/footer string)
    If the data is only a few chars long, it’s possible to cram 5 or 6 dataPoints.
    (9-11 characters or less seems to be ideal for the header & footer)
  • The font is not resizable (IE: too much data will run off the edges)
    This is why I often use the hover text on gauges. (by setting piston state).
#12

I think the Calculations piston references a variable t which is not defined.

See setting

Set variable {@globalLaunchState} = …

#13

:hugs: My bad. I thought it wasn’t 't used anymore and missed it in that definition. Below is a version with {t} restored. Unfortunately, it is now 19 chunks. Will look later if I can get it back down lower.

Launch%203a
Launch 3a.png1178×2621 637 KB

EDIT: I got this down to 18 chunks (code ie79z) but couldn’t get any smaller. I tried a lot of things but none seemed to reduce. I was able to eliminate the for loop for storing the tags which is what finally got it down one chunk. I replaced the for loop with this expression:

08%20AM
Screen Shot 2020-06-02 at 12.38.08 AM.png876×52 9.27 KB

Only difference from the for loop is the brackets as seen here:

45%20AM
Screen Shot 2020-06-02 at 12.37.45 AM.png1152×52 11.5 KB

I also simplified the {time} variable expression from this:

58%20AM
Screen Shot 2020-06-02 at 12.39.58 AM.png1920×54 12.6 KB

to this:

41%20AM
Screen Shot 2020-06-02 at 12.38.41 AM.png964×54 9.72 KB

which provides the same result.

Could get this to 17 chunks if I could come up with a simpler initialization scheme for the variable repeat time. Could require editing the variable to start at 1 and eliminate the initialization but that is not as clean.

#14

By luck, I got the calculations piston back down to 17 chunks so @WCmore can load it again (if he wants). Interestingly, this was accomplished by simplifying the creation of the notification and alert by using these expressions:

43%20AM
Screen Shot 2020-06-02 at 7.02.43 AM.png1100×86 20.2 KB

I had deleted {minOffsetBeforeAlert} from the calculations piston but it was used in creating the notification and alert. Rather than forcing everyone to keep these values in sync across the two pistons, I changed the strings created in calculations to a format string so the offset could be easily added in the gauge string. Long story you may not care about but here are the two updated pistons that should work properly (I also updated in the top post in this thread)

Launch%203a
Launch 3a.png1178×2641 639 KB

Launch%203b
Launch 3b.png1178×1938 422 KB

#15

What about putting some of this data in additional tiles? The log isn’t really visible while viewing the gauge.

#16

Some might prefer that…

Personally, on non-crucial data:

  • I like to have current info available 24/7,
  • with future info one step removed from sight.

Because of this, I would probably use the hover text (piston state) to see subsequent data…
(this is the quickest approach, with no clicks required)

Alternatively, one click to see the log showing other launches also sounds like time well spent.
(it’s not as fast as piston states, but it produces less clutter when hovering)

Heck, in that sense, one click to be able to see the variables in the define section could do something similar… Although I really like the “Mad-Libs” approach available to logs or hover text.

I’d probably insert this snippet into one of the 3 locations mentioned:
{vehicle1} launches from {loc1} in {daysToLaunch1} days
(IE: there’s no need to grab everything for [1])

Again, this is just my two cents… Once you fork a piston, it is up to you which direction it goes… :grin:
(and of course, once someone imports yours, it is up to them how they modify it)

It is always evolving…

If I may wax philosophical for a moment…

I believe that this flexibility is crucial, because every automation can have code added to (or removed from) it to make it “better” for that particular household. We are not buying “pre-packaged goods” here. We are converting ideas into unique creations.

To be totally honest, I am not sure if there will ever be (or would I want to use) a “one size fits all” when it comes to SmartHomes… The biggest appeal to me is the total customization, and lacking that, my interest would wane…

Edit: Added a link to this post