Came across the interesting service (Experimental) on Bluemix - Driver Behavior. Curious to know how it actually works, how does the data get to Bluemix from the car and is there a need to have an external app/device in the car to collect and post data to Bluemix something similar to Aviva's Rate my Drive app?
One simple example is to use IoT Platform and Node-RED to receive car probe data via MQTT and send the received data into Driver Behavior service in the Node-RED workflow. You can have MQTT client in each driver's smart phone.
I am not familiar with the Aviva's Rate my Drive app, but as far as I searched, you might be able to develop similar kind of application which can analyze driving behavior from car probe data with the Driver Behavior service.
Related
I am a web developer and I am starting to learn about the world of IoT.
Because of the vaccines arrival to my country (Argentina) I got asked to build 80 temperature sensors to monitor them and I have some questions about it.
What would be the best way to connect all of them to the cloud?
If I use for example aws iot platform, do you know how much it would cost monthly for just sending
and storing temperature logs for each sensor (remember, there are 80 of them)?
Is there any language/environment/protocol that works better for IoT? Because it's a constant flow
of lightweight data...
Is there a better way to connect them to the internet besides using esp32 modules for
each?(I saw a tutorial that said it's possible to connect some more to a single esp32 module)
If you have any advice I'd love to hear it. I know how to code but when it comes to backend and specially server stuff I have a lot to learn.
Costs are directly related to the amount of data you send, process and store. You'd have to check the price lists for each cloud service you plan to use. If we assume that you'll be sending 1 temperature reading (with associated data such as timestamp, device id, ...) every 10 minutes using reasonable protocols (MQTT, JSON) then the total costs for all 80 devices would be perhaps a few dollars per month. The total database storage will accumulate over time and you'll be charged more, but honestly the amount of data under these conditions is ridiculously low.
An ESP32 is cheap, has WiFi and enough performance to send data to cloud. You can connect this micro to AWS IoT or Google Cloud IoT using the relevant libraries from either: AWS library or Google IoT library. These libraries decide the questions of language and protocol on the microcontroller side - it's C and MQTT/HTTPS (but avoid the HTTPS, MQTT is much more practial). You can use JSON for the actual temperature data message. The microcontroller development takes place with either ESP IDF (a bit lower-level C environment) or Arduino (a bit higher-level C/C++ environment). Those use FreeRTOS as the OS on micro (note that the IoT libraries work on almost anything).
A practical alternative to ESP IDF and Arduino (especially for a web dev) is Mongoose OS where you can do much of the development work in JavaScript (not all, though). It has high-level libraries for both AWS and Google IoT (which still use the same underlying MQTT/HTTPS client, I assume).
By far the easiest way to connect the ESP32 modules to Internet is to have each connect to a WiFi AP. If the single WiFi AP doesn't cover all devices, add more until they do. ESP32 does have a mesh networking library, but I would hesitate to recommend it to newbies.
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.
I have a few questions regarding onboarding a thing in IBM Bluemix IOT. My questions are as follows:
In scenario 1: Let's say I need to connect only one thing to the Bluemix platform, so I configure the device type, device, authentication token, etc., to connect the device to the platform. This is possible in the current situation.
In scenario 2: If I need to connect 50 things to my platform, will I be configuring each and every device to get the device ID, token, etc.?
Does Bluemix provide any discovery mechanism or other ways to configure things automatically?
You can programmatically register devices using bulk/devices operations. https://docs.internetofthings.ibmcloud.com/swagger/v0002.html#!/Bulk_Operations/post_bulk_devices_add
Also, this recipe describes how to register multiple IoT devices.
If you are using a gateway, devices can be auto registered:
look for "Gateway auto-registration"
Here are some other links that may be helpful.
This recipe talks in detail about how to register a device in Watson IoT Platform - https://developer.ibm.com/recipes/tutorials/how-to-register-devices-in-ibm-iot-foundation/
This Java sample shows how one can do bulk addition/deletion - https://github.com/ibm-messaging/iot-platform-apiv2-samples/blob/master/java/api-samples-v2/README.md
I try to do the POC on IBM Watson IoT platform. I have followed the document in this link for creating the device simulator.
https://console.ng.bluemix.net/docs/services/IoT/nodereddevice_sample.html#devices
It can connect and send the MQTT message event to IoT platform but when I try to get the historical data from REST API, it always returns empty.
https://os9c6l.internetofthings.ibmcloud.com/api/v0002/historian
Not sure what when wrong.
Go to the IoT Watson IoT Platform dashboard connected to your BlueMix app, go to settings and there is a setting for Time Series DB which defaults to Off. When you turn it on you also get to choose the storage duration.
if the Time Series DB was off and the device was added, you might not be able to see it even if you set the historian on on. Try and re-add the device.
I have an idea for an iPhone app that will make billions of dollars for me, and help me take over the world. I am currently designing the architecture of the application. I had originally assumed that I would need to create and host a database that would allow users to upload their data and share it with other, targeted, users. But I thought it would be better if the users could send their data directly to each other without having it stored in a database. However, I haven't been able to find anything that would suggest this is possible.
Is it possible to send data between iPhones that are not in close proximity (bluetooth) and not on a LAN? For instance...User #1, who is in Tennessee, creates some information and hits "Send to others" and it sends that information directly to User #2, who is in Arizona, and User #3, who is in Maine. Could the text messaging functionality be hacked to do that?
(I realize that the phones belonging to Users #2 and #3 would have to be on, and running the app that would receive the data)
I am new to mobile development, and I am still getting used to the functionality of mobile devices so, I am certain this is a dumb question. But, it is worth asking because, if it can be done, this would dramatically change the architecture (and maintenance costs) of this application.
Thanks, in advance, for whatever advice/pointers you can give.
This is something handled by using the publish - subscribe pattern. You may want to look into a plug 'n play service such as pubnub. That will let you do just that. Phones that should be receiving each other's messages will have listeners set up on the same pubnub channel, and will receive a notification when any of the other phones publish to that channel. Something like pubnub has a pretty simple API/SDK that you can use to get a prototype up and running pretty quickly (and for free, at least at first).
User #1's app sends the message to your server. You server does an APNS push to the phones of users #2, and #3. They don't even need to be running the app.
No need to mark this correct or up-vote it, but I will take a high-paying job in the new world order.
Amazon has an application service called Simple Queue Service (Amazon SQS) which Allows you to create queue's with messages in them tat app's can subscribe to.
To quote their page:
Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly
scalable, hosted queue for storing messages as they travel between
computers. By using Amazon SQS, developers can simply move data
between distributed components of their applications that perform
different tasks, without losing messages or requiring each component
to be always available. Amazon SQS makes it easy to build an automated
workflow, working in close conjunction with the Amazon Elastic Compute
Cloud (Amazon EC2) and the other AWS infrastructure web services.
Amazon SQS works by exposing Amazon’s web-scale messaging
infrastructure as a web service. Any computer on the Internet can add
or read messages without any installed software or special firewall
configurations. Components of applications using Amazon SQS can run
independently, and do not need to be on the same network, developed
with the same technologies, or running at the same time.
They have an iOS API to integrate it into your app, and it is free for up to 100,000 messages per month and then $0.01 per 10,000 messages after that.
More info here:
http://aws.amazon.com/sqs/
Is it possible to send data between iPhones that are not in close
proximity (bluetooth) and not on a LAN?
The two devices obviously need some kind of connectivity.
For instance...User #1, who is in Tennessee, creates some information
and hits "Send to others" and it sends that information directly to
User #2, who is in Arizona, and User #3, who is in Maine. Could the
text messaging functionality be hacked to do that?
The problems here are:
helping each device discover the correct address for the others, and...
ensuring that the devices can reach each other.
Mobile devices are constantly moving around on the network and changing their IP addresses as they go. As you're driving to work, your device may have Internet access through it's 3G connection, except for those times when you're driving through a tunnel and don't have any connectivity at all. Once you enter your building, a wifi connection becomes available, so the device switches to that. But your company's network has a firewall that blocks incoming connections, and it's impossible to know in advance which IP address you'll get from the DHCP server at any given time anyway. The same is true for the folks in Arizona and Maine and wherever else.
A server, on the other hand, is usually located at an address that's both easy to discover (thanks to the Domain Name System), easy to reach, and almost always available. For those reasons, it's common to have mobile devices communicate with each other by going through an intermediate server.