Step 1 = Disable Automatic piston state
(found by clicking on the name when in edit mode)
Step 2 = Set piston state, such as:
You can see some examples at Wiki / Piston State
Step 3 = Trigger piston normally, and watch the text update a few seconds later
Pro Tip:
If there is an tile image displayed by the piston, the “piston state” will be seen when hovering the mouse over the tile.
I was trying to get the piston state to show my final message, but it’s not showing up. Is this not allowed?
You can not use a global that was just written…
(since it is not really written until the last line of code has executed)
IF @ReceivedMsg did not change in the last few moments, you can change line 240 to:
Set piston state to "Locations found. " + @ReceivedMsg
If @ReceivedMsg did change recently, then I would use local variables for all of your processing, and only convert the final results to global.
Happy Winter Solstice everyone!
Thanks to TWC’s seconds, my dials were more accurate this year than ever before…
When I examine the code, today’s day length was actually 6 seconds off from my actual location. I cannot blame my math… I cannot blame webCoRE… It is simply TWC reports the sunrise and sunset for a station a few miles away.
If anyone else wants to calibrate THEIR piston, I recommend running these two expressions today… right now… before midnight hits
$twcweather.conditions.sunriseTimeLocal
$twcweather.conditions.sunsetTimeLocal
Save the results to a text file, then later on, when you are bored, you can do the math to find the shortest day that TWC sees for your location.
Wow… Sometimes I am really impressed with my math…
Earlier this year, I estimated that using TWC for sunrise & sunset times will bring the results within 0.007% of accuracy…
The results for this year are in…
This Winter Solstice returned 0.042%… (instead of 0%)
(Which is exactly 6 seconds off, due to my location)
and of course…
0.007 x 6 = 0.042
The math could not be any more perfect!!
(not that anyone else cares, LOL)
First full day of Winter, and the new colors switched over on schedule…
The next six months, the dial will be moving towards the right…
We are exactly three weeks away from the Spring Equinox
(on the right gauge, it will be straight up at 50%)…
For the observant folks, the right dial moves the fastest over the next six weeks…
(meaning the largest increases in daylight day-to-day)
Interesting side note:
As observed here, over the next six weeks the dayLightLength increases nearly the same number of seconds on a day-by-day basis. (the link above elaborates on this)
Ten days until the Equinox.
Notice how significant the right gauge moved in the past 11 days!!
(that much change could take 5-6 weeks near the Solstices)
The Equinox has come and passed, but I stalled a few days to be able to showcase this…
Here is 9 days straight… (4 days before and 4 days after the Equinox)
I still find it interesting how the “equal day & night” takes place a few days before the Equinox… not during, as we are taught growing up… (how many days depends on your latitude)
Also worth noting is how the dayLengthPercent crossed 50% about 1.1 days after the Equinox…
I should probably mention that even though the right gauge only displays hours & minutes, the math behind the scenes are actually measuring precise seconds, so this is what is actually happening in real life.
(IE: the day after the Equinox, the dayLength was dead center between the two Solstices)
[ pic from today ]
This signifies that we have left the 6 weeks period with the largest increases in daylight day-to-day.
We are exactly half-way through Spring now…
For those of us north of the equator, today begins the 3 month quarter with the most amount of sunlight.
.
I’m still trying to think of a good name for this time period. (roughly May thru July)
This one’s not as easy as “Darkember”
I finally got around to creating this…now I need to find some time to create the gauges…
Now my wife will say I have over 14 hours of daylight to do work around the house. 
Sorry about this unintended side-effect, LOL
If it helps, here is my latest snippet for my gauge: (using the ‘Value’ field)
[chart-gauge min=0 max=100 greenFrom=0 greenTo=16 greenColor={colorWin} yellowFrom=16 yellowTo=84 yellowColor={colorYel} redFrom=84 redTo=100 redColor={colorSum} minorTicks=6 majorTicks=W…E…S|{dlpR}% 
]
{colorWin} and {colorSum} are static, while
{colorYel} changes based on what day of the year it is… Something like:
(isBetween(doy,172,356) ? 'colorFall' : 'colorSpring')
{dlpR} is actually {dlp} rounded…
isBetween(dlp,1,99) ? round(dlp,1) : round(dlp,2)
It shows a single decimal most of the year, but two decimals from 0-1% and 99-100%.
Let me know @Koyfam if you need any help setting this up…
It is definitely one of my favorite pistons…
(the references above are for the right gauge… with time removed for privacy)
I may definitely take you up on this offer. I’ll plaY around with it first and reach out if I get stuck or have questions.
I admit, I feel bad I have not uploaded a piston’s import code to draw those gauges… My complexity in that piston has reached a high level of personalization at this point, so I am unable to share it.
(For example: It pulls extra data from a private API, and references @globals that you do not have)
To share it here, I would have to copy it, and strip out 90% of the code first.
(would you guys even want this?)
I mean technically, it is only a single line of code to draw a gauge… Mine only got complicated because I wanted a different color for Spring / Fall. If you don’t care about that, it is literally just a single line of code referencing that @dayLengthPercent global.
In my defense, when I normally share pistons publicly, I try to do it after extensive testing, but before personalizing them to my household. (IE: You guys in the forums never see my final draft)
In this particular case, my gauge piston advanced too far before I was happy with it…
… and when I was happy with it, it was already too personal to share.
I just wanted to showcase this code snippet in action…
This tweak uses 1 decimal most of the year, but switches to 2 decimals during the slow time period.
(typically the 10 days on either side of the Solstices)
Monday:
Tuesday:
(note the real @dlp was 98.996% here)
Wednesday:
(the double decimals should linger for about 20 days, then switch back to a single digit)
Essentially, this gives me precision when I need it most, and a great birds-eye-view for the rest of the year.
Not sure if my math may be off but I’m already at 100% daylight. I got a basic gauge to work. Need to fine tune it.
If you are using $sunset and $sunrise for times, it always rounds down.
(IE: 6:30:59 is displayed as 6:30)
This removes a tad bit of accuracy…
For what it’s worth, sticking with the simple $sunset and $sunrise times should keep you within about 0.5% of total accuracy. (it depends on your latitude… My worst case last year was off 0.42%)
I am currently using:
$twcweather.conditions.sunriseTimeLocal
$twcweather.conditions.sunsetTimeLocal
which brings in actual seconds.
(although it requires a bit more math to calculate)
