I am using MQTT protocol in real time data communication application,therefore I need to retrieve the client device location data and pass it to MQTT broker. Is there any available API to track client device Geo location in MQTT environment
It really isnt' clear what you are asking in the question but I'll try to cover all the options.
The device knows it's own location and you want to publish this information on a topic. Assuming the device has a GPS receiver (or some other way to determine it's own location e.g. data from a cellular network) then it's simply a case of building a message with a payload including the location data in what ever format you want
You are trying to determine the location of the client purely from it's connection to the broker. The broker will know the client's IP address so in theory it could use a IP Geolocation API to give an estimate of the devices location. There are no standard brokers with this capability so you would have to build your own. Also in most cellular environments the devices sit behind NAT gateways so you would only be able to locate the gateway not the end device.
Related
I am using Google IOT core with mongoose os. I wanted to update device connection status to firestore. But i am unable to find event which reports mqtt connection status to pub/sub like when device disconnects or reconnect i.e if device is offline or not.
I am stuck on this problem for days.Any help will be appreciated
Update
As #devunwired mentioned in this response it is now possible to monitor Stackdriver logs for disconnect events. You must have at a minimum enabled INFO level logging on your project in IoT Core > Registries > [your registry] > Edit Registry > Select "Info" log level > Click save.
Original Response
There are a few values you can look at that are tracked in device configuration metadata that you could use to know when a device last was online:
Last Configuration Send time - sent anytime your device connects /
configuration is posted
Last Event Time - Last time an event was sent from the device
Last State Time - Last time state was sent from the device
Last Heartbeat time - Last time MQTT heartbeat was sent
To get you started, here is an example using API explorer that you can fill-in with your project ID, region, registry, and device to query for a specific device's metadata.
For 1...3 you have control over these through device manager and by publishing data. MQTT heartbeat is updated if your device sends an MQTT_PINGREQ message during the "ping period" without other messages getting sent.
At any rate, you could use any of these update time values to see the last time a device was online / functioning. You could query the states of your devices after listing the devices in a registry and could update a Firebase RTDB periodically if that's how you want to report (e.g. using AppEngine TaskQueue). Note that you also just can get these "last connected" values from the Google Cloud Console.
It was said before but we don't have an event for disconnect, just configuration ack, which generally is the connection event. If you want to share state between a device and the device manager, use state messages.
Unfortunately, there's no built in way to do this right now as there aren't events on this state.
However, you could implement a hack by sending a message on connect/disconnect from the device that you have a Cloud Function subscribed to the Pub/Sub topic listening for. It's not perfect as it would fail in the case where the device disconnected unexpectedly.
There currently is no way to do this, that i've been able to find (a year later after this original post). I posted a question here on SO regarding this as well, with more details and link to example code I had to use for handling this:
Google Core IoT Device Offline Event or Connection Status
The AWS IoT platform publishes messages on a special MQTT topic (prefixed with $aws) when your device connects/disconnects. You can easily use these to monitor these events - however, you should be aware that the MQTT protocol is designed to be robust to a poor networking conditions and the broker on the AWS side probably doesn't think it's a bit deal to disconnect a client. The broker expects that the client will just reconnect and queue messages for a moment during that process (which can be a big deal on a microcontroller).
All that being said, the AWS topics you would watch are:
$aws/events/presence/connected/{clientId}
and
$aws/events/presence/disconnected/{clientId}
and the documentation for these (and other) lifecycle events are located: https://docs.aws.amazon.com/iot/latest/developerguide/life-cycle-events.html
I'm trying to develop a solution, where iBeacon has to be used as an alerting mechanism. This iBeacon has to receive alerts or messages from a remote server and then publish the same to its nearables.
Is this a possible usecase where iBeacon has to receive request from a remote server? As a disclaimer, I new to this technology and let me know if my understanding is wrong.
I believe you are approaching this problem from the wrong angle. Essentially you would like to receive a message when you encounter certain iBeacon signals. iBeacons are "dumb" devices, meaning they can only broadcast a data packet, they cannot receive any information and cannot broadcast anything different than the iBeacon protocol packet.
That being said, if you had a remote server that stored these messages, you ask the server what the most recent message is associated with the beacon you have just encountered. That way you can change the messages dynamically on the server based on what you need your user to know.
So essentially, because each beacon can be uniquely identified based on UUID, major, minor, you can store your messages based on this so that you can ensure the user is receiving the correct message when they encounter the beacon by sending these identifiers up to your server in order to retrieve the message.
Is it possible to simultaneously broadcast my iOS app as an iBeacon and at the same time publish a service?
My app currently advertises a service, which works perfectly fine. My client app (central) is able to find the peripheral, connect, obtain the service and read data from the characteristic. However, if I update my server app (peripheral) to start broadcasting as an iBeacon emitter in addition to the service, I am no longer able to find services that I setup to advertise on the client app (central).
The idea of this is that I want to be able to read information from the server (peripheral) app when in close proximity from the client (central).
Is this technically feasible?
I was thinking about turning off iBeacon transmission when a device comes into close proximity and then starting the service broadcast, but there is no API in Core Bluetooth that calls back to the emitter when a client device enters the region being advertised.
Is this doable? Is there a workaround that would achieve something along these lines? I would like to avoid any networking, as this should be an offline solution.
Taz, For sure you can be an iBeacon and you can look for iBeacons. What I did and what I see other doing is combining iBeacons with other services, such as the CloudKit [which yes, means networking too] to add functionality to their basic functionality.
That said I can imagine an app in which your iBeacons switch to a different protocol when they see each other, the challenge; how-to negotiate a channel/UUIDs for a BLE peripheral/central pair.
I am still in the process of building, but have implemented something similar over the past months... in short you hardcode an initial channel to start your BLE conversation, your first and only exchange on said channel being to agree a new BLE one to use.
I'm creating an app that needs to connect to versions of itself running on other devices on the wifi network. The goal is to set up a broadcast / client relationship between one device to the others.
I know that Bonjour is the accepted method to do this, but I'm reticent to do that because it locks me into iOS devices, when I'd like to branch out to others, at least for clients.
If I start a webserver on the broadcaster on a specific port, like 43231 or something, is it acceptable for the client device to get it's own IP and then scan that block range for the broadcaster? Is there anything bad about pinging all the other random devices on the network with a request like that?
As in, Broadcaster is 192.168.1.11. Client is 192.168.1.4. If the client assumes all the devices are in the 192.168.1.* block, can it just iterate up the line from 1-100 or so looking for the broadcaster?
If this method is crazy, what should I do?
You can use SSDP (used by UPnP) or just multicast a message over the network and listen for it at the same time, ignoring the loopback (if you don't want the sender to receive it's own messages).
Maybe it will be better to use Bluetooth Low Energy for broadcasting/discovery? You can send non-connectable advertisement packets on server (with it's IP address) and listen for them on all other devices. Device founds such packet, reads IP address and connects to it via NSURLConnection (or something like that).
Is it possible to get GPS information in a mobile device through APIs without having any GPRS connectivity?
Edited
Yes, for example on the Java ME platform or Apple iPhone
Yes; if you are on a device that has GPS hardware in it and software development on the device gives you access to that hardware from your software.
This can be using a built in API for opening a COM port. You then just need to open the port that has the GPS hardware connected to (internal GPS receivers inside the device are often connected to a fixed COM port number) start interpreting the (often) NMEA strings that the GPS receiver is sending out.
Or perhaps the device has more specific GPS related APIs, like the GPS intermediate driver in Windows Mobile 5+ that lets the OS talk to any GPS receiver (either built in, or connected via cable or bluetooth to a COM port) and lets multiple applications concurrently interact with the GPS data.
P.S.
GPS has nothing to do with GPRS per se. You might have gotten that idea because of A-GPS which uses telecom network information and/or a dataconnection (like GPRS, EDGE, UMTS, WLAN, whatever) to download a small file with information about the location of GPS satellites.
This data will then enable your device shorter GPS aquisition times within the time period that this retrieved data is current - often a couple of days to a week I believe - because it does not just need to see what GPS signals it can receive and make sense of that, but it has a lot of prior knowledge about the GPS constellation that should be in orbit in the part of the sky you can see.
GPRS is a two-way data transmission which enables you to access the iternet while the GPS is just a receiver and as peSHIr already mentioned it has nothing to do with GPRS. GPS receiver receives the signals from multiple satellites and calculates the location from time differences.
Anyway... you need GPRS or any other internet connection only if you want to use any web service for reverse geolocation or you want to use google maps or any other location service. But just for receiving (calculating) the coordinates GPS by itself is enough.