I am just bit curious. I am new in IoT and currently started working on it using ESP8266 device. I know that it needs some firmware to write and install, like smart.js.
But I have read, Jasper (http://www.jasper.com/) can connect any device and manager, monitor etc. So I am bit curious how it works internally. I am not sure whether it installs firmware created by Jasper or in other way. I was reading this article: http://www2.cumulocity.com/guides/users-guide/jasper/#link-sims
Anyone knows about this? I mean how Jasper works to connect to any devices?
Cisco bought Jasper, which is useful for IoT business. However it might be better way for you to check Interactor(www.interactor.com) which is great for IoT development. Interactor works to conntect to any device with any protocol.
Cisco Jasper should not be confused with device management libraries (whether they be server based, or device based or both).
Jasper is a telecom based service that allows you to see and manage the connection state of sim inserted in the device. Regardless of the state of a device, the modem and sim (provided they are powered) will connect to the telco and provide basic information about the connection.
Think of it as a network tool (server originated) for the gateway on the device, not the device itself. It allows you to force disconnect devices from the network, ban sims from the account so a stolen or runaway sim can eat through data, basic connectivity tests (is the modem powered, does the sim have permission to transmit data over the network, etc).
The main value of jasper is that it allows you to manage you data costs by applying the appropriate rate plan to each device, and disconnect devices that are using too much (for whatever reason).
Jasper does not cost anything to use, however telcos will apply a rev commit (min monthly spend) usually $500/month to gain access. the sims are the same as PCS (phone) sims, but they are on their own network internally, and are specific to that telcos jasper. i.e. you can't take 500 devices using PCS sims, and import those sims into jasper. you'd need to do a physical swap of the sims.
Related
I'm writing some code (C++) for ESP32, to act as a BLE beacon. The problem is this: the iPhone doesn't send out its real MAC address, but does a random-generated MAC address, for security. The thing I'm confused about is how do you know if it's a device you've previously paired with?
So let's say I detect a new BLE MAC address, and looking at the manufacturer data I can determine it's an Apple device (first 2 bytes are "4C").
Now I need to know if I've previously paired with that device, so that I can allow the ESP32 to initiate an action (for simplicity let's just say turn on an LED). If that MAC address is in a list of known devices, then I can continue, and if not, I ignore it.
The problem is, if the iPhone is not giving up the real MAC address, the detected MAC address will never match anything. As this is a security situation I'm sure the algorithm for generating those MAC addresses is not known.
To be clear: this code is being written for the ESP32, not the iPhone.
It is in fact not possible to tell if a device has been previously seen, unless you pair and establish a bond with it. Once you pair with the device, long-term keys are exchanged and are used to quickly re-establish the connection.
This is by design. MAC addresses were originally unique, but this allowed tracking people and devices without their consent. You can read more about this in the following ESP-IDF guides:
GATT security server walkthrough
GATT security client walkthrough
So are you using esp32 as a beacon? This dose not involve any pairing or iOS MAC addresses. iOS will just be able to listen and the esp32 will not even know someone is "listening" to its broadcast.
Probably iOS application can store which services it is interested to hear to; may looks like pairing.. but it is a high level application managed technique and not any related to what BT standard calls pairing.
I have two entities which I would like to be able to start a communication:
Hardware Device Using Atmel ATSAMS70 and WINC1500 Wifi Module
HTML 5 App
The idea to have a HTML 5 app is to be able to communicate easily with most of the commercial devices like: Windows computers, Android Phones, Mac OSX computer and iOS devices. Apart from that, I would avoid working with native code at all.
Currently, they can talk with each other using WebSockets but somehow the IP address of the custom board has to be known from HTML 5 to initiate the communication.
In order to do this, I can think of 3 options:
Using WebRTC I can get the local IP address of the browser and then I could do a scan of the local devices considering a 255.255.255.0 network mask.
Have an external server that the hardware device can send its local address which will be later retrieved by HTML 5.
Using Bonjour or some sort of device discovery service between the board and HTML5.
I could not find a way to achieve #3 but #2 seems feasible to me. #1 is what I am doing now, but WebRTC is currently not supported on iOS.
So, is there any other better possibility to achieve this communication?
You don't mention how the WINC1500 unit is being connected to the network but presumably this is in STA mode (acting as a wifi station rather than becoming a software access point or part of an ad-hoc network) and is being provided with its IP details through an existing access point?
Ordinarily I'd suggest that once connected, the device ought to start indicating its availability on the network via a regular UDP broadcast on a specific port but my (admittedly limited) understanding of WebSockets it is that it creates TCP connections. The only implementation of Bonjour that I've seen uses UDP messaging too, that may be why you've had trouble with your third approach.
Your second approach seems more likely to work well. A server at a known (or discoverable) IP on the local network which allows the Atmel device to register itself (and its IP address) and also allows other applications (your HTML 5 WebSockets applications) to request that connection information to allow them to create the WebSocket TCP connections they need.
I suppose that doesn't really answer your question as to "Is there a better way?", other than to say "Not that I can think of, your second approach looks good to me...". Sorry! Sounds like a very interesting project, overall,
I would like to do data sharing(Maybe xml or json file) between 2 iOS devices (iPhone or iPad) and communication would be like "one to many bidirectional" bases at a time.
With some experience and from articles , I have found below ways to do it.
Wi-Fi Direct
AirDrop
Bluetooth(By creating Master and Slaves)
Bonjour SDK.
Bump API(Which is already closed from january 2014)
Could anybody please suggest the best way to fulfill my requirement, which is a good way to do it?
Since IOS 7 Multipeer Connectivity could also be quite interesting.
The Multipeer Connectivity framework provides support for discovering services provided by nearby iOS devices using infrastructure Wi-Fi networks, peer-to-peer Wi-Fi, and Bluetooth personal area networks and subsequently communicating with those services by sending message-based data, streaming data, and resources (such as files).
Here is a nice tutorial about implementing a file sharing system using multipeer connectivity:
http://www.appcoda.com/intro-ios-multipeer-connectivity-programming/
Wi-Fi
Connecting to your Personal Hotspot via Wi-Fi is the default option provided by Apple, since you have to specifically accept if you also want to enable the Bluetooth connection. A Wi-Fi connection provides:
Pros
High throughput: Throughput via Wi-Fi Personal Hotspot can be of around 30 Mbps between two devices and even more.
Faster: Connecting via Wi-Fi tends to be quite faster than connecting via Bluetooth.
Cons
Might need you to reconnect every time: Wi-Fi tends to be unstable and to turn itself off every time you put your iPhone to sleep. This means that you have to take out your iPhone and re-enable the Personal Hotspot if you want to connect.
Time limit: Perhaps the biggest drawback of using a Wi-Fi Personal Hotspot with your iPhone is that in order to minimize power consumption, your iPhone only gives you a short while (90 seconds reportedly) to connect a device to it after you enable Wi-Fi Personal Hotspot. If you take longer than that, you are forced to enable the option again.
More power consumption: The Wi-Fi Personal Hotspot consumes more power than its Bluetooth counterpart, which is also part of the reason it only gives you a short while to connect a device.
A bit more complex: The iPhone’s Wi-Fi Personal Hotspot requires you to enter a password and to configure your own security options.
Bluetooth
Contrary to the Wi-Fi connection, using your Personal Hotspot via Bluetooth offers some key advantages and one huge drawback:
Pros
No time limit: Once you enable Bluetooth Personal Hotspot, there is no time limit for you to connect your device to your iPhone.
Automatic pairing: Bluetooth remains dormant and ready to connect to your devices the moment you wake them up. Additionally, Bluetooth is more power-efficient than Wi-Fi.
Security handled automatically: The security level of a Bluetooth Personal Hotspot is equivalent to Wi-Fi’s WPA2, and it is all handled transparently from the moment you connect to it.
Cons
Very limited throughput: Without a doubt the biggest drawback of using a Bluetooth Personal Hotspot is its limited throughput, which can be of just 3 Mbps at the most, making it 10 times less than what your Wi-Fi Personal Hotspot can offer.
I'm trying to find out what AWDL is. On iOS, if you use Apple's peer-to-peer networking over BlueTooth, it seems Apple creates a new Network Interface "awdl0" to implement (I guess) IP-over-BT.
But I can't find any docs on this tech, or this interface, how it behaves, things we must / must not do with it, etc. Google comes up blank :(.
In particular, I believe it means "established a BT connection, and I'm running an IP bridge over the top, and you can use this to communicate peer-to-peer". Apple's own system libraries have bugs where this bridge isn't setup quickly enough, and if you send data too soon, it appears to get dropped by the OS. So ... if I can query this awdl0, I hope to check "are you ready yet?" and delay P2P messages until the OS is happy.
UPDATE
More info: I can get pairs of iOS devices to create awdl0 connections to each other - but they never get created to OS X machines, whether BT and Bonjour are on or not, whether the devices are paired or not.
Some background:
In iOS5, Apple permanently disabled the Bluetooth parts of Bonjour/Peer-to-peer networking, and published a technote instructing everyone to use DNS-SD if they wanted to keep using Bluetooth as a transport between iOS devices. This is fine, but it means you must use DNS-SD if you want high-performance BT, and you want it reliable.
(GameKit sometimes works fine, but we often see terrible performance in real-world scenarios, e.g. crowded public places - which goes away if you use DNS-SD)
DNS-SD protocol doesn't include info to tell you what the hardware is using. But it does tell you the Network Interfaces (which is how I know we're running on awdl0)
DNS-SD is awesome, and we have high-speed, low latency connections peer-to-peer between iOS devices - all the stuff that GameKit promises but often fails to deliver whenever there's more than a few wifi/BT devices in range.
AWDL recently caught a lot of attention when it caused Wi-Fi issues in iOS 8 and OS X Yosemite devices.
What is AWDL?
AWDL (Apple Wireless Direct Link) is a low latency/high speed WiFi peer-to peer-connection Apple uses for everywhere you’d expect: AirDrop, GameKit (which also uses Bluetooth), AirPlay, and perhaps elsewhere. It works using its own dedicated network interface, typically “awdl0".
While some services, like Instant HotSpot, Bluetooth Tethering (of course), and GameKit advertise their services over Bluetooth SDP, Apple decided to advertise AirDrop over WiFi and inadvertently destroyed WiFi performance for millions of Yosemite and iOS 8 users.
How does AWDL work?
Since the iPhone 4, the iOS kernels have had multiple WiFi interfaces to 1 WiFi Broadcom hardware chip.
en0 — primary WiFi interface
ap1 — access point interface used for WiFi tethering
awdl0 — Apple Wireless Direct Link interface (since iOS 7?)
By having multiple interfaces, Apple is able to have your standard WiFi connection on en0, while still broadcasting, browsing, and resolving peer to peer connections on awdl0 (just not well).
You can find more info here and here.
I'd like to provide a more precise answer as to how the protocol works internally. I quote part of the abstract of this paper.
In short, each AWDL node announces a sequence of Availability Windows
(AWs) indicating its readiness to communicate with other AWDL nodes.
An elected master node synchronizes these sequences. Outside the AWs,
nodes can tune their Wi-Fi radio to a different channel to communicate
with an access point, or could turn it off to save energy.
From a user perspective, AWDL allows a device remain connected to an infrastructure-based Wi-Fi network and communicate with AWDL peers "at the same time" by quickly hopping between the channels of the two networks (AWDL uses fixed social channels 6, 44, and 149). In contrast to the previous answer, we found that current versions of AWDL work fairly well and channel hopping only induces a small overhead.
Disclaimer: I'm co-author of this paper and we retrieved this information by means of reverse engineering. If you are interested in the details, please read the paper and have a look at the Wireshark dissector (published soon).
I recently received the Microchip/Roving Networks RN42-APL development kit from Avnet, and I am able to get the sample iOS app to run and do loopback tests and everything is great (BT connects, authenticates, aware that app is on).
However, when I place this board in a real circuit, where data is flowing to the RX-In pins, the RN42 won't even authenticate!
Has anyone seen a functional example of this MFI chip? The whole 'it just works' isn't really ringing true. Is there something I need to -do- before this chip can send and receive data?
what exactly do you mean that the RN-42-APL BT module doesn't authenticate? I used RN-42-APL + MFi 2.0c chip for iOS authentication and it works well. However the newest firmware 5.43 has still some bug related to authentication with Android system. Previously I used BT module with firmware 5.36. Engineer from Microchip told me, that previous firmware had some bugs related to authentication which requires PIN code.
The newest firmware has been improved, but I found another one bug during my tests.
MFi chip must be connected with 2-wires to BT module. This chip uses I2C data transfer. I designed and constructed real device which was based on these components.
Finally, this module works well with iOS, authentication mode you can change with SA,x command. Please read the manual. There are 4 options: 0, 1, 2 and 4.
So I figured out the issue (I think). It was unrelated to the firmware, but it seems that the device wouldn't authenticate if there was traffic on the UART lines before authentication had happened.
I don't know whether where this limitation comes from, nor do I really care, but if anyone runs into this, I would try shutting off UART traffic until authentication.