GCM / FCM

[James Peterson]

any plans on adding cloud messaging to the portal?  It seems that all the infrastructure is already in place and just an API call to pass the messaging KEY to the portal and it would be up and running.

 

This would allow for services and apps that are not currently connected to the portal to still receive notifications.  

 

Ya.... BOOOM!!! mind BLOWN!!!

[G W]

Great idea. Why didn't I think of that?

 

Short and to the point.

Best regards,

Gary Funk

[MWareman]

The reason that UDI includes the Network Module if for this kind of functionality, but at the ISY end of things.

 

Personally, I'd love to see the equivalent of the Networking Modules but hosted on the portal. It can then have recipes for easy integration to other cloud services (Pushover, IFTTT, Hue, Honeywell, etc, etc).

[mwester]

Cloud Messaging?  Is that like when airplanes write something overhead at special events?

 

Seriously, anyone have any URLs to what these things are?

[G W]

You can start here.

 

https://developers.google.com/cloud-messaging/faq

 

Short and to the point.

Best regards,

Gary Funk

[giesen]

Cloud Messaging? Is that like when airplanes write something overhead at special events?

 

Seriously, anyone have any URLs to what these things are?

Aka Push Notifications

 

Sent from my SM-N910W8 using Tapatalk

[Teken]

This and a similar discussions was asked about several months and was rejected.

[Scottmichaelj]

This and a similar discussions was asked about several months and was rejected.

 

Just like DDNS

[Teken]

Just like DDNS

 

Yes, as I recall UDI didn't want to make the portal a conditional logic infrastructure.  

[Michel Kohanim]

Hello all,

 

The only reason is our aversion to putting too much logic in the cloud. Apart from IFTTT and Geo Fencing/Push Notifications, what other services should we put in the cloud?

 

Of course, with 5.0.x, putting services in the cloud and having them be represented as nodes in ISY is quite easy.

 

With kind regards,

Michel

[James Peterson]

I just want it for the push notifications. And using the portal technology as the implementation for it bypasses the need for the user to have to have an external accessible IP address. Without the external accessible IP address even if I were to create a secondary server to host the push notifications that user would not be able to use it. My only other option would be to create my own portal setup for the isy that a user could purchase on the Udi Market. That would be the only way that I could reliably assure the user that they would be getting all of the notifications from the isy using push notifications.

 

 

 

Sent from my Nexus 5X using Tapatalk

[MWareman]

Maybe a way for third parties to host their own cloud service that can receive notifications from the Portal (if so authorized). Then, the developer of the other service can implement whatever they want.

 

I feel that James is looking for a way to have Agave receive events thru the Google push service (GCM), without having to leave a subscription open.

 

Michael.

[James Peterson]

Maybe a way for third parties to host their own cloud service that can receive notifications from the Portal (if so authorized). Then, the developer of the other service can implement whatever they want.

 

I feel that James is looking for a way to have Agave receive events thru the Google push service (GCM), without having to leave a subscription open.

 

Michael.

Winner!!

 

Sent from my Nexus 5X using Tapatalk

[Michel Kohanim]

Michael, James,

 

Thank you. What you are describing will require the portal to have a) an always on subscription to ISY and monitor the events and then based on some filters, send a push notification to another device. In short, there needs to be a mini ISY in the portal which would defeat the purpose not being cloud based. Perhaps a better solution would be to have another construct in ISY Programs that calls an event service (based on some conditions) and passes some relevant information to the portal through the portal socket (not web). The question is what type of parameters do we need in the portal to make it secure, reliable, and extensible.

 

 

With kind regards,

Michel

[James Peterson]

I don't think it would need to be an always on connection.  

 

:::Imagine I'm using my hands here::::  

 

20000 feet overview....

 

Add an API endpoint to the Portal that instead of sending commands to the ISY, receives subscription info.

 

Update the portal setup on the ISY to send these subscriptions messages to the new endpoint if messaging KEY exists

 

 

Your app registers with Google and receives a messing KEY.  

 - the App then notifies the portal that you have a MK(messaging Key).  

 -  the portal notifies the ISY to begin sending messages

    OR portal begins accepting messages from that ISY

 

Begin Infrastructure already in place:

 - now that the Portal has a messaging key associated with the account it can send all messages received from that ISY to the GCM/FCM endpoint at google.  

     -   https://firebase.google.com/docs/cloud-messaging/send-message

 

Since the device is now registered with a MK it will receive all messages from the ISY without having to be connected.  This will save data for the users and no more constant sockets drops to the ISY as a mobile app walks between networks.  

 

I know its a bit more then this to setup, but I don't think it would be all that hard to do.  And the benefits are off the charts for bringing the ISY into some serious mobile capabilities.  

[Michel Kohanim]

Hi James,

 

ISY Portal subscribes to ISY IF AND ONLY IF a client subscribes (such as Agave). There are no mechanisms in ISY Portal to subscribe on its own. Furthermore, with your description, ISY Portal will need to keep checking for subscriptions and make sure they are maintained, re-subscribe if they are severed for any reasons, and finally there's no good method of removing them in case someone decides not to use them any more. We currently have this issue with Echo: dangling accounts which Echo thinks should exist but they that are not tied to any ISYs in the Portal. We had to spend numerous hours of maintenance and development just to clean those up.

 

In short, what you are suggesting will NOT work without massive changes and major overhead both administratively (making sure accounts are still associated with devices) and performance wise.

 

With kind regards,

Michel

[G W]

Maybe I'm confused here. I thought the ISY communicated with the Portal. If this is the case, can the ISY send a message to the portal that is then sent to the FCM?

 

Short and to the point.

Best regards,

Gary Funk

[James Peterson]

I don't know maybe I am miss describing what I am trying to describe here. From what I know there would not need to be a subscription from the isy to the portal for this particular type of service.

 

Sent from my Nexus 5X using Tapatalk

[jtara92101]

I dunno about Google, but Apple APNS REQUIRES that a provider MUST make a connection to their service from a single server. They want the messages aggregated on a single connection.

 

There is simply no provision for individuals to send APNS messages. (Other than through Apple or third-party apps, and all will employ a back-end service that connects to APNS.)

 

Yes, an individual can fiddle it, if they get a developer agreement and set-up a server to talk to APNS.

 

https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW9/

 

Thus, it would be inappropriate to the ISY to send APNS messages, and wouldn't be permitted by Apple. But if UDI would like to add APNS capability to the Portal, that is something that could be done.

[James Peterson]

I dunno about Google, but Apple APNS REQUIRES that a provider MUST make a connection to their service from a single server. They want the messages aggregated on a single connection.

 

There is simply no provision for individuals to send APNS messages. (Other than through Apple or third-party apps, and all will employ a back-end service that connects to APNS.)

 

Yes, an individual can fiddle it, if they get a developer agreement and set-up a server to talk to APNS.

 

https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW9/

 

Thus, it would be inappropriate to the ISY to send APNS messages, and wouldn't be permitted by Apple. But if UDI would like to add APNS capability to the Portal, that is something that could be done.

Do apple apns have an Android lib? If not I don't support them. GCM/FCM has both an Android and Apple lib so that is why I suggested that. As long as it's compatible with both I won't have preference.

 

But you are on point that the portal or some external server needs to handle this and not the isy specifically.

 

Sent from my Nexus 5X using Tapatalk

[Michel Kohanim]

Hi James,

 

If no subscription from ISY Portal to ISY, then what is ISY Portal notifying?

 

With kind regards,

Michel

[G W]

Hi James,

 

If no subscription from ISY Portal to ISY, then what is ISY Portal notifying?

 

With kind regards,

Michel

ISY -> ISY Portal -> FCM -> Android Application.

 

Short and to the point.

Best regards,

Gary Funk

[Michel Kohanim]

Hi Gary,

 

That does not answer the question of "what" from ISY to ISY Portal. Anything that ISY needs to publish to anything else requires subscription.

 

With kind regards,

Michel

[jtara92101]

Do apple apns have an Android lib? If not I don't support them. GCM/FCM has both an Android and Apple lib so that is why I suggested that. As long as it's compatible with both I won't have preference.

 

 

 

No, APNS does not have an Android lib. It is exclusively for sending push notifications to Apple devices. And you do not SEND messages to APNS from Apple devices - they must be sent from a server that makes a permanent connection to APNS. There is no "lib" required, as the support for receiving push notifications FROM APNS is built-in to every Apple OS. 

Only mentioned it because I'd imagine Google has similar rules, for similar reasons.

[James Peterson]

ISY -> ISY Portal -> FCM -> Android Application.

 

Short and to the point.

Best regards,

Gary Funk

100% Gary!!  on the mark.  

 

Hi Gary,

 

That does not answer the question of "what" from ISY to ISY Portal. Anything that ISY needs to publish to anything else requires subscription.

 

With kind regards,

Michel

 

That is exactly what this is kindof.  a subscription.  but instead of sending notifications through the subscription socket they would be POSTed to 

exp: https://my.isy.io/GCM/endpoint.php

 

From there the event notification would be processed and posted to FCM host at google with the message KEY identifying the device to send it to.  

 

FCM then sends the message to the device.  If the app is offline, it is cached and sent later.  You wouldn't even need an ISY app to receive these notifications.  but if you did have an app that could process the notifications as they came in, they could then be directed to specific app activities and respond to whatever was needed if it needed attention.  

 

OMG my mind is exploding with all the awesomeness of this!!!