Just getting started with MQTT.
I'm building a desktop application to monitor and control a bunch of network-connected devices. Sometimes this will call for the publish/subscribe style of communication, but in many cases the user will want to select one device and issue commands to it or query it for some data.
Articles about MQTT usually stress the lack of direct connection (or even awareness) between nodes. But if you want to query and control a single device, obviously that's not going to hold. How do you select a single device and address it over MQTT? Publish a message that uses that device's unique identifier as a topic? Or is there some more elegant approach?
An example might be: Some of the devices on the network accumulate audio recordings and place them in files. I want to retrieve a list of the files on a particular device. A few seconds later I might want to tell that device to play back one of those files.
The ONLY addressing in MQTT is the topic names
So you have 2 options
Have each device subscribe to a topic that includes a unique identifier for the device.
Include the devices unique identifier in the message and only have the device the matches act on it.
The first option is of course far better as it vastly reduces both the bandwidth (as the message is only sent to the right device) and the complexity as you need much less conditional logic on the device.
Related
I have written a Solution that contains two Apps,
the first app acts like a remote control app and the second app display some stuff depending on the selection of the first app.
State Now:
Currently, both apps communicate over a Bluetooth connection using the MultipeerConnectivity.framework.
Problem:
I have always to pair both apps manually starting the apps.
Solution:
Starting both apps, they should detect each other and be paired automatically.
How could I solve my Problem, is there any alternative to the Bluetooth connection or can I set up the connection to have trusted devices or something like that?
It's up to you as the developer how the pairing is implemented. You could even code a solution which requires no approval from the user; the app could pair automatically with any device looking for other peers (although this probably wouldn't be a good idea for a variety of reasons).
One possible solution for your problem:
The first time your devices pair, you generate a random UUID and save it on both devices for later use.
The next time your devices discover one another, they check to see if they have any matching UUIDs stored; if they do find a matching pair then you can let them connect automatically.
My work wants to test their new modems using an iPhone app. We can use a current app or build a brand new one. Third party apps are OK but want to avoid jailbreaking if possible.
We want an app which connects to the network and monitors certain parameters for a set amount of time. We will log attributes from the network and modem. We already know it's possible to test speed, disconnections, reconnection time etc. Some of the parameters we need to track might be more secure or outside Apple's regulations.
These are the responses we are looking for:
Frequency (ie. 2462MHz)
Channel Bandwidth (ie. 20MHz, 40MHz)
Radio Type (ie. 802.11a,b,g,n,ac)
802.11 Deauth Reason code
802.11 Association Status code
How can we track the above attributes using an iOS app?
Are there any apps out there that can track this information? Does iOS have anything for tracking these parameters?
Thanks so much!!
I hope to use the Multipeer Connectivity framework, and would appreciate any voices of experience on how best to proceed.
I need a connection between a "coach" device and up to 45 "player" devices. They will all be in the same space, but no way to predict wifi availability or connection. The coach device needs to send an instruction (a small data packet) to all player devices each second. Each "player" needs to send a reading from a Bluetooth Heartrate monitor (very small data packet) back to the coach each second. Since the maximum peers per session is 8, would any of these ideas work to accommodate the numbers I need?
a) The first 7 player devices to establish a connection with the coach advertise a different session type and allow 7 (or would this be 6?) more players to join them. Those first 7 act as a middleman to the other 49 (or 42?) by passing on the instruction from the coach and passing back the collected readings to the coach. A few second lag between instruction and heartrate reading is not preferred, but would be OK.
b) The coach device creates and advertises one session. After 7 player devices have connected, the coach device creates another session and repeats for 7 more. Repeat until all player devices are connected to the coach. This seems unlikely to work, but without understanding the magic that is Multipeer Connectivity, it was an option that came to mind.
c) The coach establishes a session with player device one, which connects to device 2... in a daisy chain topography. When each device recieves the instruction, it adds it's own reading to the data packet and sends it on. The last device returns the entire packet to the coach. I can't predict how long it would take for a round of data, and it also seems troublesome if one device leaves the group.
Any advice or voices of experience in using Multipeer Connection Framework for 45 or so devices would be appreciated.
I've been pondering something similar lately, and I'd say in your case b) would be your best option if you don't need the 'players' to communicate with each other.
Multipeer Connectivity supports multiple sessions so you could have an array for session objects, advertise as the 'coach' and with each discovered player either invite to the latest session if it has capacity or create a new one.
Your player object can keep a reference to the session and peerID for the purposes of sending data, and maybe keep a dictionary of peerID displayNames mapped to the corresponding player object to handle incoming data.
This way you also have no hops between a given 'player' and the 'coach', unlike with a) and c).
Obviously the real trick here is testing. I myself don't own 8+ devices and I'm still not sure how I'm going to test my own implementation!
Edit
I answered a similar question with actual code here: Best option for streaming data between iPhones
I Know that it is an old question.
I had the same problem mounts ago (and have asked a similar question without clear answer).
Things that I have tested and problems faced:
The "normal way" -- one session.
Problem: Maximum 8 devices.
Array of sessions putting 6 devices on each session (to avoid the maximum 8)
Problem: To much overheating, memory and cpu consumption. When several devices from several session get disconnected at a time the reconection can take to much time to be aceptable.
This is the most complicated way.
Steps:
We create the session and allow a maximum of 4 - 5 clients.
Every time a client is connected he create a group with the same conditions.
When We reach the maximum client count (4 - 5 depending on your implementation ) we stop advertising.
New clients will be connected between each other like cells. The trick is to have some method to decide witch sessions the new client needs to connect to ordered by priority and create a method to resent traffic to the client session to the "server replicator" one.
The only problem with the last method is that it is the most complicated and you need some maths a pencil and a peace of paper to decide how you will interconect your clients and resend your traffic.
Instead of MultiPeer Connectivity framework, You can go with this https://github.com/jdiehl/async-network#request-based-networking
the default is 8, it's not the maximum,
you question scared me, as I will need more than 8 too!!
it must of been poorly written looks corrected below.
maximumNumberOfPeers
The maximum number of peers allowed in a session, including the local peer.
#property(assign, nonatomic) NSUInteger maximumNumberOfPeers
Discussion
The largest allowable value (and the default) is 8.
https://developer.apple.com/library/ios/documentation/MultipeerConnectivity/Reference/MultipeerConnectivityFramework/MultipeerConnectivityFramework.pdf
We required to send a word from one mobile device to another using wifi-direct. The wifi-direct, wifi-discoveryservice samples given in android sdk shows its usage with MainActivity. As we have app with multiple activities and from selected activities we need to send particular word to another device on wifi, we are looking for a simple 'SendWordWiFiService' approach.
Any related input in this regard is awaited. We are struggling for last 1 week trying to implement wifi-direct, wifi-discoveryservice in a project having multiple activities. But no success.
You need to use Sockets. If you haven't done them before, I suggest reading this as it got me started. Additionally you might find Oracle's documentation to be useful. In particular, you may want to read up on of using threads to run server sockets.
The steps you need to take are:
Discover peers using Wi-Fi Direct
Make a peer connection between decies (NB: Be mindful of who the group owner is once this is done, if you're application needs to differentiate between a group owner and a group client(s)).
Once the peer connection is made, sockets can be set up between the peers for the transfer of data streams, ie sending words in your case. You might find it most logical to set your Wi-Fi Direct GroupOwner as the server socket, and your GroupClient devices as a client which connects to the server.
I hope that helps.
I'm using GameKit peer-to-peer connection in my app and I'm experiencing the following issue: when using GKPeerPickerController sometimes it takes too long time to deliver an invitation to connect from one device to another. Sometimes devices just don't see each other. What can i do about that? Is it better not to use GKPeerPickerController at all and present custom interface?
Depending on the type of app you are trying to make, it may be more beneficial for you to have one device act as a Server and another as a Client. I've noticed from personal experience that having both devices act as Peers can take considerably longer, or just flat out not work.
The only disadvantage with the Server / Client perspective is that your users will have to specifically choose one or the other, and you will have to create your own user interface. But if you can work with that then you'll probably get better results. Good luck!