I'm interested in writing an app that send messages over IP (using 3g, not neccesarily on the same WiFi network as the receiving end) to a PIC microcontroller connected to a router (via ethernet or wifi)
I saw some descriptions and examples on how to send messages on the same network, not sure if just by giving a different IP it would work outside the network it self. I was wondering how can it be received by the PIC (still hasn't decided which PIC, depends on the possibility to perform this)
and in turn, depends on the msg received, the PIC will perform an action, for example, light a certain LED in a LED array.
I have the sending side (the app sending over IP), and receiveing side (the PIC which lights the LEDs)
I'm just not quite sure what to send, or if such "translation" is even possible.
I've searched the web but couldn't find any such thing except for made kit (for RC cars for example)
Thanks.
Carmel
Here's a UDP library I built for Mac/iOS wrapped in simple Cocoa that sends UDP packets to an IP address of your choice. Comes with sample server client app.
This is generic UDP packets so you just have to listen for them on the other end ( whatever that platform is ) and read the content. Let me know if you need help with that
https://github.com/Shein/Mac-UDP-Client-Server
Well, if the PIC can run a TCPserver, or maybe just UDP, then sure you can control a LED by sending an appropriate message. With an appropriate static IP address and routing, then you can use your iPhone to turn on the LED from anywhere you can get a connection.
PICs are not exactly renowned for having high performance and lots of RAM. If you do manage to get a server working, try to not use XML/SOAP
This looks more like a question for http://electronics.stackexchange.com.
If your familiar with SPI you could consider Microchip's MRF24WB0MA/RM module which
enables PIC to connect to a wireless network (either to an infrastructure wireless or
to AdHoc, or it can create its own AdHoc).
If you're using MCC compiler then you also have library available for this module
at Microchip Application Libraries.
TCP stack takes some memory space though. PIC18F would do but you'd be better of with PIC24F (they tend to be cheaper than 18F anyway).
Related
I am currently building an app that controls a single actuator and a LED strip. The controller for the actuator and LED strip is based on an ESP32.
On the ESP32 I have used the <ESPAsyncWebServer.h>, <ESPAsyncWiFiManager.h> to set up and connect the ESP to the local wireless network. In the app I would like to send some commands to the ESP like http://<ESP32_IP>/led_set?level=<level> and
http://<ESP32_IP>/act_open and so on, this shouldn't be an issue.
Normally I would set up mDNS on the ESP and in the Flutter app, however several of the ESP controllers are already shipped to the customers. So I am looking for another way to identify the ESP.
At the moment I have used the ping_discover_network library and the ESP shows up fine on port 80. I am however not able to separate the ESP from the other devices that shows up on port 80.
Do any of you have any suggestions?
Thank you in advance
You don't have many good options. If you only want to identify a few devices which have slipped through your fingers without mDNS, you can use their MAC address as a filter. If you happen to know their individual MAC addresses, then that should be quite painless. Otherwise you'd have to look for devices with MAC OUI (first 3 bytes, usually) ranges allocated to Espressif. Espressif has several OUI ranges, but if your devices were from a single batch of ESP32 module of the same type, they'll be using the same OUI so it should be quite easy to figure out.
E.g. a batch of modules I have all start with 40:F5:20:...
Of course, if a third party installs their (unrelated) ESP32 module into the same network, you'll have a chance of identifying those as well, but such is life.
This is obviously a stop-gap measure. Make sure further devices go out of door with some identification (mDNS or otherwise).
I want to connect multiple devices through socket without any server implementation.I will use that only for getting the IP addresses of the devices that will register.
There are two major problems to peer-to-peer communications: discovery, and reachability.
First, you need to know the IP address of the other peers to connect to them. Once you're connected to a mesh of peers, they can all keep each other updated on the state of the network, suggesting better peers to each other, passing around notifications of new peers who've joined and left, etc. But you have to design and implement a mechanism for trading that information. More importantly, you need to jumpstart things in some way, because when a new peer starts up, it's in a mesh of just itself, and it has no information to give itself.
One possibility is to have a handful of well-known "superpeers" (that you run) that are always connected, and bake their addresses into the app. Or you can have "introduction servers" instead of peers, serving much the same function. Or you can have some external way of trading addresses (the simplest is that users trade them on a web forum or an IRC channel or in person and type them in manually), which can be automated to various degrees. There are also shortcuts that can help—Bonjour can get other peers onto the mesh as long as one peer on the LAN is already there; GameCenter/GameKit can be used as an automated external trading network; etc.
Once you've solved the discovery problem, you still have the reachability problem. Most iOS devices usually don't have publicly-accessible IP addresses; instead, they're behind routers that do Network Address Translation, whether they be a home WiFi router or a cell carrier's 3G network. This means you need some way to do NAT Hole Punching to get two iPhones talking to each other. Somebody who knows both the public address and the internal address of each device can arrange for them to set up a connection to each other. You can have either normal peers do this (although that makes the jumpstart problem even bigger) or have your superpeers/introduction servers/etc. do it.
If you want to build all of this yourself, you probably want to look at other implementations. BitTorrent (including trackers and DHT) is well-understood and documented at a continuum of levels ranging from "lies-to-children" for curious end users to detailed protocol specs and open source implementations. And then look at some other P2P networks, because BitTorrent is not perfect, and doesn't try to do everything that everyone's come up with.
You can use GameKit. It has the matchmaking api that can help you.
It can be used for non game apps.
I've been working on something similar and it's a giant pain in the ass. There are 3 considerations: 1) Reachability 2) Discovery 3) The connection itself.
1) Don't even consider using 3g/4g, it just won't work well for keeping an open socket connection.
2) I'd use some sort of broker service between the two on the internet to connect the two. For discovery, you can just list what devices are available on the service.
3) For the connection, I find the IOS socket libraries to be rather painful to use, but if you go down to the BSD socket level it's not as bad. I think it'd be very interesting to use zmq sockets; that might simplify writing the broker service.
You can't. If the device is all online with wifi, it maybe possible and rely on the router setting just like pc connect. If some device is connected with 3g or gprs protocal , they may have no ip address at all.
I am implementing an iPhone/iPad app that allows users to send each other messages using the bonjour protocol. Basically, a server publishes his service over bonjour and the clients connected to the same wifi can discover his service and connect to it to start sending messages. The problem I've found is that some routers seem to have problems with Bonjour. When running my app at home or at some other places it works perfectly. The publishing and discovering of the bonjour services works flawlessly. However when I tried my app at one of my friend's apartments, some (not all) of the clients were not able to discover the published bonjour service. I also noticed that other apps that use Bonjour (such as Apple's Remote app) were also having trouble on said network. After doing some digging I've found that other people have had similar problems with bonjour and some routers. Therefore I have 2 questions:
1) Does anyone know if this problem with Bonjour that some routers seem to have is a widespread issue? In other words, if my app relies on Bonjour in order to function at all, do I have to be worried that it won't work in 50% of the WLAN networks or do most routers not have any issues with bonjour. Obviously I can't expect anyone to know how every router out there deals with bonjour packets but maybe there are some Networking gurus that can point me in the right direction :-p.
2) Second, if bonjour is too risky of a protocol to build my app on, what are some alternatives with similar features? The features I would (preferably) need would be service publishing and discovery without users having to manually enter IP addresses of other phones.
Ok thanks for your help! I understand that this is kind of a broad question but any help is appreciated! :)
This is potentially a tough nut to crack. The problem causing devices not to find each other on certain networks is related to the underlying transport (i.e. multicast UDP) and not Bonjour (or mDNS or whatever else you wanna call it).
In high-level, non-rigorous terms, multicast data puts more load on routers. Large corporate and university networks sometimes like to drop Bonjour messages (i.e. UDP packets sent to the multicast group 224.0.0.251 on port 5353) because it means the network isn't inundated with thousands of clients advertising their iTunes libraries or whatever, and at scale this can improve general performance. At the other end of the spectrum, some domestic routers drop multicast packets out of the box for reasons known only to the manufacturer. There's not a whole lot you can do about either situation.
Try running a tcpdump on the network to see if the packets are actually coming through. I've not come across a home router that doesn't forward them for a while. If they're not, you'll have to come up with some central [internet-facing, perhaps?] lookup facility. If they're visible, then there's something up with your implementation.
There's nothing stopping you from writing your own simpler protocol for service discovery to be sent over multicast- it's just that there are loads of Bonjour clients in a ton of different languages already written and tested.
My iPhone connects over adhoc wifi to a wifi sensor module.
The challenge is to code an app that uses this sensor module. But I'm not sure what specific API's to use to best architect this implementation.
I've started looking into the CocoaAsyncSocket class as it seems to be an appropriate tool for such use.
Does the user always have to manually connect to the adhoc wifi device? (through the Settings app) or can my own app handle the searching, making, and breaking of the wifi connection?
I doubt iOS lets me programmatically toggle whether Wifi is on/off.
Once the sensor data is being received, what container would best handle the stream?
For example, on other platforms, I coded a rotating queue buffer.
Thanks for your input.
Edit: The protocol in question is straight CSV formatted ASCII. Not HTTP, FTP, etc. Just raw data. The app is to simply open a port on the connected IP, and read/write.
Your application cannot turn wifi on/off, or select a wifi network.
Without more information on what protocols this wifi sensor module speaks, it will be impossible for anyone to give more than vague recommendations. If the module can serve data over an http connection, that would probably be ideal. If it requires your software to open a connection on a specific port and communicate over something other than http or ftp, your job will be a bit more complicated. CFNetwork and projects derived from it's usage, such as CocoaAsyncSocket which you mentioned. You can see another implementation of an HTTP connection over CFNetwork in ASIHTTPRequest, that may help as a reference for handling download streams, queuing operations, etc.
As for storing the data, again it's hard to give any concrete recommendations without more information. If you want to store the data to the filesystem of the iOS device, NSData will probably meet your needs. If you need/prefer to use a queue for buffering data, there is a simple category on NSArray which provides queue semantics. The link to CHCircularBuffer in that SO article is dead, but this github project appears to have it.
edit: Here is the official version of the CHDataStructures. I don't know if it's an improvement over the previous link, but it appears to be updated for the more recent iOS SDK.
Add the SSID of your wifi ad hoc networks in settings. When you see the SSID of the network, click the arrow and choose connect automatically. After this, the phone will automatically connect whenever it comes in range. After this, the two devices can communicate using regular socket APIs.
I want to check the network requests an app is making from my iPhone. It's on the same WiFi network as my computer (or if it makes things easier, I can set it up to use an ad-hoc network). I don't want to see every packet, just the URLs which my iPhone is requesting. I don't care about the returned data all that much.
A simple solution would be much appreciated.
If you want to intercept the phone itself you'll need to point it at an http proxy you set up on a computer and watch the requests come through. Something like http://www.charlesproxy.com/ or there are most likely many free proxies.
Connect your computer to the rest
of your local network via Ethernet.
Turn on Internet Sharing from the
Sharing System Preference to share
your Ethernet connection via
AirPort.
Set your iPhone to
connect to the computer as its base
station.
Use Wireshark to
capture and analyze the packets.
I found a really nice repo on github named Wormholy https://github.com/pmusolino/Wormholy it will show every network request on your iphone, you only add it to your pod file and then on your app, you shake your phone and you will see all requests.
Easy to install
Transparent on your app usage
Overview and details of your request
Like so
Screenshot of wormholy usage