Presence Notification with Life360

I've read a lot in this forum particularly lately about Presence issues...and the difficulties with it. I'm a recent SmartThings refugee and really hadn't many issues with presence detection with my cell and Life360. I got Life360 installed on Hubitat and created a virtual presence with it, and it is working fairly well and accurate.

But while Life360 has been doing a good job setting my presence either Present or Away... I can't get notifications to work on my Cell with both Basic Rules and WebCore:


Hub Presence 3

And what I can't understand... if I open the virtual presence sensor Tom in Hubitat's devices menu, and push either Arrived or Departed ... both the Basic Rule and the WebCore script work perfectly and send a notification to my phone. I must be missing something bone-head simple... anyone? Thanks!

It would be good to see traces of this running.

In general you should not nest trigger comparison.

In this case, you could use all 'is' comparisons.

  • even though these are conditions, if a piston only has conditions webcore will make them 'triggers' by subscribing to the events..

You could also just make it two if statements, without using else.

I think this will show you what you expect.

As to notifications, on your hub you should install a notification device.

The could be pushover (a paid app), the HE mobile app, etc.

Then in webcore you define the push device to be the installed notification device. typically this notification device will have a mobile app (like pushover, or the HE mobile app), and that app would display the notification you send.

ok... but that wouldn't apply to the BasicRule script. It also doesn't explain why both scripts work properly when I force (push) arrive or departed in Hubitat's Device page. But I created another WebCore script and used "is" comparison and I have to leave shortly anyway to pick-up some pizza.

"As to notifications, on your hub you should install a notification device." - I did... my phone. It's my phone I want these notifications sent too. Again, my phone receives the proper notifications when I open the presence sensor in Devices and manually change the presence to either "away" or "departed"... and since this change also works properly when I actually do leave my house... why do the scripts ONLY work when it presence censor is manually changed by me and not Life360... I would think that if the scripts are incorrect... they won't work when tested manually... but they do and I get notifications on my phone.

I guess I would need to see 'medium' webcore logs for the runs that you see work or fail.

These are in the webCoRE IDE.

Also see:

It's a tiny script...it's basic. I also have the same script in BasicRule... it's listed above. Certainly, can't be a programming issue with the BasicRule script. and this same WebCore script works fine also in SmartThings! What could be the problem then with BasicRule, it's not user scripting? The problem is... neither script runs when Life360 changes the Presence automatically... but both scripts works flawlessly when I manually change the presence of the presence censor!

without seeing the webcore logs for medium, it is hard for me to say.

More data please.

Here are the logs when I manually change my Presence censor to Depart then Arrive...
1/8/2022, 11:45:52 PM +163ms
+6ms â•”Received event [Tom].presence = present with a delay of 42ms, canQueue: true, calledMyself: false
+112ms â•‘Runtime (5854 bytes) successfully initialized in 3ms (v0.3.113.20220105_HE)
+115ms â•‘â•”Execution stage started
+250ms â•‘â•‘Executed virtual command sendPushNotification (28ms)
+263ms â•‘â•šExecution stage complete. (148ms)
+271ms â•šEvent processed successfully (266ms)
1/8/2022, 11:45:26 PM +748ms
+4ms â•”Received event [Tom].presence = not present with a delay of 100ms, canQueue: true, calledMyself: false
+107ms â•‘Runtime (6614 bytes) successfully initialized in 89ms (v0.3.113.20220105_HE)
+110ms â•‘â•”Execution stage started
+166ms â•‘â•‘Executed virtual command sendPushNotification (33ms)
+180ms â•‘â•šExecution stage complete. (70ms)
+187ms â•šEvent processed successfully (184ms)
1/8/2022, 11:44:33 PM +497ms
+28ms â•”Subscribing to devices...
+77ms â•‘Subscribing to Tom.presence...
+100ms â•šFinished subscribing (75ms)
+138ms â•”Starting piston... (v0.3.113.20220105_HE)
+141ms â•šPiston successfully started (132ms)
1/8/2022, 11:44:29 PM +25ms
+75ms â•”Stopping piston...
+92ms â•šPiston successfully stopped (13ms)
1/8/2022, 11:41:18 PM +616ms
+4ms â•”Received event [HomeHub].test = 1641703278616 with a delay of 0ms, canQueue: true, calledMyself: false
+22ms â•‘Runtime (5858 bytes) successfully initialized in 5ms (v0.3.113.20220105_HE)
+25ms â•‘â•”Execution stage started
+91ms â•‘â•šExecution stage complete. (67ms)
+97ms â•šEvent processed successfully (94ms)
1/8/2022, 11:41:12 PM +632ms
+4ms â•”Received event [HomeHub].test = 1641703272632 with a delay of 1ms, canQueue: true, calledMyself: false
+22ms â•‘Runtime (5858 bytes) successfully initialized in 5ms (v0.3.113.20220105_HE)
+25ms â•‘â•”Execution stage started
+85ms â•‘â•šExecution stage complete. (60ms)
+92ms â•šEvent processed successfully (90ms)

I don't believe there are logs when I actually do leave and arrive from my home even though the Virtual Presence sensor does change correctly as per the Event logs of the Virtual sensor itself.

I got this problem resolved and learned a lesson. I found in the Hubitat's "Devices" Setting for the notification device (my cell phone) ... in the "In Used By" portion... the WebCore script wasn't there. Even though the device itself was listed in WebCore's settings when I selected all the devices I wanted WebCore to work with which included my cell phone. So, when I opened the app in WebCore, I added it under devices and verified it showed up when I opened phone in Devices. I never had to do that with SmartThings. In SmartThings you just need to select the devices in settings once, and you can create as many scripts as you needed with those devices. In any case, the scripted worked and as I suspected... it was going to a bone-headed mistake, and I was right. Thank you for your help!