What's the purpose of Metadata for device config? I see when I create a device and add metadata, it comes to PubSub as a message attribute. It's very useful, for instance for Dataflow processing, I can make some aggregation and build additional logic without data enrichment operations.
But, when my device sent data through a Gateway - no attributes in PubSub message. I can add metadata to Gateway but the same result - no attributes in PubSub message. Why?
The device metadata's main use is for storing serial number, manufacturer as a key-value pair and hence used for defining and classification of devices. It helps in identification.
The device metadata is never sent to or from a device as metadata is used mainly as an identifier or label for devices. It is by design that the cloud IoT Core shall not interpret or index device metadata
and the metadata can only be used for identification purposes.
Device metadata stays in cloud and hence it cannot be used for storing information that needs to be sent from or to a device. Accordingly, in theory it is considered that the device metadata is more secure because device metadata is never sent to or from a device. Such information should be in a device configuration if it has to be sent to a device, or in device state data if it has to be reported to Cloud IoT Core.
Related
I tried to configure a bonding pincode on my Movesense 2.0.0 sensor and I was expecting being asked for it when trying to connect to the sensor with MDS or apps like nRF Connect.
But what I got looks identical to Just Works mode, and the bonding PIN is being asked only if I try to pair the device through system's Bluetooth settings. Does it happen because in the first case there's only connection and no pairing? What are the pros/use cases for having the sensor paired at system-level?
I'm looking for a way to prevent unauthorized access (connections, API requests) to sensors from devices not knowing a secret access code (like a PIN). Do BLE/Movesense provide such a mechanism?
Neither Bluetooth nor Movesense offer a way to securely "log in with a secret password". The passkey bonding mechanism that is present in Bluetooth, is only designed with the purpose of avoiding man in the middle attacks, and the passkey must be random everytime since the protocol reveals the key after each attempt. A static passkey which some people use is not allowed per the specification. It might keep away your grandmother from accessing the device, but is not secure at all at a protocol level.
If you bond the device at a system level, the further communication will be secure (encrypted and authenticated) and will for example prevent spoofing attacks. It will also result in quicker device connection setup since GATT caching can be used.
You are not saying what "system" you are using so this is just a general answer.
As far as I understand the USB devices introduce themselves by sending a device descriptor to the host which uses the information embedded in the descriptor to find and load the right driver/drivers. What I don't understand is why the drivers need the configuration, interface, endpoint and string descriptors from the device. I know the descriptors describe the device as a whole e.g. number of configurations, interfaces, endpoints, types, the size of the packets, the purpose of each byte in the packet etc. Why can't the drivers include this information from the start? Why does the USB device hold this information?
I guess the main reason is because it was designed that way. The designers could just as easily have gone the other way as you say.
Possibly more helpfully, I can think of a few reasons why they did decide on it this way:
Consider the context in which USB came about. PC peripheral connectivity was a mess. You had serial (UART) ports, PS/2 keyboard & mouse, parallel ports in various modes (e.g. ECP and EPP), game port & MIDI, the various SCSI variants, etc. Most of these did not allow for self-describing devices in a standardised way, demanding custom drivers for each type of device, and mostly manual driver loading. Device descriptors alone would mostly solve the problem of selecting the correct driver, but not necessarily the issue of needing a custom driver for each device.
Various standard device class specifications (e.g. HID, audio) define their own class-specific descriptors for communicating device variations to the standard driver. For this reason alone the generalised descriptor mechanism is useful.
Composite devices in their present form would effectively not be possible without standardised interface descriptors. You'd presumably have to make each composite device act as a hub with multiple devices attached.
Many (most?) standard device class specifications mandate a certain minimum number of endpoints where the standardised protocol is implemented, (e.g. bulk-only USB mass storage defines 1 bulk input and 1 bulk output endpoint) while devices are free to add more for vendor-specific extensions, or…
…future expansion of the standard device class or USB standard itself while maintaining backwards compatibility both ways (old driver/new device, new driver/old device). Think of UASP devices that fall back to regular bulk-only mass storage transport.
While not strictly necessary for making all those things happen, making devices self-describing in this way does seem to have been a success overall.
I couldn't find any documents on how to connect to Google Cloud IoT MQTT bridge from Swift-based applications. Is it possible to connect? Any references or links or samples would be appreciated.
Edited answer responding to comment: To connect using the MQTT bridge to IoT Core, check out the code here.
We don't have an IOS/Swift code example there, but you should be able to see the various pieces you need from the Node or Python examples. The URL/endpoint for IoT Core is mqtt.googleapis.com:8883. The MQTT client's user/pass is going to be blank for the user (unused) and the encoded JWT for the password. The same code has what it looks like, and should be enough to get you started hopefully.
To communicate with IoT Core, the MQTT topics are devices/<device_id>/events/ for telemetry from device to Cloud, and if you want to report state of the device to be stored by IoT Core, it's devices/<device_id>/state/ and if you want to send messages from IoT Core back down to the device, it's either devices/<device_id>/config/ for persistent messages that will be delivered on connect if the device isn't actively connected, or devices/<device_id>/command/ if it's more of a fire and forget, lower latency type message.
Original answer: We don't have any documentation around this particular use case yet, but I found this:
https://github.com/emqtt/CocoaMQTT
Which enables MQTT client connections from IOS and is written in Swift, so that should work. In addition to this, you'll need a library to encode a JWT (Json Web Token) for the auth side of things.
Having said that, you could ditch MQTT entirely and just use the HTTP bridge in IoT Core, as that might be easier? You can see the docs for doing that here: https://cloud.google.com/iot/docs/how-tos/http-bridge. You'll still need the JWT piece for the auth, but it would keep you from having to implement MQTT in the app.
Simply put, how does Eddystone-EID work and what are the main use cases?
Standard beacons transmit a unique identifier so apps can tell when they are in a particular place. But because this identifier is in clear text, any app can read this identifier, and use the transmission to know where it is. An unauthorized third party app can make use of standard beacons that the app's authors did not deploy.
Eddystone-EID encrypts it's identifier and rotates it periodically to prevent others from making use of the beacon identifier. Authorized apps can use a "trusted resolver" to get a stable identifier from the rotating encrypted one in the transmission. A server call is needed to convert the 8-byte AES encrypted identifier to a stable one.
Google's Proximity Beacon API provides this conversion. It is theoretically possible to build an independent trusted resolver apart from Google (I have done so for testing purposes), but otherwise you must register your EID beacons with Google and use their web services to resolve their identifiers.
An example ephemeral identifier looks like this:
0a194f562c97d2ea.
Here's a write up I did on the topic: http://altbeacon.github.io/android-beacon-library/eddystone-eid.html
Here's an explanation I found on a developers.google.com page here.
What happens when a client sights an Eddystone-EID beacon?
When a client device sights an Eddystone-EID beacon as a result of a Nearby1 subscription, the current EID is sent to the Google Proximity Beacon API2 along with the API key of the calling app. The Google Proximity Beacon API establishes whether the supplied API key is authorized to fetch attachments that have been associated with the beacon. If resolution is allowed, the attachments are served back as Nearby message objects in the normal way. Otherwise, Google Proximity Beacon API returns an empty value, as it would if the beacon had not been registered.
1 - The beacon scanning component of the Google beacon platform
2 - The Proximity Beacon API is a cloud service that allows you to manage data associated with your BLE beacons using a REST interface.
Here's another paragraph which I found critical to understand how the technology works.
Eddystone-EID is designed to give developers control over which clients can make use of their beacon signals. The beacon identifier changes pseudo-randomly in such a way that it can only be resolved to stable information by a resolution service that shares an encryption key with the beacon. Without access to the resolution service, the beacon identifier is of little use.
Eddystone-EID is appropriate for cases where beacon deployers wish to:
Prevent other parties from using their beacons.
Preserve user privacy in scenarios involving wearables or other equipment carried by the user.
Lease their beacon network to other parties in a way that allows a provable 'off switch' for access.
Provide a strong signal that a user is at a particular place, that is not easily spoofed.
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.