How to check if device is online or offline

Leif_Jensen · 2020-11-12 11:51:45 UTC

Hi all

1) Give a description of the problem
I have an IKEA socket, that I want to be activated IF my Hue Lightstrip changes to online (electrical plugged in), and vice versa, deactivate IF the Hue Lightstrip changes to offline (electrical unplugged).

2) What is the expected behaviour?
I had a piston that used to work, but it hasn’t been working since the begining of October when the hub was updated. The piston used this condition: DeviceWatch-DeviceStatus to see if the device changed from offline to online and vice versa.

What can I do instead to check if a device changes state from online to offline, and offline to online?

3) What is happening/not happening?
Well, it stopped working. When i check the device info in SmartThings Groovy IDE, under Current States, and hover DeviceWatch-DeviceStatus the “tooltip” says that the it hasn’t updated status since Oct.5th.

**4) Post a Green Snapshot of the piston![image|45x37]

5) Attach logs after turning logging level to Full
You might notice some differences when comparing the log to the piston. This is because I tried changing some things, to for testing purposes, but I changed it all back to the original piston design, that used to work. Notice the two oldest logs from 05.10.2020 when the piston still was working.

12.11.2020 11.58.47 +900ms
+1ms ╔Received event [Mit hjem].test = 1605178727898 with a delay of 1ms
+98ms ║RunTime Analysis CS &gt; 21ms &gt; PS &gt; 5ms &gt; PE &gt; 72ms &gt; CE
+100ms ║Runtime (37447 bytes) successfully initialized in 5ms (v0.3.110.20191009) (97ms)
+102ms ║╔Execution stage started
+118ms ║║Condition #2 evaluated false (9ms)
+119ms ║║Condition group #1 evaluated false (state did not change) (11ms)
+128ms ║║Condition #4 evaluated false (6ms)
+129ms ║║Condition group #3 evaluated false (state did not change) (7ms)
+138ms ║╚Execution stage complete. (36ms)
+139ms ╚Event processed successfully (139ms)
16.10.2020 21.11.28 +941ms
+1ms ╔Starting piston... (v0.3.110.20191009)
+163ms ║╔Subscribing to devices...
+198ms ║║Subscribing to Køkkenbord lys.DeviceWatch-DeviceStatus...
+295ms ║║Subscribing to Elkedel...
+297ms ║╚Finished subscribing (142ms)
+353ms ╚Piston successfully started (352ms)
16.10.2020 16.54.25 +734ms
+0ms ╔Received event [Mit hjem].test = 1602860065731 with a delay of 2ms
+75ms ║RunTime Analysis CS &gt; 14ms &gt; PS &gt; 4ms &gt; PE &gt; 57ms &gt; CE
+78ms ║Runtime (37419 bytes) successfully initialized in 4ms (v0.3.110.20191009) (75ms)
+79ms ║╔Execution stage started
+96ms ║║Condition #2 evaluated false (10ms)
+98ms ║║Condition group #1 evaluated false (state did not change) (13ms)
+104ms ║║Condition #4 evaluated false (3ms)
+106ms ║║Condition group #3 evaluated false (state did not change) (4ms)
+111ms ║╚Execution stage complete. (32ms)
+113ms ╚Event processed successfully (114ms)
16.10.2020 16.54.16 +282ms
+1ms ╔Starting piston... (v0.3.110.20191009)
+178ms ║╔Subscribing to devices...
+212ms ║║Subscribing to Køkkenbord lys.$status...
+277ms ║║Subscribing to Elkedel...
+278ms ║╚Finished subscribing (107ms)
+328ms ╚Piston successfully started (328ms)
16.10.2020 16.09.24 +125ms
+1ms ╔Received event [Mit hjem].test = 1602857364123 with a delay of 2ms
+92ms ║RunTime Analysis CS &gt; 27ms &gt; PS &gt; 5ms &gt; PE &gt; 60ms &gt; CE
+95ms ║Runtime (37286 bytes) successfully initialized in 5ms (v0.3.110.20191009) (91ms)
+97ms ║╔Execution stage started
+112ms ║║Condition #2 evaluated false (9ms)
+114ms ║║Condition group #1 evaluated false (state did not change) (11ms)
+124ms ║║Condition #4 evaluated false (7ms)
+126ms ║║Condition group #3 evaluated false (state did not change) (8ms)
+131ms ║╚Execution stage complete. (35ms)
+133ms ╚Event processed successfully (133ms)
16.10.2020 16.08.58 +134ms
+0ms ╔Received event [Mit hjem].test = 1602857338131 with a delay of 2ms
+101ms ║RunTime Analysis CS &gt; 27ms &gt; PS &gt; 7ms &gt; PE &gt; 68ms &gt; CE
+104ms ║Runtime (37287 bytes) successfully initialized in 7ms (v0.3.110.20191009) (101ms)
+106ms ║╔Execution stage started
+139ms ║║Condition #2 evaluated false (26ms)
+141ms ║║Condition group #1 evaluated false (state did not change) (27ms)
+152ms ║║Condition #4 evaluated false (8ms)
+154ms ║║Condition group #3 evaluated false (state did not change) (9ms)
+160ms ║╚Execution stage complete. (54ms)
+162ms ╚Event processed successfully (163ms)
14.10.2020 21.04.31 +815ms
+0ms ╔Starting piston... (v0.3.110.20191009)
+134ms ║╔Subscribing to devices...
+164ms ║║Subscribing to Køkkenbord lys.DeviceWatch-DeviceStatus...
+218ms ║║Subscribing to Elkedel...
+220ms ║╚Finished subscribing (93ms)
+271ms ╚Piston successfully started (271ms)
14.10.2020 18.47.10 +972ms
+1ms ╔Starting piston... (v0.3.110.20191009)
+140ms ║╔Subscribing to devices...
+174ms ║║Subscribing to Køkkenbord lys.DeviceWatch-DeviceStatus...
+261ms ║║Subscribing to Elkedel...
+263ms ║╚Finished subscribing (132ms)
+315ms ╚Piston successfully started (314ms)
14.10.2020 18.22.48 +954ms
+1ms ╔Starting piston... (v0.3.110.20191009)
+165ms ║╔Subscribing to devices...
+203ms ║║Subscribing to LeKlint.DeviceWatch-DeviceStatus...
+406ms ║║Subscribing to Elkedel...
+407ms ║╚Finished subscribing (253ms)
+463ms ╚Piston successfully started (461ms)
14.10.2020 17.54.20 +270ms
+1ms ╔Received event [Mit hjem].test = 1602690860267 with a delay of 2ms
+161ms ║RunTime Analysis CS &gt; 23ms &gt; PS &gt; 4ms &gt; PE &gt; 135ms &gt; CE
+164ms ║Runtime (37095 bytes) successfully initialized in 4ms (v0.3.110.20191009) (161ms)
+165ms ║╔Execution stage started
+180ms ║║Condition #2 evaluated false (8ms)
+182ms ║║Condition group #1 evaluated false (state did not change) (9ms)
+191ms ║║Condition #4 evaluated false (6ms)
+192ms ║║Condition group #3 evaluated false (state did not change) (7ms)
+197ms ║╚Execution stage complete. (32ms)
+199ms ╚Event processed successfully (199ms)
14.10.2020 10.39.48 +970ms
+1ms ╔Starting piston... (v0.3.110.20191009)
+132ms ║╔Subscribing to devices...
+163ms ║║Subscribing to Køkkenbord lys.DeviceWatch-DeviceStatus...
+213ms ║║Subscribing to Elkedel...
+214ms ║╚Finished subscribing (90ms)
+241ms ║Cancelling condition #2's schedules...
+242ms ║Cancelling condition #1's schedules...
+266ms ╚Piston successfully started (266ms)
5.10.2020 14.46.57 +658ms
+1ms ╔Received event [Køkkenbord lys].DeviceWatch-DeviceStatus = online with a delay of 44ms
+69ms ║RunTime Analysis CS &gt; 21ms &gt; PS &gt; 4ms &gt; PE &gt; 45ms &gt; CE
+72ms ║Runtime (37109 bytes) successfully initialized in 4ms (v0.3.110.20191009) (70ms)
+73ms ║╔Execution stage started
+80ms ║║Comparison (string) online changes_to (string) online = true (1ms)
+82ms ║║Cancelling condition #2's schedules...
+83ms ║║Condition #2 evaluated true (6ms)
+84ms ║║Cancelling condition #1's schedules...
+85ms ║║Condition group #1 evaluated true (state changed) (8ms)
+87ms ║║Cancelling statement #7's schedules...
+104ms ║║Executed physical command [Elkedel].on() (14ms)
+105ms ║║Executed [Elkedel].on (16ms)
+111ms ║║Comparison (string) online changes_to (string) offline = false (1ms)
+113ms ║║Cancelling condition #4's schedules...
+114ms ║║Condition #4 evaluated false (6ms)
+115ms ║║Cancelling condition #3's schedules...
+116ms ║║Condition group #3 evaluated false (state changed) (8ms)
+118ms ║╚Execution stage complete. (46ms)
+119ms ╚Event processed successfully (119ms)
5.10.2020 07.36.22 +940ms
+1ms ╔Received event [Køkkenbord lys].DeviceWatch-DeviceStatus = offline with a delay of 55ms
+96ms ║RunTime Analysis CS &gt; 26ms &gt; PS &gt; 4ms &gt; PE &gt; 65ms &gt; CE
+98ms ║Runtime (37112 bytes) successfully initialized in 4ms (v0.3.110.20191009) (96ms)
+99ms ║╔Execution stage started
+108ms ║║Comparison (string) offline changes_to (string) online = false (0ms)
+109ms ║║Cancelling condition #2's schedules...
+110ms ║║Condition #2 evaluated false (6ms)
+112ms ║║Cancelling condition #1's schedules...
+113ms ║║Condition group #1 evaluated false (state changed) (8ms)
+119ms ║║Comparison (string) offline changes_to (string) offline = true (0ms)
+120ms ║║Cancelling condition #4's schedules...
+121ms ║║Condition #4 evaluated true (6ms)
+122ms ║║Cancelling condition #3's schedules...
+123ms ║║Condition group #3 evaluated true (state changed) (8ms)
+126ms ║║Cancelling statement #5's schedules...
+153ms ║║Executed physical command [Elkedel].off() (22ms)
+154ms ║║Executed [Elkedel].off (24ms)
+157ms ║╚Execution stage complete. (58ms)
+158ms ╚Event processed successfully (158ms)

REMOVE BELOW AFTER READING

WCmore · 2020-11-12 18:28:20 UTC

I am not looking at those logs,
(since much does not match the image displayed) …
… but based on what you wrote:

This animal rears his head every so often…
(perhaps an analogy will help)

Can you imagine if I programmed a smart phone to alert me when it’s battery died?

The only way to truly know, would be to have a third party device ping the phone periodically… and let that device alert us to a missed response.

Now I am not saying this is not possible… just that your triggers typically will not be directed at the phone (in this example)

In your case, replace my use of the word “phone” with your “RGB Bulb 2”.

TL;DR:

The RGB Bulb 2 (or any device on the planet) cannot tell you when it dies.

Leif_Jensen · 2020-11-13 07:12:21 UTC

My apologies, Sir. It was not my intention to agitate anyone with my trivial question.
Naturally I wouldn’t have dared asking, if I hadn’t trawled the web for a solution before disturbing The Committee with my problem.

I don’t think or expect an unplugged bulb, lightstrip or smart socket to be able to communicate anything. I expect the hub, however, being able to determine if a device is online or offline - nothing else makes sense.

If it’s SmartThings or webCoRE, that implemented the function/variable/event or whatever it’s called, there WAS a way of checking if a device was available with DeviceWatch-DeviceStatus, but this hasn’t been working since the first few days into October.
Ruling out that webCoRE or pistons are able to communicate with unplugged devices or the dead, this function must have used information from the ST hub about which devices are online or offline.

Since this isn’t possible anymore, I would like to know if there are other methods for a piston to determine the current state of a device.

WCmore · 2020-11-13 09:20:33 UTC

No need to apologize… It was a legitimate question, that did not agitate me in the slightest.
(I only gave the example so as to clarify what is going on behind the scenes)

This is the best approach… although it is rare to find a trigger that works automatically.
(we usually have to poll periodically to determine what is offline)

Unfortunately, SmartThings has blocked me from the new app, so I cannot give you a specific answer to specific methods… but usually, it is timer based, with a condition check.

Pantheon · 2020-11-13 09:27:04 UTC

What?

WCmore · 2020-11-13 09:37:47 UTC

Yea, it’s crazy.

More info here.

orangebucket · 2020-11-13 10:14:47 UTC

Polling for the current connectivity status of a device should still be possible with the $status “attribute”, and of course the REST API is always an option. However triggering a piston based on changes is another matter. I just can’t see how that is now possible for legacy apps.

Leif_Jensen · 2020-11-13 12:04:27 UTC

Since I’m still a complete newbie with ST and WC, most of what you just said right there, just went by me like a fighter jet going mach 2. I have tried that $status attribute, which I couldn’t get to work (most likely because I didn’t do it right). I have no idea what the REST API is.

I keep see folk mentioning legacy apps. I understand it’s somehow outdated apps, but which apps are we talking about? Is it SmartThings Groovy IDE or webCoRE, or something ghostly that mortals aren’t supposed to know about?
Is there something better/newer I should use/learn/switch to?

Please excuse me for my ignorance - I obviously got into this SmartThings/webCoRE/smart home circus quite a few years later than you wizzards, so what might be trivial for you, requires a big effort and many hours on my behalf, googling, trying, testing and failing before I accidentally stumbles upon something that actually works.

Thank you, @orangebucket and @WCmore - I really appreciate that you guys taking your time to answer my questions, even though the answers seems outta my reach.

WCmore · 2020-11-13 12:51:53 UTC

If you are looking to read-up on the subject of “offline devices”, there may be a dozen decent threads and webCoRE examples in this list.

Note: Most of those threads were created proir to the new API, so take the examples with a grain of salt.

fieldsjm · 2020-11-13 13:47:08 UTC

For reference, there was some discussion in the ST forum regarding DeviceWatch-DeviceStatus. Depending on the DTH, device are polled or even manually marked offline. We got the manual portion working in a Roomba DTH as far as the UI appearance in the new APP goes however IDE was very inconsistent in it’s representation of online status. Often listed as offline when the device was online in reality and in the new app.

TL;DR; DeviceWatch-DeviceStatus drives online/offline appearance in the new app UI but status in IDE is not reliable enough to based programming on (at least for now).

orangebucket · 2020-11-13 14:42:51 UTC

SmartThings makes available a function/method named getStatus() to SmartApps such as webCoRE that returns the connectivity status of a device, which these days seems to be simply ONLINE or OFFLINE. It is the same as the ‘Status’ displayed for a device if you view it via the IDE.

When you work with device attributes in webCoRE you will see that there is an extra one named $status, so you can have conditions like Back Door's $status is 'ONLINE'. When the piston evaluates that condition it simply replaces $status with the result of calling getStatus() on the device. So it isn’t a real attribute, it is just a convenient way of making the online/offline status available. As it is not a real attribute you can’t subscribe to it, so you can’t do e.g. Back Door's $status changes to 'ONLINE'. Well you might be able to do it but it won’t work.

The original architecture of SmartThings, also known as the ‘Classic’, is based around device handlers and SmartApps written in the Groovy programming language and running in the SmartThings cloud. This way of doing things is now being phased out, so it is also referred to as ‘legacy’. Although the dashboard is implemented on a third party website, webCoRE pistons are legacy SmartApps saved and running in the ST cloud in the same way that Smart Lighting automations are. The Groovy IDE is rooted in the legacy environment.

The ‘new’ environment exchanges the procedural library approach of Classic for a more typical https request/response type of API. So for example, if we use curl to illustrate the idea, getStatus() is implemented more like:

curl --header "Authorization: Bearer 31614b21-595c-41be-b9b7-528e14abcdef" https://api.smartthings.com/v1/devices/4b1c1124-837e-447e-a418-f2f70123456/health

An example response would be:

{"deviceId":"4b1c1124-837e-447e-a418-f2f70123456","state":"ONLINE","lastUpdatedDate":"2020-10-22T21:12:39.388+0000"}

You can do that in webCoRE if you want, though it wouldn’t gain you much.

Leif_Jensen · 2020-11-16 10:28:52 UTC

Thank you, all, for you effort in trying to help me, even though I think you have too much faith in my skills. Unfortunately this is apparently just too complicated for me to comprehend.
The wague descriptions and examples I can find via google doesn’t help me, and all this talk about legacy apps has just confused me even more.
I think I just have to accept that what used to be possible, is not possible anymore. And I’ve wasted some money on some hardware that is outdated and relatively unsupported and undocumented - at least for dummies.

If any of you can point me to some complete guide for dummies, maybe I can learn it from the very basics. It’s just that you speak a completely different language - maybe beacuse it’s easy for you to understand how it all works, and you assume it’s easy to anyone

Again thank you so much for taking your time, and I apologize that it was wasted on me.