Although as we’ve seen this weekend, ST/Samsung didn’t update the Status page.
And if the cloud itself is having issues, then…
As well as @Bloodtick_Jones’s piston above, I’m really liking @fieldsjm’s piston below. Clearly we make our own little changes, but hopefully soon we can have a best of the best…
Just a preference but since the summary json includes the status data at the very bottom; I would adjust to make only one initial GET request to the summary.json and process all from there. There would be no need for the second call, regardless of the data changes.
It would only require a change to the initial URL selection and deletion of the second web call. The data point for the status is the same regardless of which json, $response.status.description
Not sure if it has ever happened, but if the API fails, it might be worth have a default response based on http status code? Just a thought…
Very interesting ideas @fieldsjm, I like idea about if the API fails. Hey feel totally free to play around with the code, and please post results you’re happy with, WebCoRE is for everybody, and even if there’s 0.00005 per cent more efficient piston, I’ll happily swap them over. 
Not sure if it’s more efficient, but i’ve been tinkering with the code a bit. Added the httpStatus check at the top, note that if the summary get request fails, then I tried the status request. You’ll get a push notification if either one or both fails.
The remainder is still very similar, just arranged in a way that only sends notifications only if there is a problem (personal preference). The piston state will get set regardless and I’ve included the components in the state as well.
The reason I grabbed the status from top status and not summary was because a region might have a problem and you didn’t care but I wanted to update the piston itself and planned on adding a virtual switch in the upper section for ActionTiles notification. Here was the original thread.
Note: this also works for Ecobee notification and I have updating to have a generic version for both including multi-region support. webCoRE is cool.
@fieldsjm Looking good, let’s play with it for a few days. @Bloodtick_Jones is actually the brains behind the original piston, and he may not be finished, I’m sure the three of us can come up with the optimal piston, three brains are better then one.
I wasn’t sure if they would operate independently, one of the reasons why I kept both in the httpstatus check. Summary first, if issue, then status.
I don’t use ActionTiles but I like the idea. I have been experimenting with WebCore Tiles so a status tile there might be interesting too. I’ve also been messing with HousePanel (way more customizable) but I can see a status tile there too.
Do you mean Ecobee has a similar API? I would be interested in that too.
@Alwas I’m glad we share the same mindset. I come to the community as there are alot of awesome people doing good work. My pistons are ever evolving so it’s a great place for ideas.
Yes, “almost” the same - but you need multi-region type support to watch different components. Will post shortly.
Both SmartThings and Ecobee use the same reporting service, but the formatting is a little different. I wanted a more generic to use for both.
String [] was used because with a comma delimited string with arrayItem() didn’t work with the comma included in the SmartThing regions. It makes for a funky configuration and you should select ‘test’ to initialize the string array properly.
They both watch for the description to change and then will process the larger summary and send a more detailed email to the user. There is some Echo Speaks stuff in there too.
Ecobee does update regular and I caught an event yesterday. SmartThings seems to be more hesitant to publish outages.
SmartThings status piston:
Ecobee status piston:
@Bloodtick_Jones I appreciate all the hard work you put into these. I did similar edits to the ecobee version that I did for the ST, just for my own preferences (http check, notifciations only if problem, etc). I also noticed a value for scheduled maintenance, currently null, but I intent to populate that into the piston state and warning once we get some data there.
I did want to mention that I put together a more concise way of pulling the components. Three loops is some hard core coding work but it can be done in one.
Instead of using an advanced string, I set my desired components in a simple string variable (myComponents). The loop checks to see if $response.componenets.name is any of myComponents.
I attempted the simple string variable but the logic was not working for the smartthings port with the commas in “Europe, Middle East, and Africa”. The string array was the only way I could get it to index correctly.
But nice! (three nested loops was brut force for sure).
Updated my piston above to include alerts for scheduled maintenance as there is a valid data point currently.
Since our piston design is slightly different, I essentially just added:
Those errors are usually related to a missing variable. My guess is the global variable @EmailAddress is the problem, it would be the only variable not created by importing of the piston.
You’ll want to re-assign the myEmailAddress variable to something other than that global or create that global for yourself.
Duh! I had even looked at that when reading the thread here but I guess it just slipped my mind. On it. Thanks!
