GCM / FCM

[Michel Kohanim]

I think we are going in circles. WHAT are we notifying and WHAT is the source thereof? If the source is ISY, then the only ways to have ISY notify something is either by subscription or the Network Module.

 

With kind regards,

Michel

[MWareman]

I think what Michel is saying is that although the ISY maintains a persistent outbound connection to the portal, it does not actually send any events unless there is a client also connected and subscribed to the Portal.

 

This means that if the Agave (or Mobilinc) is not running and connected to the Portal, as it is now the Portal will not receive events, so its not possible to then push anything anywhere.

 

This was probably done as a performance optimization on the Portal side - one I can somewhat agree with. I'm not sure how well the Portal would handle thousands of ISYs streaming events real time, without significant additional investment - especially when there is any purpose to the Portal listening for events when there is no client connected to the Portal.

 

The only way around this would be to stand up our own cloud server, have a process on it 'subscribe' to the Portal (thus establishing the outbound stream of events from ISY) and then pushing the events to GCM (managing the messaging key ourselves). However, even this would put a significant additional load on the Portal if lots of people do it.

 

Michael.

[mwester]

Whatever you end up doing, please please make it "opt-in"!!  I really do not want to have to compete with my ISY for outbound internet bandwidth!  Now, I know its probably peanuts to all you in the big cities with your 100 Terabyte/Second fiber optic links to your houses, but many of us in the smaller towns have far, far slower links and suffer with the horrors of data limits on top of it.

 

A constant stream, 24x7, of ISY events going to the portal will add up over a month.

[James Peterson]

Honestly I feel like Steve Jobs trying to convince IBM about personal computers and being told why would normal people want a computer in their home...  

 

As for bandwidth issues?  Yes, some of us have access to lots or up to unlimited amounts of data.  

 

When I or anyone spins up a subscription, quite a bit of data is transferred from the ISY or Portal to the subscription client, then sits and waits for subsequent notifications.

 

When you are running this client on a mobile phone and walking between cellular towers and wifi to data and so on and so forth, this constant reconnect starts to eat up data and begins to be unreliable.  I do not believe that the socket idea was designed for this type of use in particular sine the connection need to be maintained and mobile clients do not like to maintain these types of connections for long periods of time.  

 

The idea I am finding so hard to explain would never need to maintain a connection and or spin up sending massive amounts a startup and current state data.  

 

My Idea:

 

Create a new network module that can be purchased and installed on the ISY just like any other module.  This module will handle sending the data to the GCM endpoint.  Users will have to register their messaging key with the ISY directly and no portal involvement.  

 

NOTE:   If the ISY is going to complete with mobile internet providers providing their own HA products and other standalone HA on the market it has to start making moves towards more mobile friendly tools.  The ISY is a great tool and was a great standalone product for a while, but clients are no longer standing still.

[Michel Kohanim]

Michael,

 

Precisely.

 

James,

 

Perhaps if you can answer my questions instead of dissertations on the history and future of technology and how it should be implemented in ISY, we might be able to find a solution. Please respond with yes/no:

 

1. Is the source of events ISY (yes/no)?

2. Is it all the events from ISY (yes/no)?

3. If yes to #2, is it the same format in xml (yes/no)?

4. If no to #2, then what?

 

With kind regards,

Michel

[G W]

Now, that being said, is it possible for the ISY to send data to the ISY Portal?

 

If the answer is yes, then UDI can write code for the ISY that send to the Portal. The ISY needs to be configured for the FCM. Portal code that reads the ISY to configure the FCM.

 

This all takes time, so can this be done?

 

Best regards,

Gary Funk

[Michel Kohanim]

Gary,

 

Of course, you can use the Network Module to send data to ISY Portal. That's what we do with IFTTT. What's not being answered is WHAT is being sent to ISY Portal and what's being sent to FCM.

 

With kind regards,

Michel

[James Peterson]

Michael,

 

Precisely.

 

James,

 

Perhaps if you can answer my questions instead of dissertations on the history and future of technology and how it should be implemented in ISY, we might be able to find a solution. Please respond with yes/no:

 

1. Is the source of events ISY (yes/no)?

2. Is it all the events from ISY (yes/no)?

3. If yes to #2, is it the same format in xml (yes/no)?

4. If no to #2, then what?

 

With kind regards,

Michel

yes

maybe, but not necessary.  

yes

na

[Michel Kohanim]

Hi James,

 

Thank you. In this case we have to figure out a way to have the ISY Portal subscribe to ISY. The only remaining question is whether or not there are any services that we can use to figure out whether or not someone has stopped using a phone or service. Is there such a service?

 

With kind regards,

Michel

[jtara92101]

 The only remaining question is whether or not there are any services that we can use to figure out whether or not someone has stopped using a phone or service. 

 

Define "stopped using"?

 

You mean permanently? Or just that the phone is turned off, etc?

 

You are SUPPOSED to continue to send push messages even when your phone is off. It's practically the whole point of it. The backend service will queue them for when the user's device(s) is/are online.

 

Still not clear to me just what events are intended to be sent. These push message services aren't meant for any kind of bulk transfer, and should be aggregated, even for the same user. And unless the data is very short, it should just be a notification that tells some app that it ought to go somewhere (outside of the messaging infrastructure) to fetch it.

 

"you're up next to sing Karaoke" -> cool

 

"the Karaoke singing queue changed" -> cool, go get the Karaoke singing queue from somewhere

 

"the Karaoke singing queue changed, Bob is up next, then Fran, Sarah, Frank.... -> uncool

 

'100 new songs were added to the Karaoke library" -> cool, go get them from somewhere. uncool - followed by 100 song titles.

 

10 notifications to same user in 1 second's time - uncool, aggregate!

 

Understand these are generalizations, based on how Apple APNS works - and sure the intent of the Google push services are similar.

[mwester]

I was told, indirectly, that my comments about bandwidth concerns were not welcome on this topic.  Nevertheless, I feel compelled to comment -- has anyone checked just how much traffic there is in the Insteon event viewer over the course of a day?  And all of those events are supposed to be sent, in real time, out my internet connection to the portal -- to be queued up to be delivered to some remote app that may not even be powered up?

 

That costs money - to me, starting at my uplink.  To UDI (and thus to me next time my portal subscription needs to be renewed) when they need more AWS machines to handle all this traffic.  And so little of this, so very very little, is ever going to be delivered!

 

Clearly the filtering (there has to be filtering) has to happen at the ISY.

[G W]

I was told, indirectly, that my comments about bandwidth concerns were not welcome on this topic. Nevertheless, I feel compelled to comment -- has anyone checked just how much traffic there is in the Insteon event viewer over the course of a day? And all of those events are supposed to be sent, in real time, out my internet connection to the portal -- to be queued up to be delivered to some remote app that may not even be powered up?

 

That costs money - to me, starting at my uplink. To UDI (and thus to me next time my portal subscription needs to be renewed) when they need more AWS machines to handle all this traffic. And so little of this, so very very little, is ever going to be delivered!

 

Clearly the filtering (there has to be filtering) has to happen at the ISY.

You know how we send email and text meddage through the ISY now? That's how notifications will be sent.

 

You control the ISY and therefore the notifications that will be sent.

 

Best regards,

Gary Funk

[Michel Kohanim]

Hi jtara92101,

 

Stopped using = threw away and went with another service provider and/or phone.

 

Hi mwester,

 

I totally agree with you. It makes no sense to send all the messages and events through push notification. We need to figure out a way to filter things on ISY WHILE not making it too cumbersome.

 

Hi James,

 

Do you happen to have a set of use cases that require push notification? May be something like:

1. A checkbox next to a device so that change of status for the device is published

2. A checkbox next to variables so that the change of status for the variable is published

- What else?

 

With kind regards,

Michel

[G W]

Hi jtara92101,

 

Stopped using = threw away and went with another service provider and/or phone.

 

Hi mwester,

 

I totally agree with you. It makes no sense to send all the messages and events through push notification. We need to figure out a way to filter things on ISY WHILE not making it too cumbersome.

 

Hi James,

 

Do you happen to have a set of use cases that require push notification? May be something like:

1. A checkbox next to a device so that change of status for the device is published

2. A checkbox next to variables so that the change of status for the variable is published

- What else?

 

With kind regards,

Michel

Michel,

 

Could a notification be added to a scene?

 

Also, I'd like to assign a level (1,2,3) to a notification. Then subscribe to a level.

 

Subscribe to level 1 and get only level 1. Subscribe to level 2 and get levels 1 and 2.

Subscribe to level 3 and get levels 1,2 and 3.

 

Best regards,

Gary Funk

[giesen]

Hi jtara92101,

 

Stopped using = threw away and went with another service provider and/or phone.

 

Hi mwester,

 

I totally agree with you. It makes no sense to send all the messages and events through push notification. We need to figure out a way to filter things on ISY WHILE not making it too cumbersome.

 

Hi James,

 

Do you happen to have a set of use cases that require push notification? May be something like:

1. A checkbox next to a device so that change of status for the device is published

2. A checkbox next to variables so that the change of status for the variable is published

- What else?

 

With kind regards,

Michel

I'm guessing a checkbox for program status as well?

 

Sent from my SM-N910W8 using Tapatalk

[James Peterson]

Hi jtara92101,

 

Stopped using = threw away and went with another service provider and/or phone.

 

Hi mwester,

 

I totally agree with you. It makes no sense to send all the messages and events through push notification. We need to figure out a way to filter things on ISY WHILE not making it too cumbersome.

 

Hi James,

 

Do you happen to have a set of use cases that require push notification? May be something like:

1. A checkbox next to a device so that change of status for the device is published

2. A checkbox next to variables so that the change of status for the variable is published

- What else?

 

With kind regards,

Michel

 

I like the idea of selecting the devices, scenes, variables that you want notifications from.  

 

My basic concern for wanting this is to be able to receive alerts to my phone even when the app is not running.  Then be able to take that notification and take the user to the appropriate response location.  

 

But I think we are finally getting on the same page.  I don't notifications that my living rooms lights just turn on while I am home, but if I am on vacation and they just turned on and no one is supposed to be home, yes, I want that notification.  

[jtara92101]

It seems to me your use case is very similar to the current email notifications. Would it be sufficient if the user could add a notification to a program?

 

Others seem to be seeing this more broadly, and - I fear - not really within the intended usage of push notification services.

 

Since an individual CANNOT originate push messages (that is, other than using a Apple/Google-provided or third party app) and in any case push messages have to be put in the push network(s) from an always-connected server, it would seem appropriate for the Portal to do the job. It would round-out the current email and text notifications.

 

So, if a user has a portal subscription, they should be able to add something in email/notifications to create a recipient that is reached via push notification.

 

Alas, I see a fly in the ointment. Push notifications - at least for Apple, Google may be different - only go to a specific app. For Apple at least, UDI can't send notifications that can be consumed by your app. (Not YOUR app, as it is Android...) They can only send notifications to their own app, which they don't have.

 

It could be done in a round-about way, if UDI had an app on mobile devices. The UDI app would receive notifications, and then could notify any apps listening on a device using a Custom URL Scheme (iOS) or an Intent (Android).

 

Again, this is all with Apple infrastructure, which is what I am familiar with. Maybe James can comment on the differences with Android push services.

[Jimbo.Automates]

I like the idea of selecting the devices, scenes, variables that you want notifications from.

 

My basic concern for wanting this is to be able to receive alerts to my phone even when the app is not running. Then be able to take that notification and take the user to the appropriate response location.

 

But I think we are finally getting on the same page. I don't notifications that my living rooms lights just turn on while I am home, but if I am on vacation and they just turned on and no one is supposed to be home, yes, I want that notification.

It's not just for notifications, it would also be useful to have the status of a device or scene be updated. Then you could have Agave widgets that were in sync without having to hold a subscription open!

 

Sent from my Nexus 6P using Tapatalk

[G W]

It's not just for notifications, it would also be useful to have the status of a device or scene be updated. Then you could have Agave widgets that were in sync without having to hold a subscription open!

 

Sent from my Nexus 6P using Tapatalk

From what I understand this is just for notifications. The application runs in the background to receive updates. If it loses connection there's s good chance notifications has lost connection.

 

If I'm wrong, please show where I can read the correct documents.

 

S.A.T.T.P.

Best regards,

Gary Funk

[Jimbo.Automates]

From what I understand this is just for notifications. The application runs in the background to receive updates. If it loses connection there's s good chance notifications has lost connection.

 

If I'm wrong, please show where I can read the correct documents.

 

S.A.T.T.P.

Best regards,

Gary Funk

 

I'm not expert on FCM, but an app, like Agave can receive the FCM and notify you if it wants to, or just update it's database.    The subscription connection I was talking about, was the Agave subscription to the portal or isy, not FCM.

 

Lot's of docs are available:  https://firebase.google.com/docs/cloud-messaging/

[G W]

 

 

I'm not expert on FCM, but an app, like Agave can receive the FCM and notify you if it wants to, or just update it's database. The subscription connection I was talking about, was the Agave subscription to the portal or isy, not FCM.

 

Lot's of docs are available: https://firebase.google.com/docs/cloud-messaging/

Right. If Agave can't connect to the Portal, it's probably because the Portal is down and notifications will be down.

 

Am I still missing your point?

 

 

 

S.A.T.T.P.

Best regards,

Gary Funk

[Jimbo.Automates]

Right. If Agave can't connect to the Portal, it's probably because the Portal is down and notifications will be down.

 

Am I still missing your point?

 

 

 

S.A.T.T.P.

Best regards,

Gary Funk

 

Yes, the point is that it doesn't need a keep a constant connection to the portal because it's getting updates from FCM. I never said it couldn't connect to the portal.

[G W]

Yes, the point is that it doesn't need a keep a constant connection to the portal because it's getting updates from FCM. I never said it couldn't connect to the portal.

I understand. That's could actually take the place of Agave running in the background.

 

S.A.T.T.P.

Best regards,

Gary Funk

[Jimbo.Automates]

I understand. That's could actually take the place of Agave running in the background.

 

S.A.T.T.P.

Best regards,

Gary Funk

 

Agave would still run in the background to receive the push messages, it just wouldn't have to keep a subscription open to the ISY/Portal.

[MWareman]

If there was a hex representation of 'device x changed' pushed to the portal and to the GCM API (each time any device changed) - if the device is listening it can then go get the new state of device x. If not, it gets discarded after some time (few mins).

 

Android has a system called Intents. An app can register an intent such that when messages are received thru GCM the OS will wake the app and deliver the event for it to process. The app itself isn't actually running all the time. It's an incredibly efficient way of running an app that needs to receive notified pushed from a cloud service.