There is an extra variable - statusDescr - that is not necessary but was put in place for debugging. It can be removed and the value directly from the API can be used in the tile.
Unfortunately pistons are saved and run entirely in the ST cloud, so if the cloud is down your tile wonât update and notification pistons wonât run
Hell, if the ST cloud is down, you wonât even be able to load the WC dashboard as it needs to pull its data from ST.
This tile has worked twice for me, including right now. Here is another example where I wish we could code something like âon clickâ open a URL (open status.smartthings.com). Then we can go get the details.
I suspect the moment the ST server is down, your webCoRE dashboard will not load, so you will never see the tile changeâŚ
In other words, your piston will likely only work if the ST server is up and running.
One loophole might be to have the piston send a notification (or SMS) to you if the server was down. I noticed this last time around, all my pistons on a timer continued to run, even though I could not access my dashboard for seven hours.
While I can not argue with the logic of if ST server is down⌠the fact is, this tile is still useful in most situations, as now - where it is a battery reporting issue, not the main server.
Maybe but I donât think so. The API seems to be hosted completely independent of the hosts for the actual production platforms. In my experience that is an Operations best practice.
Something changed recently and this status tile has stopped updating. Can anyone with a better handle on this web request stuff say why?
If I look at the api_URL in a browser, I see the status description âAll Systems Operationalâ at the end (like this âstatusâ:{âindicatorâ:ânoneâ,âdescriptionâ:âAll Systems Operationalâ})) but statusDescr seems to be ânot setâ.
It does not create a tile, but will provide alerts of outages and scheduled maintenace. Also updates piston state so you get a summary on your dashboard.
I use a modified version but I, of course, fell back to this one to verify the issue. Itâs definitely not working (for me) and always shows a thumbs down. hereâs the full logging for the first pass (It should show Thumbs Up for All Systems Operational)
4/20/2021, 12:00:06 PM +663ms
+1ms âReceived event [Home 109 2nd Ave].wc_async_reply = httpRequest with a delay of 0ms
+62ms âRunTime Analysis CS > 27ms > PS > 9ms > PE > 25ms > CE
+64ms âRuntime (41028 bytes) successfully initialized in 9ms (v0.3.113.20210203) (63ms)
+65ms ââExecution stage started
+76ms âânull
+77ms ââExecuted virtual command log (1ms)
+83ms ââExecuted virtual command log (1ms)
+89ms ââExecuted virtual command setVariable (3ms)
+94ms ââExecuted virtual command log (1ms)
+102ms ââCalculating (dynamic) == (dynamic) All Systems Operational >> (boolean) false
+110ms ââCalculating (dynamic) == (dynamic) All Systems Operational >> (boolean) false
+116ms ââCalculating (dynamic) == (dynamic) Major Service Outage >> (boolean) false
+142ms ââExecuted virtual command setTile (21ms)
+144ms ââExecution stage complete. (80ms)
+145ms âSetting up scheduled job for Tue, Apr 20 2021 @ 1:00:00 PM EDT (in 3593s)
+154ms âEvent processed successfully (154ms)
4/20/2021, 12:00:06 PM +442ms
+0ms âReceived event [Home].time = 1618934400000 with a delay of 6442ms
+84ms âRunTime Analysis CS > 64ms > PS > 7ms > PE > 12ms > CE
+86ms âRuntime (41023 bytes) successfully initialized in 7ms (v0.3.113.20210203) (85ms)
+87ms ââExecution stage started
+95ms ââCancelling statement #29's schedules...
+102ms ââSending external web request to: mf6lzdpt63q3.statuspage.io/api/v2/summary.json
+123ms ââExecuted virtual command httpRequest (22ms)
+124ms ââRequesting a wake up for Tue, Apr 20 2021 @ 12:00:30 PM EDT (in 24.0s)
+129ms ââExecution stage complete. (41ms)
+130ms âSetting up scheduled job for Tue, Apr 20 2021 @ 12:00:30 PM EDT (in 23s), with 1 more job pending
+139ms âEvent processed successfully (139ms)
4/20/2021, 11:10:12 AM +668ms
+1ms âStarting piston... (v0.3.113.20210203)
+491ms ââSubscribing to devices...
+664ms ââFinished subscribing (176ms)
+714ms âSetting up scheduled job for Tue, Apr 20 2021 @ 12:00:00 PM EDT (in 2986s)
That said, Iâll take a look at the one you posted but there seems to be a number of pistons posted in that thread. The one you published I expect?
Definitely not setting the variable also odd that it isnât even showing the log info data. Iâm wondering if the issue is related to async httpRequests (new to the most recent version of webCore).
Try adding a log info line after the GET request to see what response you are getting
Here is my log, the only difference is that I pulled all tasks out of the EVERY timer so I could execute via TEST and I am using a older version of webCore to avoid to web request issues.
4/21/2021, 8:40:48 AM +894ms
+1ms âReceived event [Home].test = 1619008848894 with a delay of 0ms
+43ms âRunTime Analysis CS > 19ms > PS > 11ms > PE > 13ms > CE
+46ms âRuntime (42525 bytes) successfully initialized in 11ms (v0.3.110.20191009) (43ms)
+47ms ââExecution stage started
+51ms ââCancelling statement #29's schedules...
+59ms ââSending external web request to: mf6lzdpt63q3.statuspage.io/api/v2/summary.json
+344ms ââExecuted virtual command httpRequest (285ms)
+351ms ââ[description:All Systems Operational, indicator:none]
+352ms ââExecuted virtual command log (1ms)
+357ms ââAll Systems Operational
+359ms ââExecuted virtual command log (1ms)
+364ms ââExecuted virtual command setVariable (3ms)
+369ms ââAll Systems Operational
+370ms ââExecuted virtual command log (1ms)
+379ms ââCalculating (dynamic) All Systems Operational == (dynamic) All Systems Operational >> (boolean) true
+388ms ââCalculating (dynamic) All Systems Operational == (dynamic) All Systems Operational >> (boolean) true
+400ms ââExecuted virtual command setTile (8ms)
+447ms ââExecution stage complete. (401ms)
+451ms âSetting up scheduled job for Wed, Apr 21 2021 @ 9:00:00 AM EDT (in 1150.656s)
+462ms âEvent processed successfully (462ms)
I rolled back to the previous version as it was causing probelms with several of my pistons, including the status piston I posted above. (That is my most recent version, not sure if I made any modification since I posted in that thread.)
If you are interested, lots of discussion on the issue here:
The problem definitely started recently so may be related to the change. It was working fine for years but stopped within the last week or two.
As soon as I saw the different URL, I tried changing to the one you used but with no change.
Iâll take a look at logging the httpStatusCode and see whatâs returned but Iâm guessing that the older version of Webcore would explain why it works for you. Your piston, posted at the top of the thread you directed me to, seems to be working fine so I can just work with that.