Notifications

[James Peterson]

4 hours ago, beninsteon said:

 

@James Peterson your agave service also looks great. Let me know when it's ready for mass consumption. I would also be happy to be a beta tester here. I'm looking for notifications on variables (leak sensor tripped, fire alarm on, garage door left open, etc).

Ben

 

18 minutes ago, Jimbo said:

Yes, that's been peoples reason for years now, but once you purchase the app you get 7500 messages for free a month for each 'app', it's been working great for many years.  It uses the Google Messaging service FCM which does have a cost, so they could start charging at some point.  I think @James Peterson is planning to use FCM as well, but would be best to include that as part of the portal and allow ISY to send FCM messages directly and Agave could receive them.  Everything will rely on a service that supports push messaging so it doesn't kill your devices battery.

 

Yes, my system is using FCM.  It is was meant to just be a proof of concept, but it may just work.  I am a least a few months away from beta testing, but I will be posting more details on my slack channel for anyone interested in testing when the time comes.  This will be available for both iOS and Android.  Android is being developed now with iOS to follow.  I plan on having them both ready before I start enrolling testers.  So far I am working simple rules [Device action happened] I hope to add other types in the future. 

[Javi]

2 hours ago, Michel Kohanim said:

All, need more clarification and requirements as my conversations with James are not entirely related. Just for clarity, all ISY Portal accounts that have links to Echo and Google Home do subscribe to ISY at all times and keep the subscription open.

With kind regards,

Michel

I cam across this thread while looking for something else so my comments are not related to Agave and will be happy to discuss this in another thread if requested. 

So here are my thoughts:

Please correct me if I'm wrong but It is my understanding that sending downstream messages with FCM is at no cost. I send these messages all the time and am not charged.  I am changed (Google Cloud) to host the server which holds my keys and allow users to send messages to their phones. 

 

So, Since UDI already has a server running it would be possible for UDI to send these downstream messages at almost no cost aside from set up.

 

I think it would be beneficial to all UDI customers if UDI held it's own FCM keys and had simple IOS and Android apps which receive messages. I can help build an open source Android app as an example or for UDI to use but have limited experience with iOS.

[beninsteon]

4 hours ago, Javi said:

I think it would be beneficial to all UDI customers if UDI held it's own FCM keys and had simple IOS and Android apps which receive messages.

Yes, agree!

[Michel Kohanim]

Hello all,

We'll definitely look into it since it makes sense to have ISY Portal have this capability. The development is probably most time consuming for adding filters (we don't want to send everything). 

With kind regards,
Michel

[jfai]

Here are some of the reasons that led me to develop my own message relay service, running locally on an RPi.

1. Central administration and storage of authentication headers, recipient credentials. No duplication of headers in many network resources. Same for transport-specific configuration values, e.g., type of message, channel id.
2. Message templates: 'raw' variable values and device state values (e.g. Elk) don't result in readable messages unless multiple network resources are used for the various state values. Any type of ISY node/module state value can be substituted in message templates (numbers, strings, …). Multiple substitutions per message. Messages are timestamped by the relay service - no need to format the date and time in each network resource.
3. The messages are rendered/formatted according to the idiosyncrasies of each transport. 
4. Changing message templates does not require rebooting the relay service nor the ISY.
5. Support for publish-subscribe and for point-to-point transports.
6. Multiple recipients (family members), with different preferences for notifications and transports. Example: one recipient may prefer SMS over Pushbullet, and most recipients only want to receive alerts and warnings. Others may want informational messages and all details, maybe temporarily.
7. Prefer not to require yet another app for ISY notifications - recipients already have apps for notifications for other purposes.
8. Fallback transports, with ultimate store and forward in case of an Internet outage. ISY only sends one request, the relay service takes care of pushing to all transports and recipients with well-defined behavior in case of transient or permanent failures.

[Michel Kohanim]

@jfailenschmid,

Quite impressive. Is your service reusable/extensible?

With kind regards,
Michel

[jfai]

It's a Node JS app. It's running happily for a few weeks now. I'm still working on extensions, time permitting. It has a plug-and-play interface for transports. Not sure what you mean by reusable & extensible. Jimbo and I had a short exchange about collaborating. I'm thinking about the feasibility to make this available to others. The challenge is to find the time to write documentation and setting up a GitHub project or similar. Also checked into hooking into the Polyglot universe, not sure about that one. 

[Michel Kohanim]

@jfailenschmid,

Thanks so very much. What I mean is that whether or not we can use it and include it in ISY Portal and licensing etc. Since it's node.js based, it'll work very well with ISY Portal and might reduce our development time.

With kind regards,
Michel

[bmercier]

I'm currently looking at a possible implementation as well, and I'd like to share 3 ideas.

Idea 1: Polyglot Node server

For simple notifications, we could use a node server. The messages would be configured in the custom params. Then, we could create one node per notification text, and a control would be used to trigger the notification. We would need to have a convention for the content of the params, as they would need to hold things such as a node name, and the actual notification text. 

Pros:

• Does not need portal, if running the nodeserver locally
• Easy to use in programs

Cons:

• No variable substitution
• Configuration in the custom params possibly a bit "cryptic" if we need to have both the destination and notification text in the same field.

 

Idea 2: ISY Portal notification service.

The idea here would be to use the existing ISY network resources to trigger a new portal messaging API. The advantage would be total control over the messaging conditions (using ISY Programs), and the possibility to use variable substitution in the notification text. The network resource would need to be a POST, with a specific portal URL, and the body would need to have a specific format which specifies the destination and the message content. We may also have to change the content-type header as well, given that the default is url-encoded content.

Pros:

• Complete control over triggering conditions
• Variable substitutions

Cons:

• Configuration of network resource a bit harder (The first one. The others could be copied)

 

Idea 3: ISY Portal based configuration

The idea would be to have everything configured in ISY Portal:

• Triggering conditions
• Destination
• Notification text

Pros:

• Easy to configure, less error-prone

Cons: 

• No variable substitutions
• Triggering conditions will not be as extensive as what we can do with ISY Programs
• Require a permanent subscription (which is already the case for users using GH or Echo)
• Requires more development

 

What do you think?

Benoit

[Charlie_Morlock]

Idea 2 seems best. Will allow us to exploit full power of ISY (programs, variables...) only downside would be creation of NR, but, as you pointed out, you can copy them.

Perhaps even provide a wiki with templates ...

Sent from my SAMSUNG-SM-T377A using Tapatalk

[Javi]

@bmercier   I think this should be made for novice users as advance users can easily implement notifications using existing resources.   This should not require the user to understand code, much like the current "Emails/Notifications" available from the UD Admin Console.  I understand that it may not be practical to implement notifications in the same manor (at least not short term) as "Emails/Notifications". So, which option would provide the best path for future implementation into  the Admin Console?

[Jimbo.Automates]

I have a node server that is like number one, but different and has part of number two as well. I wanted to release a preliminary version this week but haven't had time. It was very simple so I can put it out and see what you think.

Sent from my Pixel 3 XL using Tapatalk

[DennisC]

I like the idea of including variable substitution, but having to use the portal. I prefer to keep everything possible in house.

[bmercier]

19 hours ago, Charlie_Morlock said:

Idea 2 seems best. Will allow us to exploit full power of ISY (programs, variables...) only downside would be creation of NR, but, as you pointed out, you can copy them.

Perhaps even provide a wiki with templates ...

That's also the approach I would prefer, but first I was wondering if that's what most users would like to have.

Benoit

[bmercier]

18 hours ago, Javi said:

@bmercier   I think this should be made for novice users as advance users can easily implement notifications using existing resources.   This should not require the user to understand code, much like the current "Emails/Notifications" available from the UD Admin Console.  I understand that it may not be practical to implement notifications in the same manor (at least not short term) as "Emails/Notifications". So, which option would provide the best path for future implementation into  the Admin Console?

Option 2 is the most flexible option, and eventually the admin console could be enhanced to facilitate the configuration of the network resource.

[beninsteon]

@bmercier thanks for this!

I think option 2 sounds best. I presume the portal would call on an ISY-specific Android/iOS app to relay the notification?

Perhaps this should be put to a poll in a dedicated thread on the Portal sub-forum?

[Javi]

Put me down for option 2 also

[James Peterson]

On 2/2/2019 at 11:43 AM, Jimbo said:

Looks awesome @James Peterson really curious how creating the rules are done! 

 

Just about finished creating a basic interface for creating the Rules.  I'm trying ti keep it really simple.  Stating with Switches, Sensors, door locks and ELK alarms from the start.  I'll start a new thread soon and see if I can get  a few alpha testers.  So far on Android only,  but this is an entire system (server hosted) so iOS will just be a basic addition to the code as it is for Android right now.  

 

attached screenshot. 

[James Peterson]

I think I have something that might be worth testing.  I will be moving all discussion about this to my slack channel.  If you would like to participate, please email support@agaveha.com and let me know you would like to be added to the channel.