I don’t have any PII in that code so I wasn’t worried about someone else viewing it or being able to import it. I wasn’t aware that others couldn’t import it to their instance.
When I use the green snapshot webCoRe strips out the URI used for the API call. Catch 22.
What’s your recommendation for sharing a piston like this? Paste the green snapshot and then adding the URI in the text here so other can paste it in when they import?
That works well… although I like to keep it attached to the image for future reference…
You can make the URL into a string variable up top in the define section…
(those are never anonymized, and works right out of the box)
or if the user can copy/paste, you can add it in a comment line…
I just reposted it with the URI in the update. I’ll probably go with your suggestion to move it to a string in the next update.
Thanks for your help and patience. My coding is fine, learning how to share it here was the struggle.
Wanted to report that all imported cleanly and I’m starting testing this out in my home! Great piston set!
One featureset I’ve seen elsewhere that I would like to see is a “weather factor” (cloud cover factor or lux factor or fog factor, etc.) that can offset these values. This would make it a bit better on cloudy mornings.
Imported as well and using these as new global variable conditions on lighting triggers. Thanks!
Thanks!
I’ve been working on some updates to the Astronomical API that creates tiles based on the data:
I’ll post the new piston code once I’m happy with it.
As for the WX info, none of that should change this API. I have been playing with the TWC data.
I suppose the TWC data could be used to alter the lighting piston (e.g. check hourly and if partly cloudy or cloudy, turn on the lights). Is that what you had in mind?
Honestly I’m thinking of an IF Cloudy THEN offset = offset + cloudoffset or something. That way I could set cloudoffset as 30. Only problem is limiting it to 100, but you seem way more experienced in that stuff that I am!
I see where you’re going now. Not sure it’d produce the effect you want but… buckle up 'cause here we go!
The available TWC data doesn’t tell us the type of cloud cover. 100% cumulonimbus is going to have a different impact to our lighting needs than 100% altostratus. In some instances, cloud cover can actually increase the ambient light level such as thunderstorm to the west reflecting light in the morning. All we know is the percentage of cloud cover.
Also, the TWC data cannot be used as a trigger:
It is unfortunate, but a weather alert cannot be used as a trigger. To get alerts for your area, you can program a piston to periodically make a query. (mine is set to run every 15 minutes, but other triggers can work as well, such as right before you go to work) Please program strategically so we don’t hammer the weather server too frequently. Any more often than 4 times an hour is a waste of resources and pointless for alerts. We don’t want to encourage SmartThings to start charging us for this data. (since they are billed for each query)
There’s no way to trigger a lighting event based on a weather alert. Granted, cloud cover isn’t a weather alert but the concept is the same, we can’t adjust the lights because the clouds are rolling in. If that’s what you’re after, getting a sensor that measures lux is the way to go. While we could set up a polling loop to get the current cloud cover condition, that is very costly from a resource perspective. I wouldn’t set this up to check the current conditions every 15 minutes.
The best we can do is to use the $twcweather.conditions.cloudCoverPhrase variable to get the forecasted cloud cover when a lighting event is triggered and adjust based on that.
Assuming 100% cloud cover is “dark” and 0% cloud cover is “light” we can use the forecasted conditions (they update twice a day) to create the adjustment factor you seek. We can adjust both the day_level and twilight_level based on the percentage of cloud cover. The night_level is our absolute lowest setting. Once night hits, we wouldn’t need to make any adjustments based on cloud cover.
Here’s a chart showing the adjustment:
Examples:
Here’s an updated piston that has the adjustment ready to go: r3y84
If you wanted a less dramatic change, you could adjust the $twcweather.forecast.daypart[0].cloudCover[x] values by dividing them by two (or three) which would cut the effect proportionally.
I hope this is helpful. Let me know if you give it a try and it does what you’re after. As always, YMMV.
UPDATE:
I’ve updated the original piston with some additions (tiles, status, etc.) and split it in to two separate pistons per this thread.
Astronomical Data API: tybg
Astronomical Data Synodic: e8kiz
The major change is having the parent piston restart the child pistons (or any others you create) so they immediately subscribe to the updated times from the API call.
You’ll need the synodic API if you want to do any triggers based on the twilight and/or shabbat booleans. Update the API piston (lines 69-73) with any of your pistons that use the global variables and you’re good-to-go.
:Jawdrop: thanks!!! This is amazing. Implemented widespread throughout my home. Will report back if any issues arise!
i stumbled upon this page and found it interesting and would like to use the piston.
i was able to import without issue.
my problem is manually creating the global variables, say for @astronomical_twilight_begin for example. When i create the variable name “@astronomical_twilight_begin”, which I set with the ‘date & time’ data type. I am not sure what the value should be? Is it an expression? If so, is that the one defined on line 48 in the piston? Or is the value a date and time I manually set?
thanks
edit: issue resolved by leaving the value blank once the date and time variable has been created with a name for the variable itself.
Sorry for the delay, I was AFK for a few days.
Glad you got it sorted. Yes, just create the variable as “Date and Time” and set the value to “Nothing selected.”
Hello, I am seeing a problem with this piston after updating Webcore recently.
When the piston is executed I a seeing a ‘status 500’ error:
Anyone else experience this problem? And what the fix is? It’s actually impacting my routines that are location based and on time of day.
Here’s what the piston looks like:
Thanks
This is external to WebCoRE and the piston. It looks like the SSL certificate at sunrise-sunset has expired:
This has happened once in the past that I can remember. I’ll bet your noticing was just coincident with the WebCoRE update since it happened less than a week ago.
There’s a simple fix. Just change the API string from HTTPS to HTTP:
Current:
https://api.sunrise-sunset.org/json?lat={$latitude}&lng={$longitude}&formatted=0
Fix:
http://api.sunrise-sunset.org/json?lat={$latitude}&lng={$longitude}&formatted=0
There’s really no need for SSL, it’s just a best practice. Moving back to HTTP will make the piston work again and bypass the need for a valid SSL cert.
Hello, has there been an update to the API? Earlier this morning the piston did not complete and there is an error logged in webCore. See screenshots below. At first glance, it doesnt appear to be related to the certificate error you looked into back in July.
Thank you
No, no change to the API nor is it the certificate error again. The error code is right there in the log. It’s a simple timeout error. Nothing really to do apart from waiting for it to run again tomorrow.
I checked my log from this morning and my instance ran fine. Something between your hub and their server just timed out. It’s really rare but I’ve had it happen a couple of times over the past couple of years.
I do have an error check in there so the global variables will retain yesteday’s values if there is an error. This way everything still works but we lose some of the hyper-precision of what this API provides over the internal sunrise/sunset calculations. You probably wouldn’t even notice for a day or two. 
If you wanted to, you could create a loop that would give it a second try before failing and/or send a notification if the status returned wasn’t 200 (OK).
appreciate the response.
okay.
I may just implement a loop to retry in case of initial failure.
thanks
Happy to help.
