Push notifications only to those present in home


#1

1) Give a description of the problem
I have created a piston that regulates the AC Conditioner based on the temperatur. I have also set it up with Push Notifications to the three of us with mobiles. All of this works. But getting notifications on this when not at home could be an annoyance, and I would therefor like it if the notifications only was sent to those present at home. My problem is that I have not found out how to do this, nor have I managed to read myself up on it. Looking for help from you guys.

I have my phone setup with Smartthings Presencor Sensor and Webcore Presence Sensor. Have also defined my Home in Webcore.

2) What is the expected behavior?
Working as expected, not enough knowledge on how to to the rest.

3) What is happening/not happening?
As posted below, everything is working as designed. I would like to change the design, but not sure of how (just repeating my self now, sorry!).

4) Post a Green Snapshot of the pistonimage

5) Attach any logs (From ST IDE and by turning logging level to Full)
Not relevant at this time.


#2

I don’t think you can selectively send notifications now that ST removed the (unofficial) address book feature. You might be able to accomplish it with Pushover, there might be a cost associated for the app per platform.

Edit: There’s also the option of sending SMS, if you want to consider that route.


#3

Yeah, I went down the SMS-route.
Scrapped my piston, and “made” a new based on @ike2018 example piston.
I got this working (jey!) as intended. I`m sure it could have been made more elegant, but still learning.

Is there any way I can restrict how often text-messages get sent? I realise now that my wife would not be happy with receiving a text every hour, especially for something like this. I also realise that its not necessary with notifications for this excact piston, but for those where its relevant It would be nice to (know how to) define how often messages was sent, like once a day, once every two hours etc. Just using this as the example piston, since I know everything else is working.


#4

Here are two methods that I often use:

[1] Simple blocks (once a day)

This method can also easily be converted to once an hour, or once a minute, or once a week, etc…


[2] Complex blocks (for any duration)

If you want to only get alerts every TWO hours (or any delay really), a different technique would have to be used.

Here is a more complex version, but this one allows you to be more specific in how often it can run.
(by adjusting the very top variable, you effectively change how often the SMS block can run)

The ELSE block is optional, as is the other “Log to console” command. I just added them so you can see the results a bit easier. When I tested this, I just randomly toggled the switch on and off. The SMS portion of the code only ran once the right amount of time had passed since the last SMS.


#5

I’ve gone a bit crazy with notification abstraction. I’m not ready to share my work yet because I am still improving it. @ipaterson has also done this.

Basically I package my message up in a variable along with meta data like who and what type of message it is. I then pass that to another piston which sends the notifications. That piston evaluates my metadata and then either sends or queues the message.

If queued I have a piston waiting for some event like I turn a certain type of notification on with a simulated switch or I arrive home or at a certain time like 8AM. When that happens it sends the queued messages. If there are more than 3 it just emails me the notification.

I travel a lot for work, so using the webCoRE mobile presence sensor webCoRE knows exactly what timezone I’m in and it will also timeshift certain notification windows. For example if I don’t want battery low notifications when I am sleeping it won’t send them between a certain time period in the timezone I am currently in, ignoring what timezone it is at home. But others like security notification I get no matter what.


#7

A quick tip with notification pistons (or any other piston that you’re going to reuse throughout ALL of your other pistons): Create a very small “proxy” piston to receive the notification arguments and forward them to that big piston.

This just saved my bacon; earlier this week I lost my biggest piston that was in charge of sending notifications while I was testing advice I was about to give to someone else. No trouble to restore a piston from a backup bin or exported file, but the new piston will have a different ID. That means all of your pistons that call the old piston would need to be updated. However, since I had a simple proxy piston there was only one place that I had to update.

That advice is particularly useful if you are using a piston that someone else published. You need to be able to swap it out if they release updates. In my case this piston was under development so I had a public copy and a private copy with my personal contact info so I used the proxy to easily switch between the two and could just scrap my private notification piston and duplicate from the modified public version.

My proxy piston looks like this, this is the piston that everything else calls to send a notification: