SensorUp just became the newest member of the Eclipse Open Source Foundation! SensorUp's goal of interoperable IoT fits Eclipse's vision and mission perfectly. SensorUp's Open Geospatial SensorThings API platform is location-intelligent and designed specifically for IoT, and that also means we match the focus of both Eclipse LocationTech and Eclipse IoT. What a great match and we feel like home! We are very excited and looking forward to working with Eclipse to empower developers to innovate to unleash the potential of IoT with open standards and open source.
Noah Liang (梁文諾), our first baby, was born on Nov 9th. We feel in love with him right away, and I have to say, he is soooo cute. 
Of course, we try our best to offer him the most comfortable environment to grow. As the founder of SensorUp, of course I am trying to "sensor up" his nursery (#connectedBabies, #walkTheTalk).
Currently we have the following sensors:
To ensure a comfortable environment, we have a air quality station (temperature, humidity, CO2, and noise level):
To ensure a great feeding atmosphere, we have Philips Hue:
Every parent needs a baby monitor, and we have Nestcam for video and sound:
And we need to control the room temperature, so we have Nest Thermostat:
Finally, I would like to know Noah is feeling warm or cold in his cute tiny PJ, I use Texas Instrument's SensorTag. (BTW, I am writing a new blog tutorial about Noah and SensorTag.)
Wanna guess how many APPs do I need in order to see the readings from these sensors/actuators? These sensors are from four different vendors and I need four different APPs. Switching back and forth from each APP is VERY frustrating and time consuming, especially when Noah is crying at midnight. 
I know there are some companies (maybe too many) trying to address the issues, such as SmartThings (acquired by Samsung in Aug 2014) and Revolv (acquired by NEST in Oct 2014). I had the pleasure to attend the Under The Radar Conference (UTRConf) 2014 with both companies' founders. There are also big giants, like Apple's HomeKit, GE's Wink, in the game. And there are industry alliances working on this issue as well, such as Allseen Alliance and oneM2M. Currently the situation of fragmentation is getting even worse because seems every IoT company, small and big, is trying to create a new ad-hoc standard, claim it is open, and try to lock everyone in their proprietary ecosystem. (ps. Heard of the famous quote about standards? "The nice thing about standards is that you have so many to choose from", Computer Networks 1988)
I think eventually the consumer markets, especially smart home and wearables, will find its way to integrate these smart objects at home into a system of systems. I just hope the solution will be an open ecosystem, so that everyone can innovate but not the selected few software giants.
People say new baby give parents new meaning. I think my baby just strengthen my goal to disrupt the IoT silos!
Webinar Recordings
Introduction to SensorThings - #1 of 4
The Thursday, November 26, 2015, webinar recording is now available: Steve Liang introduces the SensorThings API -- the Open Geospatial Consortium (OGC) candidate standard for the Internet of Things (IoT). He describes the broad reach of IoT, and the power of connecting sensor data. He also introduces SensorUp's Platform (sensorup.com) the first implementation of the SensorThings standard.
Webinar slides are posted to slideshare as well.
Thanks to all those who attended, and for your great questions!
IoT Data Modeling with Open Standards - #2 of 4
Steve Liang goes over the SensorThings Data Model. He explains each element of the data model, and their connections. He then illustrates with IoT use cases. Finally, he introduces the SensorThings Playground, showing how to walk through the guided setup, and how to use the code generated.
Webinar slides are posted to slideshare as well!
Thanks to all who attended, and for all your great questions! See you Thursday, December 10, 2015 at 1pm EST. We'll go over RESTful Pattern for IoT API.
We'll post a blog about literature sources for IoT (geo)semantics and (geo)ontology, and link to it here when it's posted.
RESTful Pattern for IoT API - #3 of 4
Steve Liang explains how to access sensor data, or IoT data via SensorThings. He explains the RESTful pettern for IoT API. He provides numerous demonstrations to illustrate how to access your sensor data by constructing requests to the SensorThings API.
Webinar slides are posted to slideshare as well!
Thanks to all who attended, and for your great questions! See you Thursday, December 17, 2015 at 1pm EST. We'll go over Connect Sensors to SensorThings API - CREATE, UPDATE, DELETE.
Connect Sensors to SensorThings API - CREATE, UPDATE, DELETE - #4 of 4
Dr. Steve Liang explains how to register new sensors, observations, things and other entities in SensorThings. A live demo shows the process in detail, including REST calls using postman.
Linkage:
Slides
SensorUp Developer Centre
Git
SensorUp Playground
SensorUp Documentation
Postman
Big Thank-you to everyone who attended the Getting Started webinar series!
We sincerely appreciate the interest we received from all over the globe, from both individuals and large organizations.
We got so many questions along the way that we're now planning a second series to begin mid-February 2016. Before that, we'll also be delivering a webinar through Eclipse Foundation about open iot and open standards for iot, SensorThings in particular. Hope to see you there!!
This is a step-by-step tutorial regarding creating a Thing instance, the related entities with SensorThings API, and eventually upload sensor readings.
You can also download the Postman script here (download). (Note: Postman is a great tool for sharing and sending RESTful requests.)
If you haven't seen the OGC SensorThings UML diagram, it might be a very good idea to look at it first (link to UML).
Step-by-step guide
Step 1: CREATE a Thing entity instance as well as the Thing's Location.
In this case, a weather station is modelled as a Thing in the SensorThings API data model. The Icelandic Weather Office (example station) provides excellent data description and we can easily convert the table into the following SensorThings API JSON.
POST: URL_to_the_Server (You can use SensorUp's sandbox server: http://chashuhotpot.sensorup.com/OGCSensorThings/v1.0)
Header: Content Type: application/json
Step 2.a: CREATE an ObservedProperty instance (when the observed property doesn't existing in the system)
If no existing ObservedProperty, create an ObservedProperty entity instance by POST the following JSON to the server. An ObservedProperty describes what is the phenomenon a datastream is measuring. And once an ObservedProperty is created, it SHALL be reused by other Datastreams that measuring the same phenomenon. In this example, we use the definition from DBPedia. Note that different domain application might have different definition though.
Step 2.b: When the observed property already exists in the system.
When the ObservedProperty already exists in the system, Go To Step 3.
Is the ObservedProperty already in the system?
You can simply issue a request to URL/ObervedProperties to list all the existing ObservedProperties in the system (e.g., click here), and find the one you can use. Only create new ones if you cannot find an existing one.
Step 3.a: If no existing Sensor, CREATE a new Sensor.
Similar to the previous step, if the Sensor doesn't already exist in the system, create a new instance by POST the following JSON request. However, if the Sensor already exists, it should be re-used.
Differences between Sensor and Thing?
How a Thing different from a Sensor??
A Sensor is "an entity capable of observing a phenomenon and returning an observed value. Type of observation procedure that provides the estimated value of an observed property at its output. [OGC 12-000] ". For example, a Campbell weather station (e.g., road weather information station) can be modelled as a Thing, and multiple Sensors (examples) can be mounted on the station.
Step 3.b: If the Sensor already exists.
Go to Step 4.
Step 4: CREATE a new Datastream by linking to the newly created (or existing) Sensor and ObservedProperty
Step 5: If the FeatureOfInterest is different from the Thing Location, then either CREATE a new FeatureOfInterest or LINK to an existing one.
In this example, the FoI and the Thing's Location are the same, so we don't need to do anything. Server will create the FoI automatically.
Step 6: CREATE new Observations
Finally, we have established all the required "metadata" for the observations. Now we can upload many many observations to the system.
Step 7: Retrieve the uploaded Observations
Finally, you can retrieve the Observations you just created by issuing a GET request to the server URL, like this: http://chashuhotpot.sensorup.com/OGCSensorThings/v1.0/Datastreams(453609)/Observations
BTW, feel free to ask questions by leaving comments below. 
Related articles
Would you like to explore the world of IoT (Internet of Things) without having to digest a technical specification, or detailed API documentation? Here at SensorUp, we understand the power of open standards – specifically the Open Geospatial Consortium SensorThings API candidate standard – but also that powerful things often have a learning curve. As such, we are preparing the SensorThings Playground: a web application that will allow interested people and organizations to experiment with a SensorThings system via a friendly, step-by-step process.
In just a few minutes, you can register and begin creating virtual Things and generating Observations which are displayed to you graphically in real time. At the same time, you will be exposed to the concepts of the SensorThings API, preparing you to imagine innovative applications and solutions for your organization's needs.
For developers who want to advance from "gentle SensorThings introduction" to "full-fledged API consumer", the Playground also provides HTTP RESTful requests that allow you to programatically invoke the same operations performed by the guided user interface.
The SensorThings Playground is expected to launch in the coming weeks.
SensorUp aims to disrupt the silos of the Internet of Things. We believe in an open ecosystem for IoT rather than fragmented, silo-ed, and proprietary IoT system. The real potential of the IoT is creating value from an interoperable system of systems, like today's Web.
Open standards enable interoperability. For example, the OGC SensorThings API is an IoT data interoperability standard. SensorThings API is a candidate Open Geospatial Consortium (OGC) standard to share IoT sensor data and relevant location information over the Web. However, having a standard specification does not guarantee interoperability. A conformance test suite, that validates the implementations of the standard, is critical in order to ensure the different implementations developed by different organizations can interoperate with each other. That is the reason we devoted time and efforts to work on the SensorThings API test suite when we are finishing the final phase of SensorThings API. To learn more about the value and importance of standard compliance, below is a great video from OGC.
We proudly announce that our test suite for SensorThings standard API is released today. It helps SensorThings developers to verify conformance of their SensorThings API implementations. The test suite is written in Java using TestNG framework for execution on TEAM Engine (Test, Evaluation, And Measurement Engine). The SensorThings test suite is available on the OGC Compliance and Interoperability Testing and Evaluation(CITE) website in Beta version. Also, the project details, including the release notes and JavaDocs, are available here. You can test your service against SensorThings API after registering on CITE website.
BTW, make sure to use a sample service for the purpose of testing. As our test suite will test not only retrieving the IoT data but also creating, updating and deleting the IoT data. That means you might lose some of the data of the service being tested.
Having a compliance test suite is a major indicator of the maturity of the standard. I assume you would agree with me that an interoperable standard without testing is not very useful. Releasing the SensorThings test suite is a major milestone towards to an interoperable IoT ecosystem. We are very glad to be part of this.
Note: We would like to thank all the helps from Dr. Luis Bermudez, the Executive Director of the OGC’s Compliance and e-Learning Program. It was a great pleasure to work with Dr. Bermudez for this exciting development.
Reposted from an OGC Blog post by Steve Liang (founder and CEO of SensorUp and editor of the OGC SensorThings API)
Interoperability is a major challenge for the Internet of Things (IoT). The real potential of IoT, like the potential of the Internet itself, lies in “systems of IoT systems” rather than IoT systems that operate as isolated technology silos. Real interoperability requires layers of standards, and each layer addresses different interoperability challenges.
Amazon Web Service (AWS) IoT, announced in October of this year, “is a managed cloud platform that lets connected devices easily and securely interact with cloud applications and other devices.” With AWS IoT, any organization, small or large, can develop message exchange infrastructure for IoT devices at scale.
AWS IoT supports MQTT, an open standard from OASIS. MQTT “was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium.” There are many other network interoperability standards (LWM2M, CoAP, etc.) that enable message interchange, and AWS also supports some of these.
The figure above shows an IoT value chain from a standard layers perspective. Although AWS with MQTT addresses IoT network interoperability, it doesn’t address IoT data interoperability (or semantic interoperability). So, to put it another way, AWS IoT does address how IoT messages are exchanged over the network, but not how the exchanged messages can be used and understood by devices and applications.
The OGC SensorThings API is a candidate OGC standard that defines requirements for a standard API that when implemented provides IoT data interoperability. The API defined in the candidate standard is an extremely lightweight IoT Data Interoperability standard that uses both MQTT and HTTP REST.
The OGC SensorThings API and Amazon’s offering complement each other very nicely.
“Data interoperability” means the ability to meaningfully share data. Network interoperability has no value if the bits and bytes are delivered but can’t be interpreted, that is, if their meaning can’t be known. “Things” in the IoT are sensors and actuators that have locations, descriptions and instruction sets. Data provided by a sensor has a “data model” that needs to be published by the sensor so the data’s structure and content can be known.
SensorThings API is part of the well-established OGC Sensor Web Enablement (SWE) suite of open international standards. SWE standards are in use by many large-scale organizations such as NASA, NOAA, USGS, Natural Resources Canada, the World Meteorological Organization (WMO) and many others, including many private sector companies. Unlike the other SWE standards, however, the SensorThings API is specifically designed to be lightweight and “RESTful”. Most IoT developers need to quickly develop IoT applications without getting too deep into the complexities of geomatics and sensor semantics. Often these are near-real-time applications that will need to accommodate large numbers of devices and high transaction rates. If the developers implement SensorThings API, they can be confident that they are accomplishing those objectives while putting in place a good foundation for future expansion and integration with more “industrial grade” service-oriented location and sensor semantics platforms.
The OGC SensorThings API Standard enables organizations to build IoT solutions that can be used and understood by heterogeneous IoT systems. SensorThings API’s data interoperability complements Amazon’s message exchange. Used on top of Amazon’s IoT service, the SensorThings API provides a modern, scalable, flexible, elegant, and – most importantly – interoperable way to access and manage IoT observations and associated location data from heterogeneous devices.
AWS IoT, MQTT and many other network interoperability standards (LWM2M, CoAP, etc.) enable message interchange. However, IoT network interoperability doesn’t enable the systems that are exchanging messages to interpret those messages. To realize the many-to-many system-of-systems vision, IoT applications need to implement standard ways of communicating sensor locations, sensor and data parameters, and sensor instruction sets. This is what the OGC SensorThings API provides.