I want to create an iOS app to connect my Wifi OBD 2 to the iPhone. But i have no idea on how to do the peer connection with swift 2. I have the OBD doc to communicate with it (https://www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf - page 30).
I tried to search the same thing on android and windows but the problem is my knowledge on peer to peer iOS communication.
I see a lot of iOS app for OBD protocol on app store, I'm sure that anybody can help me !
Thank you !
You don't need to know about real wifi peer2peer communication. Once you attached your phone to the wifi network created by the obd2 wifi adapter, you will be able to establish a good old TCP-connection to it. By default most wifi adapters listen at 192.168.0.10:35000 for incoming connections.
After establishing the TCP connection you can communicate via AT and PIDs by writing/reading to/from the socket. The actual protocol is described in ELM327 manual and the ISO/SAE standard documents.
Related
What is the best way to communicate with a remote device using Modbus over TCPIP via Bluetooth BLE in iOS? Has anyone experienced this yet? As there is almost to no information available on the internet.
Thanks
I'm looking to build a pair of apps that work in a similar way to iTunes and the Remote app for iOS... Is there a framework for connecting iOS and MacOS over wifi?
Bluetooth is something I'd like to avoid and there's no need for a web service, I'm just looking to control my Mac app remotely from the phone.
Thanks in advance.
Id say the most ideal way to accomplish this is via the Bonjour protocol.
Here is a great article on the subject, http://mobileorchard.com/tutorial-networking-and-bonjour-on-iphone/.
Good thing with using Bonjour in iOS is it also works via Bluetooth.
Hope this helps !
here is an example project which exchange the data between iphone and iMAC with WiFi connectivity.
https://github.com/boobalaninfo/Bonjour-iOS-MAC-Apps
Use bonjour to search for devices. Then use CocoaAsyncSocket to send and receive data. It works like a charm.
Little info about AsyncSock:
GCDAsyncSocket and AsyncSocket are TCP/IP socket networking libraries.
Here are the key features available in both:
Native objective-c, fully self-contained in one class. No need to muck
around with sockets or streams. This class handles everything for you.
Full delegate support Errors, connections, read completions, write
completions, progress, and disconnections all result in a call to your
delegate method.
Queued non-blocking reads and writes, with optional timeouts. You tell
it what to read or write, and it handles everything for you. Queueing,
buffering, and searching for termination sequences within the stream -
all handled for you automatically.
Automatic socket acceptance. Spin up a server socket, tell it to
accept connections, and it will call you with new instances of itself
for each connection.
Support for TCP streams over IPv4 and IPv6. Automatically connect to
IPv4 or IPv6 hosts. Automatically accept incoming connections over
both IPv4 and IPv6 with a single instance of this class. No more
worrying about multiple sockets.
Support for TLS / SSL Secure your socket with ease using just a single
method call. Available for both client and server sockets.
I have a very simple TCP client/server implementation using GCDAsyncSocket (7.5.0) and I'm using NSNetService for service discovery.
It's used only on a local wifi network and it works for 2 years with no problem (just to say : I have a proper use of GCDAsyncSocket).
...Until I tried using a third iOS device as access point providing the wifi network to which the client and server connect.
Same when the third iOS device connects both client and server by sharing its connection via Bluetooth.
The service discovery is OK, but once I get the ip address and port, I can't connect and get this error :
Error Domain=NSPOSIXErrorDomain Code=64 "Host is down" UserInfo={NSLocalizedDescription=Host is down, NSLocalizedFailureReason=Error in connect() function}
I tried restricting to IPv4 and IPv6 (both are provided by the service discovery), I also tried using the ipv6 git branch of the GCDAsyncSocket repository and various parameters.
My primary question is : is establishing a simple TCP connexion over a wifi or bluetooth iOS access point possible, if so how ?
My secondary question is : why does the NSNetService service discovery work and not the simple TCP connection ? I know that the protocols are not comparable but still, it confuses me.
It sounds like to me, that your problem lies in connection from the cellular network. When connected to cell network, it causes issues with ip address. Refer to this discussion from the Cocoaasyncsocket Github page.
I want to send UDP packages in a local network using GCDAsyncUdpSocket.
My fear is that at some point UDP packages will be sent via LTE because of the newly introduced "WiFi assist" from iOS 9.
Is there some way I can pretend iOS 9 from passing my traffic to cellular network, and instead require it to always use WiFi?
Thanks a lot for any ideas!
I think you can use "Reachability" to detect if the phone is connected to a wi-fi or to cellular data and then avoid to send message or manage the that particular condition. You can also ask to the user to disable the wi-fi assistant with a popup just to be sure to avoi the problem.
If I have an iOS client and an embedded device that I want to communicate between the two with a WiFi connection using UDP, do I need to write a server (python or something) to facilitate the connection? I am trying to look online but there are a lot of ambigious articles.
Thanks
You'll have to write a server application for the device (iOS or embedded) that will be listening for data.
However, for a simple, single-client UDP connection, your server is basically just a UDP socket, which you bind to the port you want to use - and then start listening for data on. You don't need any connection-handling as UDP is connectionless.
On your client, you just send data to the IP and port of your server, and that's it.
I've done this myself, connecting my iPod Touch to a small ITX computer (running WinXP), to control a small mobile robot over WiFi.