Cell Phone Push Notifications for ISY

[MrBill]

@IT Solutions I don't have ELK but I do use Insteon open/close or Hidden door sensors on about 19 doors (it's less security than an actual supervised alarm contact but being in a small rural town where everyone knows everyone I'm ok with that).   I've added doors over time so I can't say I set it all up in 90 minutes, but If I had to redo it from scratch that's probably all it would take.....  

First create a network resource for every zone.  Leverage the COPY button, Edit the Name of the NR, then edit the body, then Save and COPY, rinse and repeat.  You can probably make 40 network resources in 40 minutes. 

Second create your program that sends the notification, mines pretty simple:

If

       $Away = $cTrue

and 'Front door' is switched On

then

       Resource 'open.FrontDoor'

Again, for the next zone leverage the COPY function, edit the name then the body of the program. 

 

Yep setting up 40 zones will take a few minutes.  but once it's complete you won't touch the programs again.... for years!

[DennisC]

1 hour ago, IT Solutions said:

 

@DennisCWhat are you using for Push Notifications?

Thank you.

 

As I stated above, I use email substitution for both text and email notifications. I have found it to be highly reliable with delivery in a matter of seconds.

While I think it is a personal  decision, my thought is for critical applications, or what I think are critical applications, the fewer devices involved means the fewer points of failure. If you are committed to Pushover, then @MrBillhas given you good examples to follow. In my opinion you are adding additional failure points (Network Resources, Pushover).

[IT Solutions]

@DennisC Delivery speed by email will vary greatly depending on what you are using for the SMTP server, and also your inbound email.  If you are going email to text, then a backlog on texts at your cell phone carrier can cause delays.  If you are getting notifications in seconds, you are doing very well.

One option we are considering is  Pushover for "general" notifications, followed by an email with more details.  Since either Pushover or email could be down (or delayed) at any point in time, using two different services increases the probability of getting prompt notifications.

Edited February 23, 2021 by IT Solutions

[MrBill]

@DennisC  It's interesting that you view email has less working parts to fail, I think it has more, the smtp server as well as the fact that at any given moment your email may suddenly be delayed or filter to junk.  I've never used UDI's default mail server (I did try at first but was having delivery issues), further anyone that was using UDI's default server in the second half of 2020 experienced several long outages.    That said you are correct, any method has it's potential for breakage.   

I actually didn't fess up above when I typed my front door notification program, I do send critical messages to my phone in multiple ways.  In addition to the Network Resource it send an email that is addressed TO: the email address that sent, and the 10digitnum@mms.att.net essentially critical messages arrive on my phone 3 times, once from Pushover, once as a text message and once in a separate email client (my regular email client is silent, the second email client is just for ISY notifications).

I also have a dual WAN router with an LTE modem for failover if cable dies.  Really the only place without redundancy is the ISY itself, to be honest I don't think I need it either.  The ISY itself has only actually stopped working and required manual intervention once in many years, and all that was needed that time was a simple reboot.  But yes it's definitely important to think thru all the possible points of failure.

@IT Solutions I created an email address just for the ISY to use at my isp, a gigantic cable company in philadelphia.  I use that email address for NOTHING else, period.  They also have an app that you can use with that account.  Essentially I use the same account as BOTH the outbound smtp account and the inbound notification account.  I send a few things 'email only' both FROM and TO the same email address.  Others I send FROM the account and TO: that account comma 10digit@mms.att.net.  and in a few cases like doors in away mode I also send via pushover..... usually I get all 3 but there are cases where one or the other or the other is missed or delayed.

[DennisC]

1 hour ago, MrBill said:

@DennisC  It's interesting that you view email has less working parts to fail, I think it has more, the smtp server as well as the fact that at any given moment your email may suddenly be delayed or filter to junk.  I've never used UDI's default mail server (I did try at first but was having delivery issues), further anyone that was using UDI's default server in the second half of 2020 experienced several long outages.    That said you are correct, any method has it's potential for breakage.   

I actually didn't fess up above when I typed my front door notification program, I do send critical messages to my phone in multiple ways.  In addition to the Network Resource it send an email that is addressed TO: the email address that sent, and the 10digitnum@mms.att.net essentially critical messages arrive on my phone 3 times, once from Pushover, once as a text message and once in a separate email client (my regular email client is silent, the second email client is just for ISY notifications).

I also have a dual WAN router with an LTE modem for failover if cable dies.  Really the only place without redundancy is the ISY itself, to be honest I don't think I need it either.  The ISY itself has only actually stopped working and required manual intervention once in many years, and all that was needed that time was a simple reboot.  But yes it's definitely important to think thru all the possible points of failure.

 

eMail, not so much, but text messaging has worked very well for me. Although, I do use email for backup notifications or if I want more of a trail of the notification. Anyway, my point was, I feel going through network resources and then the Pushover process added extra points of failure to the ISY notification. Final delivery process is the same, so since it works very reliably for me, I don't see the need to add the extra points of failure.

[DennisC]

1 hour ago, IT Solutions said:

@DennisC Delivery speed by email will vary greatly depending on what you are using for the SMTP server, and also your inbound email.  If you are going email to text, then a backlog on texts at your cell phone carrier can cause delays.  If you are getting notifications in seconds, you are doing very well.

One option we are considering is  Pushover for "general" notifications, followed by an email with more details.  Since either Pushover or email could be down (or delayed) at any point in time, using two different services increases the probability of getting prompt notifications.

As I said, text has been very quick for me. In addition, you still have all of the same delivery steps with Pushover as in direct from ISY, but you then add Network Resources and Pushover process before the delivery steps.

If it works for you or you have too many notifications for ISY to text, then that's fine. For me it is quick and reliable.

[MrBill]

1 hour ago, DennisC said:

eMail, not so much, but text messaging has worked very well for me. Although, I do use email for backup notifications or if I want more of a trail of the notification. Anyway, my point was, I feel going through network resources and then the Pushover process added extra points of failure to the ISY notification. Final delivery process is the same, so since it works very reliably for me, I don't see the need to add the extra points of failure.

We will have to kindly agree to disagree, which is perfectly fine, but I believe email has more points of failure:

ISY > SMTP server > heuristic (spam) message filtering > IMAP/POP server > End-point Client 

and unless specifically configured like I did it Points 2, 3, and 4 are likely different providers

ISY > Pushover API server > Apple Push Notification Server > End-point Client

(admittedly I'm lacking on the android message path, I assume it's just google server instead of apple server)

and for text messages:

ISY > SMTP server > heuristic (spam) message filtering > SMS or MMS mail gateway > endpoint server > client.

AT&T customer can attest to the fact the SMS or MMS mail gateway is a pain point.  

The only reasonable fail-safe method is to use multiple platforms and receive redundant messages.