Interesting thought experiment. I wasn’t able to get into the full logic of the API but it appears to be calculating based on lat/long so theoretically more accurate to physical location?
Anyway, today, the sunrise API is 14 seconds earlier than the TWC data, north-west at approximately 2.2 miles is a weather station. Plugging in those coordinates into the API = almost identical data to the twc data (1 sec) .
If that is the right station, and we reverse engineer my previous formula, that estimates your GPS latitude somewhere between 36 and 44 degrees. (either north or south)
Note, I am not trying to blast your personal info here…
I’m just making a playful guess based on partial data.
I bet with a few days worth of data, we could estimate the latitude within one degree. (however, longitude will never be revealed unless you also included the actual times…
… and even then, it would only tell you how far east/west in any given timezone)
I thought SmartThings captured GPS coords when determining our Home location. (Although I wonder at what level of precision that data is passed to $twcweather requests)
Just to follow up on this from a few days ago. As I studied the numbers it appeared my DLP was still not changing daily. Digging in, I found that, even though I got all the times down to seconds, webcore still wouldn’t do all the right math with those times and was truncating. So I converted my shortest and longest day to seconds for the multiplier and then current day all using your formula and now I get (I think) a more accurate number. Today it says I am at 99.82% of max. Makes sense since max should be in a few days. Thanks!
Regardless of what it represents, the math on the two time variables is done correctly down to the second. Perhaps the real question is what is it casting those two time variables into to be able to do the math properly when it can’t do it for an actual time variable?
I believe the time variable doesn’t have a problem with storing seconds. In fact I believe I have narrowed the issue down to the cast function from string to time (or datetime). I created the test piston below and it shows whenever you cast from string to time, seconds are lost. Casts from time to integer (see seconds and milliseconds calculation) or integer to time (see ‘…S’ variables) retain the seconds. Note when there is not cast (’…NF’ variables) the seconds are also retained. Also, in answer to your question above, the dynamic version is using string because that is the output of formatDuration. In the case of dynamic data, no cast is performed.
And now, sorry for diverging so much from the real topic of this thread.
I noticed an issue with my length of day. Everything is calculating correctly based on $twcweather sunrise and sunset values but when I go look at timeanddate.com/sun for today, the daylength is off. I noticed this because watching the DLP (mine currently 99.86%) it did not seem like I was going to make it to 100% by Saturday which should be the summer solstice. Currently based on $twc, I get a day length of 14:36:47. When I look at timeanddate.com, it indicated that day length should have been two days ago:
True, I was looking at the final conversion from string to dynamic, time, or datetime. It is not as obvious what else is going on. formatDuration creates a string in a particular format given an input but not clear where the conversion happens in that process. The fact that the formatDuration conversion works, however, could be shown by the success of the dynamic type assignment where it accepts the output ‘as-is’.
I saw that and, unfortunately missed out 6 months ago. I just added in yesterday logging the day length to google sheets (since I had that worked out ). Now I can’t miss the shortest/longest days in the future. And I can do plots!
When I originally created this piston, I scanned the next 15 years in the future, and while the day of month changed often, the max and min dayLengths were all within 2 sec of each other. (most within 1 sec)
I went with the extreme values, with the intention of preventing the dial from ever going outside of 0 - 100%.
… but I still think calibration is wise to bring balance between the two sources.
I added in a block of code just to compare last short/long vs each days value and update as needed. At least I know it will always be accurate.
In reference to the variable conversions, I updated my piston to manually calculate all data points in ms (decimal). I don’t use time at all. Using formatDuration only to get a conventionally formatted string (xx:xx:xx) for quick visual reference.