Perhaps I'm missing something obvious, but the way Amazon SNS is described it sounds like a cloud-to-device push, of the sort that might be used for advertisements and other notifications.
I'm wondering if it easily supports mobile-to-mobile pushes, such as sending a data packet from one Android phone to another (specific) Android phone. Or, from an Android phone to an iOS device?
The data packet I'm describing might contain text & floating point data, or an SQL structure, or a bitmap.
Apparently Amazon SNS will not do mobile-to-mobile push.
Reply from Amazon:
To answer your question, no AWS SNS will not send a direct push message from one mobile device to another. SNS uses Amazon's servers as the publisher which will send the messages to the subscriber end points. You can view more of this here:
http://docs.aws.amazon.com/sns/latest/dg/SNSMobilePush.html
You would need to use the application on the mobile device to handle the messages from one device to another using the Google Cloud Messaging (GCM)
Answer link:
https://forums.aws.amazon.com/thread.jspa?threadID=144057
Related
I am interested in building a device that will be connected to my home network and I will be able to control remotely via an app on my cell phone.
My original thought is this:
Both systems will pull data from some cloud service
My mobile device will modify a data entry in the cloud service
The device will be constantly pulling this data and update the necessary setting when they change
Concerns with the original thought:
Constant pulling of the device in order to see when data has been changed (inefficient)
No way to communicate from the device to the phone (feature limiting)
Question:
What is the best way to create the link between my mobile device and the device that will remain in my home?
Potential similar architectures include Nest, Ring, etc.
The concept is correct - typically, IoT devices and mobile apps communicate through the cloud. There are cases when you want to connect your app directly to a device (e.g. through bluetooth, LAN or sometimes even internets), but that is done usually for a specific reason, e.g.:
IP cameras generate a lot of traffic, putting it through a centralized server is very expensive, so cheap home products do P2P from mobile app (centralized served could help you get the IP address for your camera)
TV with phone as remote control. Using cloud service hear would be weird and limiting access to LAN simplifies the setup
In general cases (Next, Ring) you can be pretty sure the IoT devices talk to the cloud, instead of the mobile app directly. It both offer more feature (as the data can be processed in bulk in cloud), but there's also benefits for using the cloud even if it's used only to relay data.
In many cases, you also want to limit traffic (e.g. save batteries or data plan). Two key aspects to be able to do that:
Don't waste time setting up a connection. That means connecting to a stable cloud service (your mobile might not be online) and using optimized network (e.g. LAN with static IP address, NB-IoT or LTE-M)
Choose optimal M2M protocol. Two popular M2M protocols are COAP ("light weight HTTP") and MQTT (a messaging protocol)
Once you've set up how both your device and mobile app can exchange data with the server, it's up to you to design how to use that. Note that there's nothing stopping from the device to also push data to the server - all connection (IoT device <-> cloud <-> mobile app) can use two-way protocols.
How to susbcribe to a telemetry events using MQTT and using C code? (this is a microcontroller code)
I can send data to a specified topic but when I trying to subscribe to this topic I got error message
This is the message from the log
"mqttTopic": "/devices/my-device/events/my_telem_topic1",
This is the error message from the log
"message": "SUBSCRIBE: Failed to subscribe to topic: '/devices/my-device/events/my_telem_topic1'."
To add to what Kamal posted:
Part of the confusion here is that both MQTT and Pub/Sub (where IoT Core puts your device's telemetry events) are called "topics".
There are 4 MQTT topics for devices to work with (this is all on device side, not Cloud side):
/devices/<device-id>/commands
/devices/<device-id>/config
/devices/<device-id>/state
/devices/<device-id>/events
The first two are there for devices to subscribe to in order to get updates from the IoT Core Admin SDK, the latter two are topics for device to publish data to the Cloud.
In order for a device to subscribe to another device's telemetry, it would need to be able to subscribe to the Pub/Sub topic that's receiving telemetry from the other device. This won't be done as part of the MQTT implementation, but rather, you'd need to implement the Pub/Sub API on your device. This is going to require a separate authentication path as well, likely a service account key that you add to your GCP project, then download to your device. The links in Kamal's answer should get you started if you want to go down that route.
Depending on what you're doing however, as they say, you can probably process the incoming telemetry from one device in a Cloud Function or similar, then set a config for the device that wants to be responsive to that telemetry. That way, if the device is online, it'll get it right away, or if it's not online, it'll get it upon reconnecting to IoT Core.
Telemetry events sent to Cloud IoT are sent to a Cloud Pub/Sub topic that is configured when the device registry is created and are not intended to be retrieved via MQTT on devices. One could use any of the mechanisms available in Google Cloud to subscribe to these messages (Cloud Functions, Cloud Dataflow, or a custom-written subscriber). Commands can be received by devices via MQTT. The topic for a device's commands is /devices/{device-id}/commands/#. APIs are available to send commands to devices.
One would generally send telemetry events from devices, analyze them with one of the aforementioned Cloud products, and then possibly generate commands to devices based on the results of that analysis.
I'm conducting a vendor analysis for an enterprise level organization. I'm looking for a SDK I can integrate with an iOS/Android application that does the following well:
Location Analytics
Geo-fencing around locations specified by the organization
Push Notifications (specific to geo-fences, time zones, and customer segmentation)
Easy to use console
Doesn't noticeably drain the battery
They also need to be advanced in their field--ideally they'd have some sort of beaconing
capability in their product or planned down the line to support indoor location awareness
Some examples I'm looking at are Geoloqi, Xtify and Urban Airship. Do you have any experiences with those or similar vendors?
It sounds like the proxim.io API is exactly what you are looking for. Here is a quote from the API documentation page:
Proxim.io is a platform for delivering relevant messages to your
application users. Messages that are delivered based on real-time
location, topics of interest, and geo-triggers. Messages can be
delivered to a device via Push, or can be routed to a software system
through an API (Web Events).
I have seen Xtify do most of these. With Push Notification it has support for tags which can help in sending message to subset of users. It has a location API. The console can use used to upload basic credentials, test sending messages and some basic analytic view.
Looks like Leantegra has all you need: there is back end solution; appropriate hardware and mobile SDKs for Android and iOS.
OK, how do push notifications work?
I found a nice tutorial: http://lessons.runrev.com/m/4069/l/59312
I get the concept that the device needs to register with the server but does the app essentially hold an AJAX connection to server or does the server somehow plug into the mobile phone network... ?
There are three essential components when talking about push notifications:
Your server
The providers server
Your mobile device
Your server is the sender. It sends the push notification to the providers server, which in turn sends it to the device. Your device, therefore, is the receiver. (Concluding that you don't have to "plug into the mobile phone network", this is all done by your provider - Google in this case)
Within your mobile application you just register an eventhandler which is fired when you receive a push notification.
Google called this C2DM (Cloud to Device Messaging), now GCM (Google Cloud Messaging) - you can get an introduction inclusive of an architectural overview and demos here at android.com.
To answer your question I know:
Both push notifications services (Apple's and Microsoft's) are using a persistent IP connection for implementing their push notifications functionality.
I think Android works the same way (at least with Android Cloud to Device Messaging (C2DM)). "It uses an existing connection for Google services". http://en.wikipedia.org/wiki/Android_Cloud_to_Device_Messaging_Service
But the answer is closer to AJAX, except I assume it is a simple "http" connection to Google Messaging service from Android, and the OS gets an alert of a new message and relays it back to a program that registered on it to want notifications.
Is there a cross-platform mobile app dev environment that allow us to access the SMS inbox of the phone?
I would like to create messenger apps on different platforms(Android and Symbian at least) that plays around with SMS. I learnt that Phonegap and Mosync is currently not providing such API, and I am still finding it. Any suggestions?
MoSync allows you to send SMS, but like you say, it wont let you receive them.
I guess the reason is, most app only need to send sms, because incoming messages
can be picked up from a server. Also many apps use sms to generate spread/users,
once your app is connected to a IP service of some kind you just talk to the server.
There is of course the cost question, send sms costs app users money, receiving sms
can cost the service provider money.