Posts Tagged ‘Sensors’
12 Thoughts on the Eclipse IoT Developer Survey
The Eclipse IoT foundation published results of IoT developer survey – this is the third annual installment. Eclipse IoT, under its umbrella, has several significant open-source IoT projects. And if you have not looked at it – it is definitely worth checking out and to be considered for your IoT development strategy.
I would strongly recommending reviewing the survey and also signing up for a virtual meetup that they are hosting to discuss these results. It has very good insights into the state of IoT from a developer perspective. I must admit that I kept intending to fill in the survey myself but despite several reminders ultimately never filled it!.
I would certainly be leveraging the trends in this survey in formulating my strategy with the following thoughts/observations:
- Distributed Software: IoT applications are distributed across Sensor (Device / Thing etc.), Gateway (Edge/Fog/Hub) and Cloud. This year’s survey has the feedback split across the above three. And that’s the right way to look at it because each aspect requires different approach, perspective and strategy.
- Stats 101: Note that the percentages do NOT add up to 100, keep that in mind as you look at the look at them. This is, probably, because it reflects reality – there is no single correct answer. This also, probably, points to a trend that there are multiple projects going on or multiple products being worked on by the same set of developers.
- Javascript is #1 in Cloud: I came to a different conclusion than the survey. Javascript, NOT Java is the #1 language used for IoT for the Cloud. I expect that trend only to accelerate. The reason I claim that is that the survey results are split in Javascript AND Node.js. Node.js is a framework (for a lack of better word in the context of this article) – Javascript is the language. The only discrepancy I can think of is that Javascript may refer to pure User Interface or Web Interface development? The numbers on Gateway are also split into JS and Node.js – and when you put them together – it is higher than C/Python/C++. And by that token – Javascript is #2 as a choice of programming language on IoT Gateways.
- Linux dominates: Raspbian and Ubuntu are winners. Canonical would be very happy or probably already knows this since they are ditching the smartphone/tablet focus and switching over to IoT. I am pleasantly surprised that it dominates constrained devices as well. Reading between the lines – the popularity of Raspberry Pi as a prototyping devices drives Raspbian?
- IoT HW Architecture: The percentages do not represent device or gateway volumes. This is important to bear in mind especially when you look at the results for IoT Hardware architectures. For example 32.9% of developers use Intel x86_64 for Gateways – to state the obvious – these are not 32.9% of gateways but the number of developers.
- Cloud Programming: Ruby On Rails is missing? No mention of RoR in the IoT Cloud. (May be the option did not exist in the survey).
- Machine Learning (Slide #32): Interesting to note that 29.5% of developers claim that they are building machine learning.
- Cloud Services for IoT: No IoT platform other than GE Predix made this – e.g. no PTC. (this is a blog post in itself given the huge number of IoT platforms out there).
- Connectivity Protocols: This actually mixes both – transport or medium of connectivity and also the ‘data’ protocol. To give an example – Cellular, from a developer perspective, is IP (Internet Protocol). Same with Wifi & Ethernet yet TCP/IP is broken out separately. Zigbee & Thread are mapped to IEEE 802.15.4. This is important to keep in mind because you can’t easily split IoT into black and white categories. There is shades of grey all around.
- Messaging Protocols – yet another sign – there is absolutely no point in trying to get to one standard – the use case should drive if you want to use HTTP, MQTT, XMPP, CoAP etc.
- Industrial Protocols – this is a great slide. It would be interesting to dig into what “None” really implies – does it imply that it is proprietary?
- Leading Indicators – these results are leading indicators – of things that are to come. The survey is what the developers are working on (presently or in recent past). And that makes them more interesting because they are indicators of where IoT is heading.
IoT: Where do you begin?
Kevin Ashton, the father of IoT, has a simple advice for companies looking to leverage and benefit from IoT – “Begin”. In Why the Internet of Things isn’t like the Big Bang Kevin says, and I quote:
In what Ashton calls “the wild frontier of IoT,” the best advice he can give is “Begin.”
“There’s too much sitting around in meetings, staring at PowerPoints, waiting for someone to tell you the answer. When someone else knows the answer, you’ve already lost.”
But where to begin? Pick an internal project, and enable it with IoT. Roll it out to a limited set of customers, learn, tweak and update the solution. Analytics is supposed to be the big killer app – the data coming in from these sensors, and things that would unlock the potential of Big Data or Small Data. But to begin – collect the data. Or if you are already collecting the data (and many industrial companies have been doing “IoT” for a long time) – figure out a way of putting a wrapper around that system, and APIfy it.
That’s how to begin…
Internet of Things: IP or Not
Rethinking the Internet of Things: A Scalable Approach to Connecting Everything (which BTW is free for the Kindle Edition) makes the case for a Non-IP (non Internet Protocol) stack approach for “things” to be connected. While I am in agreement in the author, the approach seems to be all or nothing – which is not true either. I feel that for constrained devices, that emit limited data and require low bandwidth – a non-IP approach makes sense. I am not entirely clear on how many of those billions of connected devices are really simple/constrained devices.
There would be three categories of “things” based on how they connect to the Internet:
1. Devices/Things that have the resources (CPU/Memory/Connectivity) to support and run the TCP/IP stack similar or identical to ones found in PCs/Macs/Tablets/Smartphones.
2. Simple, Standalone Devices or Things: More like sensors that have limited resources making it unsuitable even for running the constrained version of IP stack – 6LoWPAN and its variants – will need to support a connectivity protocol/stack that is ideal for the low bandwidth, long battery life requirements.
BTW these type of devices/things have been around for decades now – however getting them connected to the “Internet” allows making their data available, and hence unlocking the value.
3. Complex Devices/Things – These are hybrid of 1 and 2 that is they have their own “network” not based on IP – and may leverage connectivity/protocol specific to its industry or use case. And it has a integrated gateway or bridge that takes relevant data back and forth between IP and its internal Non-IP network. A great example of this is an Automobile (now popularly in the IoT vernacular being called “Connected Car”) – the automobile makes use of CAN Bus (since the 1980s). Autos are now connecting up to the Internet using Wi-Fi or 3G/LTE (or both), and they are building in functionality to go back and forth over an IP connection to the CAN Bus as well.
4 Implications of Apple’s HomeKit
HomeKit defines a language, API, taxonomy (albeit for IOS devices only) to discover, pair, and control home automation devices (more about it here). The technology is very interesting, but it has implications and raises questions:
1. AllSeen/AllJoyn defines a protocol for a proximal network (i.e. local to the premise) and is limited to Wi-Fi with some support for Bluetooth. HomeKit is solving a very similar if not identical challenge. What would manufacturers prefer – AllJoyn/AllSeen or HomeKit? With limited resources would they give priority to AllSeen/AllJoyn?
2. The basis of HomeKit, appears to be a common database where information on the Accessories is stored – there location within home, the common name given to them, rooms they are in etc. Would for example the IOS App for Comcast Xfinity Home or AT&T Digital Life be willing to give access to their devices to other app developers? I am willing to bet because their solutions are anchored on professionally managed security, they probably will not.
3. AT&T and Comcast (as an example because their home automation & security service is widely deployed in the US) may not open up access to devices their systems control in their IOS apps however consumer apps for Philips Hue or NetAtmo using HomeKit would probably allow access. Do you think the likes of Philips Hue or NetAtmo would be ok with that? Or would be their policy controls in place during app approval or access controls allowing some degree of control to Philips and NetAtmo as an example?
4. HomeKit will have complex scripting capabilities – going beyond what IFTTT can do. HomeKit possibly solves the software challenge much better than Revolv with its consolidated app for controlling many things through its hardware (in reality controlling the Wi-Fi or Ethernet connected devices such as Philips Hue or Sonos does not require their hardware/gateway). What role do companies like IFTTT (from a HomeAutomation perspective only, not the many other functions it provides. IFTTT has simple if-then rules only today operating through the latency of an internet connection) or Revolv play with HomeKit? Did Apple disintermediate the likes of IFTTT for Home Automation and Revolv?
Trying the much-hyped Twine
Twine is probably the geekiest of all the Internet of Things projects from Kickstarter – 8 of which I covered here. Twine is not for the ordinary folk. And it is expensive – with the full sensor kit [kit at the Twine + the Breakout Board, Magnetic Switch, and the Moisture Sensor] – it is for $199.95.
The looks are also geeky. And to get started you need a PC or Mac and has a WiFi Interface. I had ordered my Twine in December 2012, and finally started playing around with it this week – actually my first try was in January [then either it quit working on me or the batteries died, I never quite figured out what happened].
Setup:
You need a device or a computer with a browser to setup the Twine, and whatever you use is compatible with 802.11b WiFi. Setup can be confusing even though Twine on has simple enough instructions. The orientation of Twine is important – when setting up you have to place it with its back [where the instructions are written] facing up and then go to TwineSetup.com.
The first time when I tried it in January it worked for me easily enough. When I set it up yesterday all over again – I could not get the web page to show me the Wireless network to connect to [this is the screen with no wireless networks listed in the pull-down]. So I had to set it up using the other screens that they have for configuring the Twine. In the last step you need to create an account with the Twine website.
Once it is setup, all the information from your Twine can be accessed on to your web dashboard at twine.supermechanical.com.
Initial Thought
s:
While the Twine is interesting I find it bulky – the size of Twine is bigger because it uses WiFi as its connection and it needs two AAA-sized batteries. The upside of using WiFi is the controller to talk to the Web is not separate from the sensor. Twine is a controller and sensors all in one. The integrated sensing capabilities of the Twine are limited to Temperature, Orientation and Vibration. Vibration has been added recently since when I tried it in January it was missing. Enabling Vibration sensing to show on the Web Dashboard requires that you first setup a rule.
One more change Twine has made is to configure how often the Twine updates the status to the Web – the slower updates consume less power and can run on batteries longer.
Twine can be powered by a USB connection but that makes it impractical to be used in some situations. Twine has a rubber jacket that slides to insert the batteries. I found the insertion of batteries or removal to be a major pain – the rubber jacket is not easy to slide. I wish that Twine had a better industrial design.
Use Cases:
The website lists many suggested use cases – the challenge is that for each of these you would need a Twine – do the math at 125 a pop – the 18 use cases listed [and screen captured and stored on my Flickr account] would cost you almost $2250!
This is the reason I find Twine to be an impractical IoT platform.
I would mu
ch rather prefer using the Wireless Sensor tags that I covered in my earlier post. Mounting the Wireless Sensor tags on the door to sense door opening using motion is so much practical compared to mounting the Twine. [Take a look at this picture of the Twine and the Wireless Sensor Tags side by side.]
What I have tried out, and I like:
Because the Twine connects directly to the Internet, the updates reflected on the Web dashboard are fairly fast. I was impressed (after enabling the Vibration sensing through the Rules) at how fast the dashboard on the website showed the vibration measurement after I just tapped my finger on top of the Twine.
My home has become an experiment for Internet of Things, and one of my favorite tests is to put the controller or sensor inside my refrigerator and do temperature-sensing testing and also range testing. The Twine worked pretty well. The ambient temperature sensor on the Twine took about 30 minutes after placing it inside the refrigerator to adjust or show the temperature [of the
refrigerator].
I also loved the packaging – it was nice, and the unboxing experience was fantastic.
The To-Do List:
I still have to try out the three sensors that I received. The sensors can be connected to the Twine via a connector and special cable provided. Of course – you can only have one connector at a time.
The power of Twine comes from being able to setup notifications that are delivered via email or text messages – that is next thing to be tried as well.
Bottomline:
My initial analysis – I would be opposed to using Twine for automating my home or connecting it to the Internet – the cost is high, the form-factor is bigger, and it also lacks smartphone or tablet apps. I will continue to review further and try to use it for different scenarios – maybe I will change my mind about it.
Wireless Sensor Tags
The first I had read about Wireless Sensor Tags by CAO Gadgets was last year. I finally ended up ordering them in December. And as I begin to write this review, I came across an excellent review by Alasdair Allan – here it is: Teardown of Wireless Sensor Tags. I am going to defer to Alasdair for the fantastic overview and build on it. I would like to summarize from his post the hardware on the tag:
Processor: Microchip PIC16LF720 micro-controller
Wireless: Microchip MRF 49XA
Motion Sensing: Honeywell HMC5883L
The tags are using the 433MHz frequency – which does not need a license in the US.
Alasdair makes a remark on the choice of the sensor being based on a magnetometer – which would give good angular measurements. I have not tested the precision of the angular motion but it uses angular motion for setting the tag for door open/close sensing. The picture below from the Web App shows you can select different angles as threshold for triggering the alert.
My experience with the software has been decent. It is at time somewhat confusing. With trial and error you will get it but given that the subject matter is complex and in my opinion the audience for this system is more of the geeky, hacker and DIY nature – we can live with it. For example – it is not clear the first time that you need to click on the “Motion Sensor” menu entry after you have clicked on the “Options” button under the tag you want to configure. There are small little things like this that make it challenging.
I have tried both Android and the IOS Apps – I would have to say that I am a bit disappointed because it is a short-cut. The Web App is implemented using HTML/jQuery and the UI of the mobile apps suggests that they are built using HTML/jQuery vs. a native application. One more thing that I still need to figure out – how do you “remove” the phones. Once you have installed apps on your phones and signed into your account – they will show up in the configuration. For each sensor – you can setup the trigger to notify the phone you have installed the app. Interestingly I had given my Nexus 7 to my son so I want to try and remove it (you can see it in the image), and the “Unknown” is a result of the app being setup and I missing an opportunity to name the phone. None the less I don’t see any mechanism of removing both these entries and starting over.
Notify Phones
The door open and close of the sensor tags seems to work well. I have tried both the Phone Notification, emails – and they work. Range has been pretty decent – at my home. I have the Tag Manager in my basement and two of the sensors on the floor above – one of them to detect garage door open or close. The third sensor – I wanted to use to monitor my refrigerator – its opening/closing and also the internal temperature. And the tag goes out of range when I put inside the refrigerator.
As a next step I need to do a couple of things: test the angular sensitivity / precision and try to understand the range impact of having the sensor inside the refrigerator. The picture below shows how the Wireless Tag Manager compares in size to the Twine (SuperMechanical), the Node (VariableTechnologies) and the Fitbit.
8 Internet Of Things & Sensor Projects on Kickstarter
1. Twine
Product Description, Technology and Pricing:
Twine is a durable 2.5″ square provides WiFi, internal and external sensors, and two AAA batteries that last for months. It will sell for $99 through their site. The temperature, vibration, and orientation sensors are built into Twine. The primary interface to communicate with Twine is WiFi – and a Web App is provided. Additional sensors – Magnetic, Moisture and a Breakout Board for interfacing your own analog inputs can be bought separately to the Twine.
2. Knut
Product Description, Technology and Pricing:
Knut is also a WiFi connected sensor hub. The Knut access is WiFi based hence you can access the data captured or action from a PC or a Smartphone. Knut/Amperic talk about bringing in IOS and Android apps. The last update (Update #11) on the Kickstarter talks about their move to 11g as the WiFi protocol and the status of their IOS Apps. Knut has only a temperature sensor and battery sensor built into. Additional sensors Amperic/Knut planned are humidity, vibration, door, water proof temperature, and water presence. These sensors connect to the Knut using a 3-port hub.
3. Ninja Blocks
Company: Ninja Blocks
Product Availability: Anyday now? Website indicates that they are sold out.
Product Description, Technology and Pricing:
Ninja Blocks wants to bridge the physical and virtual world, it wants to create an IFTTT (if this then that) to connect physical actions to virtual worlds. Each NInja Block comes with an LED (RGB), a Temperature Sensor and Accelerometer. Inputs and sensors can be added or connected to a Ninja Block using 4 Expansion Ports and USB. The difference in approach is that they want to have their cloud (Ninja Cloud) to setup sensors (Ninja Blocks) to cause a trigger actions to generate virtual world actions. The example on their site is a Motion Detector generates a Tweet with a picture. It would support integration with popular services such as Dropbox, Twitter, Facebook, Google Docs etc.
3. NODE
Company: George Yu, Variable Tech
Product Availability: As of today – shipping in 2 weeks or so.
NODE is cylindrical tube with Bluetooth LE 4.0 as its primary interface, and Smartphones/Tablets as the platform for accessing. NODE is compatible with Arduino, has built in Accelerometer, Magnetometer, Gyroscope. Additional sensors can be connected by removing the end of the NODE KORE – similar to screwing on a cap.
5. Bitponics
Company: Bitponics
Product Availability: As of today no updates on the Website of Bitponics on availability. Update #10 on the Kickstarter site is only available to the backers. So no clue on what is going on 🙂
Product Description, Technology and Pricing:
6. Wovyn
Company: Wovyn
Funding Failed
7. DaisyWorks
Company: DaisyWorks
Funding Failed
8. SmartThings
Company: SmartThings
As of August 28th 2012, 9:45PM Eastern:
2,393 Backers
Availability: Funding Open
Product Description, Technology and Pricing:
This is the latest kid on the block, and apparently drawing a steady stream of praise from the top tech blogs. It has passed its goal so it will get funded. Their approach is to build a pro-sumer Home Automation, Monitoring and Energy Management system. It consists of a SmartThings hub to which the sensors are connected wirelessly – Zigbee and ZWave are mentioned. Not sure if it has any proprietary 433MHz or 900/15MHz Radios on them. No WiFi, Ethernet to connect to the Router. NOW that would make it very interesting because if you are forced to place this near to your home gateway you may have challenges with the radio reach on this thing.
Cancer Sniffing Sensors (& Dogs?)
The Metabolomx machine looks like a desktop PC with a hose attached. It sits on a cart that can be wheeled up to a patient, who is instructed to breathe in and out for about four minutes. The machine analyzes the breath and its volatile organic compounds, or VOCs—aerosolized molecules that, among other things, determine how something smells. Tumors produce their own VOCs, which pass into the bloodstream. The lungs create a bridge between the bloodstream and airways, so the breath exhaled by a patient will carry the VOC signatures of a tumor if one is present. “It may seem surprising, but it’s actually very straightforward,” says Paul Rhodes, the co-founder and chief executive officer at Metabolomx.
A few years ago researchers in California received widespread attention for showing that dogs can smell cancer on a human’s breath. With 99 percent accuracy the canines could detect if a person had lung or breast cancer, beating the best figures from standard laboratory tests. Subsequent studies confirmed the results and provided further evidence that dogs really are man’s best friend.
Seismic Detection Otis Elevators
Smart, smart design. And guess what it all worked! Otis demonstrated great customer responsibility ….
The United Technologies elevator unit took 13,000 calls from Japanese customers in 48 hours and restored service to 16,400 lifts within seven days
Michaud-Daniel knew Otis had technology on its side, since about half the elevators it maintains in Japan—including most in high-rise buildings and regions with severe earthquake risk—are equipped with seismic detectors. At the first vibration signaling the onset of a quake, these devices return the elevators to the ground floor so passengers can exit, then block them until Otis can check their safety.
The detectors worked. Some 16,700 elevators in the areas affected by the quake were shut down by the emergency systems. Otis, which had worldwide revenues of $11.58 billion in 2010 and manufactured about 40,000 of the 80,000 elevators it services in Japan, didn’t receive any report of trapped or injured passengers. “All the elevators operated as they were supposed to,” says Michaud-Daniel.
All Things CC: 