All posts tagged: things

JSON, or JavaScript Object Notation, is a lightweight open standard format that uses human-readable text to transmit data objects in the form of pairs of attributes and values. It is used primarily to transmit data between a server and a web application as an alternative to formats and languages such as XML for lightweight, flexible formatting of data for Internet communication in a way that is both machine-readable and human-readable.

Let’s look briefly at how JSON can be used, how it compares to XML (Extensible Markup Language), and the role JSON can play as a lightweight format for information transport in Internet of Things and embedded applications. In an Internet-of-Things application, every “Thing” connected to the network should have an API that allows access to key data elements.

This data needs to be streamed at an appropriate rate over the Internet to a server directly, or to a gateway or other device in the local network. Near-real-time access to sensor data at the gateway or at the server allows contextual information derived from that data to be served up in a timely manner, so minimising network overheads is clearly valuable.

Although originally derived from the JavaScript scripting language, JSON is a language-independent data format and code for parsing and generating JSON data is readily available in a large range of programming languages, making it easy to get up and running with the language of your choice. JSON objects are human readable – they are basically freeform text documents. Whilst JSON objects contain rich information and are a highly flexible way to represent data, they are easy for programmers and database administrators to use.

XML is well established as a language of choice to describe structured data and to serialise objects, and various XML-based protocols exist to represent the same kind of data structures as JSON for the same kind of data interchange purposes. When data is encoded in XML, the result is typically larger than an equivalent encoding in JSON, mainly because of the presence of closing tags in XML.

While the API is a key consideration in implementing a RESTful solution for moving around and accessing your data, the format of the payload is also equally as important. XML is one traditionally popular language in these sorts of applications, but JSON is not as verbose as XML and does not contain detailed processing instructions. Being a more lightweight data interchange format, it is faster to use JSON to send bits of data, such as data from a sensor for example, around the Internet of Things.

JSON is promoted as a lower-overhead alternative to XML, providing similar data exchange capabilities with support for creation, reading and decoding of data in the real world with lower overhead. The increasing popularity of REST over SOAP in modern APIs also promotes greater use of and support for JSON as the preferred data exchange format, since you are no longer limited to only returning XML.

JSON-RPC is an RPC protocol built on JSON, as a replacement for XML-RPC or SOAP. It is a simple protocol that defines only a handful of data types and commands. JSON-RPC allows for notifications – information sent to the server that do not require a response – and for multiple calls to be sent to the server that may be answered out of order. This flexibility in choosing messaging options to get the data where it is needed with the priority that is needed in the most lightweight possible way is attractive in resource-constrained and bandwidth-constrained Internet-of-Things networks or embedded systems.

Modern web browsers incorporate native JSON encoding and decoding, increasing performance due to the fact that functions no longer need to be parsed as well as eliminating potential security vulnerabilities where JSON is evaluated as Javascript. Native JSON is generally faster compared to the JavaScript libraries used in the past to parse JSON, as well as more secure.

As an example of JSON in use for an existing embedded Internet-of-Things solution, the “Razberry” platform. This adds the hardware required for the Z-wave wireless home automation protocol to the Raspberry Pi single-board computer, turning an inexpensive device into a Z-wave home automation gateway and exposing control of your home automation network via a JSON interface.

Furthermore Google BigQuery added support for JSON a few years ago, explicitly mentioning the potentially useful role of JSON in connecting data collected from sensor networks and the Internet of Things to BigQuery, bringing the power of Google’s Big Data manipulation expertise together with the Internet of Things and sensor networks as the sources for that Big Data.

JSON is one of many tools available in the Internet-of-things toolbox, and can easily be used with many applications. And here at the LX Group our engineers have an excellent understanding of the standards required for effective communciation between devices within Internet-of-things platforms, and are ready to integrate it with your new and existing products.

To get started, join us for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

The new ZigBee Smart Energy 2.0 (SEP2.0) ZigBee Application Profile brings with it powerful new ZigBee capabilities for smart energy metering and control networks. With its ability to transport rate, demand, and load management messages to and from networks of smart energy appliances and the “Smart Grid” across a wide variety of wired and wireless media, the profile promises to be a key element of residential energy management systems.

Capable of passing energy-related messages across a HAN, or Home Area Network, using numerous different types of wired or wireless physical media, SEP2.0 is aimed at enabling the next generation of interactive smart appliances, HVAC, lighting and energy management systems – a “Smart Grid” of energy-efficient technology.

An IP-based HAN enabled by ZigBee Smart Energy 2.0 makes it possible to manage every aspect of the energy consumption and production of a home or building, whilst moving the information around a network built entirely around the Internet Protocol and interconnected with existing networks and the Internet.

The ZigBee Smart Energy 1.0/1.1 Profile was originally developed to allow 802.15.4/ZigBee low-power wireless mesh networks to support communication between smart meters and products that monitor, control and automate the delivery and consumption of electricity – and potentially other household utilities such as gas and water, moving into the future.

The functionality of the Smart Energy 1.x Profile was primarily intended to support the functional requirements of smart meters being used by electricity, gas and water utilities to manage their distribution networks, automate their billing processes, and communicate with customers’ energy management systems.

ZigBee-enabled smart meters act as communications gateways between the utility and the consumer, enabling the exchange of messages about pricing, demand response and peak load management. At least this technical capacity exists in theory, but electricity retailers will only bother with it if they have a revenue model in implementing such technology.

The ZigBee Smart Energy 2.0 Profile was created in response to the need for a single protocol to communicate with the growing universe of energy-aware devices and systems that are becoming common in homes and commercial buildings. For that reason, a diverse range of Function Sets were defined under SEP2.0, including Demand Response and Load Control, Metering, Billing, Pre-Payment, Directed Messaging, Public Messaging, Price Information, Distributed Energy Resource Management and Plug-in Electric Vehicle Management.

One or more of these Function Sets can be used to implement one of the Device Types defined in SEP2.0, such as Meters, Smart Appliances, Load Controllers, Smart Thermostats, In-Premises Displays, Inverters and Plug-in Electric Vehicles to name just a few.

ZigBee Smart Energy 1.x access the MAC/PHY layers of the 802.15.4 radio hardware via the ZigBee Pro protocol stack, but SEP2.0 replaces the ZigBee Pro protocol stack with the ZigBee IP stack, which uses the 6LoWPAN protocol to encapsulate the proprietary ZigBee packet structure within a compressed IPv6 packet. At the transport layer, IP packets bearing messages containing standard ZigBee command and data packets are exchanged using the familiar HTTP and TCP protocols.

When used in combination with the SEP2.0 Application Profile, the ZigBee IP stack provides a media-independent interface between the network and MAC layers of the stack that allows SEP2.0 packets to be carried across nearly any IP-based network.

A recent version of SEP2.0 includes support for communication across ZigBee and 802.11 wireless LANs as well as powerline communication (PLC) networks. SEP2.0 will also have improved future support for 802.15.4g, where the physical layer of the ZigBee/802.15.4 network is a sub-gigahertz radio at, say, 900 MHz for long-range outdoor telemetry or environments where the 2.4 GHz spectrum is congested. Support is also improving for other popular network technologies such as Ethernet.

Amongst the first SEP2.0 enabled products to hit the market will be Energy Service Portals (ESPs) which serve as a bridge between an energy utility’s communication infrastructure and the IP-based Home Area Network. These portals are provided to consumers by utility companies, and use the SEP2.0 Energy Services Interface profile to provide a bridge between the SEP1.x protocol used by most existing smart meters and the home’s IP-based network.

A ZigBee-enabled home energy management system can employ multiple Application Profiles to provide unified control of all home energy systems. For example, a smart home energy management system may use the Smart Energy (SE) profile to pass the utility’s load management and demand response messages to the home’s major loads and energy sources.

The Home Automation (HA) and RF for Consumer Electronics (RF4CE) profiles may then be used to communicate with Smart Appliances, lighting systems and other consumer-controlled products. Energy-aware homes will also employ a large number of end-point applications such as smart thermostats, in-home energy displays (IHDs), and tablet-based control panels that use SEP2.0-enabled ZigBee or Wi-Fi radio links to communicate with the home’s ESI and other elements of its energy management system.

SEP2.0-equipped network endpoints may also be implemented with the physical layer of the network using power line communications, networking smart appliances without RF spectrum congestion.

The ZigBee Alliance has created well-defined provisions for interoperability with, and upgrade paths from, the earlier SEP1.x standard to SEP2.0, which is good news for engineers looking to upgrade or to interoperate with existing SEP1.x technology. There is no significant increase in the processing power required in your hardware, although the key generation and exchange functions in the SEP2.0 security layer may be tough for 8-bit microcontrollers to handle unless they have security acceleration capability, handling the cryptographic maths in dedicated hardware.

Unfortunately, in terms of memory, SEP2.0 and the applications it supports require significant increases in both flash and RAM over what is required for most SEP1.x applications. Storing the code for a SEP1.x stack, a small application profile and a simple user application requires roughly 160 kb of flash in a typical microcontroller, plus 10-12 kb of RAM. Implementing comparable functionality under SEP2.0 requires about 256 kb of flash and 24-32 kb of RAM.

As an example of an existing hardware reference solution targeting SEP2.0, Texas Instruments provides an example consisting of the CC2533 802.15.4 RF system-on-chip, which runs the MAC/PHY layers of the SEP2.0 stack on its built-in 8051 core, combined with one of TI’s ARM7 Stellaris 9000-series microcontrollers as the application processor, running the remainder of the network stack and the application code.

Most of the microcontrollers in this powerful family include a fully-integrated Ethernet MAC, CAN interface, USB host controller, and enough memory and processing power to implement many simple SEP2.0 applications.

It is also worth considering some of the highly integrated single-chip solutions on the market such as the Texas Instruments CC2538, which integrates a 2.4 GHz 802.15.4 radio, ARM Cortex-M3 32-bit microcontroller core, hardware security acceleration for SEP2.0 and plenty of flash and RAM to support the ZigBee IP stack, SEP2.0 profile and application code with support for over-the-air firmware flashing capability for updates in the field, all in a single chip.

As you have just read, the new profile offers a great amount of promise in terms of functionality and convenience for the end user. Here at the LX Group our engineers have an excellent understanding of the Zigbee platform and have put this to use to create various systems for a wide range of customers – and we can do this for you too.

To get started, join us for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Let’s take a brief overview of the web applications and cloud platform available from Exosite – a provider of Internet-of-things cloud services that help you collect, store, visualise and interact with data from your networked devices in the cloud. Exosite provides a cloud platform that can be connected to your Internet-connected sensors and other devices.

Once your device is connected, data is flowing into the cloud and you can set up logical rules to process and act on that data, log timestamped historical data or use Exosite’s built-in scripting language to process and interact with that data. Time-series information can be used to visualise, command or control devices, either in real time or in response to trends over time.

Their platform makes it easy for product developers to create cloud-capable connected products with a range of microcontrollers and RF solutions from different hardware vendors. Exosite’s “One Platform” and “Portal” families of cloud Platform-as-a-Service and web applications provide value to developers and device OEMs, helping to minimise risk and time to market for developers of Internet-of-Things connected products. Exosite can help you to quickly prototype and deploy systems to meet your needs for cloud-based remote access to devices and their data.

Exosite’s data platform is a hosted-served system that removes barriers to market entry and empowers companies to quickly prototype and deploy their own Internet-of-Things solutions using Exosite’s web service APIs. The system is designed with product developers in mind, meaning that it has a built-in framework that eliminates the complexity of infrastructure and simplifies IoT development. Exosite’s “One Platform” makes it easy for product developers to create cloud-capable products.

Furthermore the Exosite developer site provides a wealth of convenient user guides, API documentation, application notes and support information, as well as example source code and reference projects covering a range of different programming languages and architectures. There are libraries for interaction with the Exosite API in a range of different programming languages, allowing you to work with the languages that best suit your needs.

Working and maintaining the software is simplified as Exosite supports over-the-air firmware and software updates from their cloud service, if supported in the particular hardware used. This allows for remote wireless management of your devices, allowing firmware updates, feature enhancements, and other maintenance rolled out without the need for physical on-site service of hardware devices offers great value and convenience, improving user experience and reducing support costs for networks of Internet-of-Things connected devices.

With Exosite you can build pre-configured settings in the cloud for your families of devices, enabling newly manufactured devices to know exactly what version of software to install – right from the cloud, without any local intervention – as soon as they come online on the Internet.

As well as automatic provisioning, Exosite’s built-in device management tools make it easy to manage software installations and updates. When it comes time to update your devices in the field, you can simply upload your new content, select the device model type you would like to update, and hit deploy. Your new firmware is then deployed automatically, from the cloud, to every one of your connected devices of that type out there in the world. If those devices are not always connected to the Internet, they will automatically update themselves with the new software the next time they connect to the Internet.

Gathering data from an Exosite system isn’t difficult at all, and it allows you to aggregate and monitor data from your network of devices in the cloud in real time – as well as run powerful scripts to combine multiple lower-level inputs and build custom dashboards to report on defined metrics in an easily interpretable, visible way.

Exosite is easy to integrate with other systems, allowing you to easily push data out of its cloud platform into existing, external services. Since Exosite is based around cloud infrastructure, you can scale your application without having to worry about infrastructure or server administration.

You can build your own web app, or customise Exosite’s own app. You can get started with an Exosite developer account for free and use their simple but powerful set of APIs to start interacting with your devices in real time over the Internet. When you’re ready to scale up with your commercial solution, you can easily move up to a paid account, giving you an OEM-ready “white label” platform with the features and capabilities needed to build a business around your connected Internet-of-Things application.

For a better end-user experience designers can easily customise the website theme, control the user experience, configure device options and set up pricing plans for your customers, but you can grow at your own pace without worrying about the scalability of the underlying server infrastructure.

Exosite supports a range of open source and proprietary hardware development kits and platforms, reducing the time required to develop and build Internet-of-Things connected hardware solutions. For example, Exosite provides libraries for use with Ethernet-enabled Arduino and Arduino-compatible development boards, as well as support for development kits and development boards with network and Internet connectivity from hardware vendors such as Microchip and Texas Instruments.

Combining these hardware development tools with Exosite’s cloud platform allows you to get online with cloud-connected hardware quickly, getting your sensor data online and getting physical devices interacting with the cloud. Exosite makes it easy to connect, manage, and share your sensor or device data online.

Testing or getting started with Exosite is simple, as the free developer account has everything you need to start interacting with your devices in real time over the Internet. You get a web dashboard account, full access to the API, a cloud scripting environment, and the ability to upgrade features a-la-carte.

This account is aimed at allowing you to build your own Internet-of-Things environment on a one-off basis. If you find value in it and want to deploy it as a business solution for a wider audience then you can easily upgrade to a paid “white label” account in order to do so. Finally the developer account includes two devices and one user, while a paid account gives you support for many more devices, many more users, SMS messaging capability from the cloud and more.

It’s no secret that the Internet-of-things not only holds a lot of promise for connected devices and the possible products you can profit with – however getting started can seem like a maze with literally scores of options, platforms and hardware types.

To make your start in the IoT as smooth and cost-effective as possible, partner with the LX Group. We have experience in all stages of IoT product development – along with every other stage of design to manufacturing. To get started, join us for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.
Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Let’s consider some of the security concerns presented by today’s connected embedded devices and “Internet of Things” networks. Where does security potentially fall down with these kinds of systems, and what can be done to keep systems secure?

Internet-of-things networks and Internet-enabled hardware appliances bring with them all the established security concerns associated with computer networks and electronic technology – for example, if users are not forced to set strong passwords, or educated in choosing good passwords, then poor passwords can be chosen. RFID access tokens can be lost by authorised personnel, as can mechanical keys.

Where security depends on a computer or electronic hardware system, an attacker with physical access to the hardware can do just about anything without restriction. Transport layer security should be used to help increase (but not make foolproof) the security of TCP/IP communications over the Internet. Wi-Fi access points shouldn’t be transmitting at excessive power levels, allowing easy abuse by people outside the intended working range of the Wi-Fi network.

All these traditional concerns about network security and physical security are maintained in an Internet-of-Things environment, but new threats and challenges are potentially emerging with the growth in connected, embedded technology. What if attackers can potentially unlock the door to your house, or maybe even set fire to your house, by exploiting vulnerabilities in a web server and manipulating Internet-connected physical devices?

Devices such as the Lockitron, a crowd-funded gadget that fits over a standard deadbolt and allows you to lock or unlock your home from a smartphone app, may be convenient to use, but is the risk of connecting Internet-based attacks and vulnerabilities with the physical environment around your home or workplace worth this convenience? Even if a server responsible for providing Internet services for Internet-of-Things deadbolts is relatively secure and hard to attack, what if breaking into a single server means you can then burgle 100, or 1000 or 10,000 homes with their doors unlocked on demand?

Furthermore, with relatively good (but never invulnerable) server-side security, this sort of attack may still be considered worthwhile by organised attackers. Where the stakes are potentially high, strong end-to-end security from the physical hardware right through to communications, Internet services, servers and mobile apps is important.

As we have an increasing level of connectivity reaching into devices that interact with the physical world the consequences of security failures escalate, as do privacy concerns. Possible remote security attacks on a car’s engine systems – because the designers decided that the car’s entertainment system should be connected to Bluetooth and Wi-Fi to allow easy upload of music and media, but that the entertainment system should also be connected to the engine management unit for some bizarre reason – could potentially be life threatening, for example.

Similarly, attacks on life-critical implanted medical devices such as insulin pumps or pacemakers are an area where serious attention is justified, given the potential for an electronic attack to mean mortal harm.

There are also privacy concerns in an environment where Internet-of-Things sensors, wireless sensor networks and machine-to-machine sensor data collection become more ubiquitous in the home. The large amount of data being collected from smart lighting, home automation appliances, smart energy management and control appliances and other sensor networks around your home could reveal a lot of information – what time you’re home, what time you’re not home, what time you sleep, how often you exercise or how often you cook, for example.

What if the information from smart energy metering appliances could be compromised by a potential burglar, who would then know what time your home is not occupied? What if data could be mined about your personal exercise or cooking habits from the fusion of information from smart appliances in your home?

Could that information be used for commercial benefit, for example by advertising or marketing agencies or health insurance providers? If your refrigerator keeps track of every food item you buy, there is obviously going to be interest – ethical or not – from market research companies, or health insurance companies, in looking to get access to this sort of information from the network.

We generally understand that information that people have generated is personal information – your information is your information, you own it and you control it, and there are expectations of privacy. But that understanding is not so clear when the information is generated by the machines around you, autonomously, without human control.

Is the information generated by your refrigerator, your lighting, your home automation appliances, exercise appliances or your car really “your” personal information which you expect privacy around? Do you “own” and control the privacy and security of that information? And is that a question that the general public is thinking about?

If all our collected data, data which may be considered personal or sensitive, is stored in the “cloud” because the cloud provides scalability, then our information is only as secure as the cloud service we use and we have no direct control over the security. So can we trust any given cloud service provider? How secure is it, really? And does a particular proprietary hardware product give us any choice in the servers or Internet services it uses?

If we unlock and lock our house with a gadget that only connects to its manufacturer’s web service on a server in a foreign country, for example, does that mean that the government of that country can legally compel that provider to provide that data on every time you arrive or leave home, no matter where in the world you live?

As you can see, integrating security into any Internet-of-things product should be a prime concern – from both a physical and software perspective. Furthermore educating the end-user through appropirate documentation is also paramount. Overall the consequences of poor security should not scare you, as these challenges can be met with the appropriate level of design.

Here at the LX Group we can help you in all stages of IoT product development, ensuring a level of security to meet your needs is included – along with every other stage of design to manufacturing. To get started, join us for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Should your next product or design be an Internet-of-Things product? That is, should every embedded design always feature Internet connectivity, or machine-to-machine communications, where the possibility exists? There are lots of different perspectives on this question, several advantages and disadvantages and pros and cons that need to be weighed up.

Although Internet-of-Things connectivity is very popular and hyped at the moment, it isn’t always going to be a worthwhile fit that provides valuable advantages for all devices in all situations.

Internet connectivity provides advantages – data collection and logging with the data stored in the cloud, accessible via the Internet from any device anywhere in the world, or the possibility of convenient remote access and control of devices via the Internet, for example, but this type of Internet connectivity brings with it concerns over security, safety and privacy.

There is a very slight potential that devices connected to the Internet can be accessed by unauthorised persons, if and only if exploitable security vulnerabilities exist. This is a serious concern for Internet services that control real, physical hardware that is potentially dangerous if misused, or for hardware that controls security-critical systems such as building access-control systems for example.

Control of security-critical real-world hardware, and the secure and confidential management of personal information (data collected from health and medical data-logging instruments such as RF heart rate sensors, for example, or information from a home automation system that indicates the typical hours that people are at home and are not at home) needs to be taken into account when deciding to have embedded automation systems exposed to the Internet.

Product designers need to consider whether the benefits of Internet connectivity are worth the risks. Consumers expect that such data will be collected and handled with some degree of privacy and security, and the convenience of Internet-based data collation and access to data will only be accepted by the market if it doesn’t also come with unacceptable privacy concerns.

If your design incorporates Internet connectivity, does this connectivity contribute to a positive, easy user experience or does it potentially make the user experience more difficult? If your product or design requires the consumer to have an existing Wi-Fi or Ethernet network to provide Internet connectivity, for example, is this inconvenient for some consumers?

Even though most consumers already have Wi-Fi networks, is the product still worthwhile for consumers that don’t? What about if the Internet connection to the LAN, or a mobile or cellular Internet connection if that’s what you’re using, fails? Can your design still function usefully in an environment without Internet connectivity, or is it completely useless?

Can the device work in a transparent, convenient way for the end user in an environment where the Internet connectivity is unreliable and may be off-line sometimes? For example, can data be temporarily buffered in local memory while the device is off-line, and then transmitted to the Internet service later, reconnecting transparently without user intervention?

Adding Internet-of-Things connectivity to a design can introduce hardware complexity, and extra cost for your device. It can mean other increased costs such as server and hosting costs, the costs of wireless LAN or other network infrastructure, the cost of cellular network access if cellular modems are used, and potentially the significant costs associated with RF regulatory compliance, testing and approval for consumer products which are intentional RF radiators. Such regulatory requirements may be simplified or eliminated if the RF connectivity component of your design is eliminated.

Are these costs worth it for the benefits? Or are you simply over-engineering, and adding “Internet of Things” connectivity because it’s in vogue and it’s a trendy buzzword? Do these features provide value for money in the context of your particular product, or are they simply features for features’ sake?

Overcomplicated, over-engineered systems that try and pack too many features into a single design can potentially suffer from disadvantages such as increased hardware cost and size, decreased market uptake due to relatively high cost, relatively high power consumption, more difficult and complicated user interfaces, and greater challenges in trying to assure the reliability, security, low maintenance and support costs of your design.

Furthermore a larger, more complicated system inevitably has more points of potential hardware (or software) failure, more work to be done in debugging and quality assurance, and more potential points of security vulnerability.

All this may sound like the Internet-of-things is a negative point of difference for existing and potential products – however this couldn’t be further from the truth. You already know that connected devices are the way of the future. The key to success in manufacturing, information security and customer satisfaction lies in the right design and working with a team who understand the IoT and how it can be put to work for your benefit.

Here at the LX Group we have experience embedded hardware design for the IoT, including security, regulatory standards and compliance testing, working within standards and design for manufacture. To get started, join us for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

When your organisation understands that creating new IoT devices is necessary, but you’re not entirely sure about the future of the technology with regards to which platform to settle on – it can be difficult to make an informed decision. The “paradox of choice” can often stall progress, until now. With the Waspmote platform from Libelium, you can use an incredibly wide range of wireless technology and platforms to meet your IoT goals.

Libelium’s Waspmote platform is an open source wireless sensor network platform specifically focussed on the implementation of low-power modes, allowing individual battery-powered nodes (or “motes”) to be completely autonomous and to run for many months or years without maintenance.

Depending on the duty cycle, types of sensors and the radio used, it is possible for a Waspmote node to run for as long as five years on a single battery. The advanced Waspmote “mote” for wireless sensor networks is at the centre of Libelium’s complete ecosystem for Internet-connected wireless sensor networks and Internet-of-Things applications.

Waspmote allows for highly flexible implementation of wireless sensor networks – the connection of almost any type of sensor you can think of to any cloud platform, using many different common wireless networking technologies. Using the waspmote platform is a great way to implement Internet-connected sensor networks for Internet-of-Things and wireless sensor network applications, with a huge range of supported sensor types as well as a range of different options for network and Internet connectivity.

There are many different options for wireless connectivity in a Waspmote system, including 3G, GPRS, 802.15.4/6LoWPAN, 802.11 WiFi and Bluetooth. A combination of multiple different radio interfaces can be chosen if desired. Both 2.4 GHz and 800 MHz ISM 802.15.4/6LoWPAN radio hardware is available for use with Waspmote. With the right choice of radio hardware, radio link distances of up to 12 kilometres are possible.

Waspmote’s hardware architecture has been specifically designed to enable extremely low power consumption. Power to any of the sensor interfaces can be turned on and off under software control, as well as power to the radio transceivers.

Three different sleep modes make Waspmote one of the most power efficient wireless sensor network platforms on the market, with a current consumption claimed as just 70 nanoamps in hibernate mode. There are more than 60 different sensors available to connect to Waspmote – soil moisture, GPS, temperature, humidity, vehicle detection, light, PIR and radiation sensors to name just a few.

The platform also supports over-the-air programming (OTAP), allowing firmware development and update across a network of wireless sensor nodes without the need for physical access to the hardware. It is possible to choose unicast, multicast or broadcast delivery of new firmware updates across the wireless network, controlling which nodes receive the update.

The huge range of different Waspmote sensors available enables a huge spectrum of different application possibilities in industrial monitoring and automation, smart cities, environmental sensing, agriculture and home automation. In a typical network of Waspmote sensors, a number of end nodes are equipped with 802.15.4/6LoWPAN hardware, appropriate sensors for the desired application, and power supplied from a battery or other sources such as solar power.

These nodes send their sensor data over the 802.15.4 mesh network back to the gateway node, which is equipped with an Ethernet interface as well as an 802.15.4 radio. The (IPv4) Ethernet gateway changes the 6LoWPAN IP header to IPv4 while keeping the UDP transport layer, and it sends the data to the IPv4/IPv6 tunnelling machine which changes the header to the proper IPv6 format and sends the information (now using IPv6) to servers on the Internet, and from there to services, and ultimately users, who use the collated sensor data.

The Meshlium gateway reads the sensor frames coming in from the nodes and stores them locally, sending them out to external cloud services on the Internet. The frames coming in from Waspmote nodes are received over the 802.15.4 mesh network and sent out to the Internet via the Ethernet, WiFi or 3G interfaces, if present.

Data is sent from the Internet-connected gateway out to a cloud server on the Internet via HTTPS and/or SSH for security, and the Waspmote ecosystem is compatible with any cloud platform you like.

Notably, there is no lock-in or closed compatibility with any one particular web service, unlike with some alternative products on the market targeted at Internet-connected embedded applications. You can choose your servers, and choose your cloud software platform.

As well as being based around open hardware, the Waspmote IDE is distributed under an open source license. The Waspmote platform provides professional-grade wireless sensor network infrastructure combined with a strong commitment by Libelium to the philosophy of open-source technology.

Waspmote supports encryption libraries, ensuring the authenticity, security and integrity of the information collected from the wireless sensor network. Different encryption algorithms such as AES-256 and RSA-1024 are implemented.

As well as offering cryptology and security, strong mesh-network scalability, support for 802.15.4/6LoWPAN, support for an open, flexible choice of web services and cloud server infrastructure, the Waspmote platform offers easy and fast deployment, over-the-air programming for easy firmware maintenance and an intuitive graphical programming interface.

The highly power-efficient Waspmote hardware platform also lends itself to flexible power solutions, such as battery power, remote power from solar PV, or potentially other types of energy-harvesting power supplies – as well as use in almost any contemporary application.

Waspmote offers an open, approachable and easy-to-implement platform, which we can integrate with your needs to form a solution in a short time frame and your required budget. Getting started is easy, join us for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

When considering methods of adding Internet-of-things connectivity to existing or new ideas, being able to integrate open-source hardware can help reduce hardware target costs, however support and development advice can be lacking due to the distributed nature of open hardware development.

However with the openPicus ecosystem, we have found an inexpensive hardware choice that is also fully supported by the manufacturer and also allows for integration into final, closed products. The openPicus ecosystem provides user-friendly Internet connectivity for the relatively easy development of Internet-of-Things applications.

openPicus is based around the openPicus Flyport family of low-power, network-connected microcontroller modules, which are available in three different versions, with either Wi-Fi, GPRS or Ethernet connectivity but with the same microcontroller and an otherwise equivalent module pinout.

Each Flyport module is pinout-compatible, allowing the same underlying hardware design to be assembled with different Flyport modules to meet changing connectivity needs that your customer may have. All Flyport modules are based around the same Microchip PIC24FJ256 16-bit PIC microcontroller, making firmware development easily portable across the different modules.

openPicus provides an IDE, comprehensive documentation, tutorials and a consumer discussion forum for its products, aimed at enabling developers of cloud services and mobile apps to use the system to prototype and develop Internet-connected hardware solutions relatively easily with minimal electronic engineering expertise.

Flyport is an open platform, providing an embedded webserver (for the Wi-Fi and Ethernet-connected modules), support for both infrastructure and ad-hoc Wi-Fi network modes (for the Wi-Fi version of the module) and sleep and hibernate modes for efficient power use when operating from batteries.

Each of the Flyport modules provide up to 18 digital I/O pins for interfacing to external hardware, four 10-bit ADC input pins, 4 UARTs, SPI and I2C interfaces. The Ethernet and Wi-Fi versions of the Flyport modules include two megabytes of external flash memory on board, and all versions include an internal real-time clock in the microcontroller.

The Flyport modules are all powered by the openPicus framework, which is itself based on the FreeRTOS real-time operating system. An IDE is provided, free, to make it easy to develop your own applications running on top of Flyport technology. Flyport modules are programmed using a C or C++ like programming language, with Flyport making development easy by managing all the required network interfacing, Internet communications protocols and the webserver internally for you.

The API allows management and programming of all the available functionality of the entire family of Flyport hardware modules, allowing the developer to import web pages, create applications, compile and download code to Flyport modules. Unfortunately, the IDE is only available for Windows at this time, although it can be run inside a virtual machine (with Windows installed) on OSX or Linux PCs.

Most of the underlying technology of the openPicus / Flyport system is released as open source software and open hardware, but with licensing choices such that you are not forced to release all your own code under an open-source license if you choose not to when integrating openPicus technology into your own commercial designs.

The openPicus Flyport IDE has its source code released under the GPLv3 license, and the schematics for the Flyport hardware are released under the CC-BY 3.0 Creative Commons license. Using the openPicus core, libraries and code samples in the firmware of your commercial product does not require you to release the source code of your firmware, provided that the core and libraries are used without modification.

If you tweak or modify the openPicus core or libraries then you are required to release the modified code under the LGPL v3.0 license.openPicus provides their code samples, applications, example projects and libraries for open use under the Apache 2.0 license, and the openPicus Framework (including the TCP/IP stack, email and FTP support) under an LGPL v3.0 license.

A number of pre-designed carrier boards for Flyport modules are available, allowing development with easy-to-use hardware “building blocks” with little or no expertise in custom electronic hardware design and construction required.

For example, the Music Nest is a carrier board for Flyport modules which can be used to develop Internet-connected audio applications. A VLSI1053 stereo audio codec IC is onboard, interfaced back to the Flyport module over SPI, along with an SD card for the storage of audio files.

Another example is the “Grove Nest” carrier board is a simple carrier board for Flyport modules that provides 10 ports for sensors and other peripheral modules which are compatible with Seeed Studio’s “Grove” connector standard. openPicus provides example libraries for a large range of sensor and actuator devices from Seeed’s “Grove” family of development modules, allowing the development of Internet-connected, Internet-of-Things devices in an easy “plug and play” fashion with minimal hardware expertise.

As is typical of Arduino and most similar development boards, these Flyport carrier boards can be powered either via an external power supply or via the same USB connector which is used to download firmware to the Flyport module. The Ethernet Flyport module is a programmable system-on-module based around the 16-bit PIC microcontroller common to all Flyport hardware, combined with a fully integrated 10/100 ethernet interface with integrated MAC and physical layer and a unique MAC address pre-configured for each module.

By default the Ethernet Flyport module includes an RJ-45 ethernet jack, but you can also route the Ethernet signals off the module to an RJ-45 jack on the carrier board, providing flexibility in terms of where the bulky RJ-45 connector is located on your board. Using the Flyport Ethernet module provides the embedded system with a powerful “Internet engine” with a small footprint, low power consumption and low cost, allowing real-time control and display of data on a dynamic webpage accessible from a standard web browser, from a PC, tablet or smartphone.

Thanks to the embedded webserver built into Wi-Fi and Ethernet Flyport modules – they can host HTML pages directly, allowing easy access to information such as sensor readings (or a user interface for control of hardware devices) using an internal webpage. Display of dynamic webpage content in the form of Javascript and Ajax is also supported.

Finally the TCP/IP stack and the application layer run on the main microcontroller of the Ethernet and Wi-Fi Flyport modules, meaning that you have full control of the connectivity and the application.

This means you can, for example, process data coming in from sensor hardware and display this data on a webpage served up from the Flyport module, or send the data to a remote location via email or FTP. You can also shut down the Wi-Fi or Ethernet connectivity to reduce power consumption when connectivity is not actively required.

The openPicus system provides a well-documented and easy method of integrating IoT connectivity into existing and new products, and thus helps decrease the time to market for your new and existing products.

With our experience in embedded hardware, IoT-connectivity and complete product design – we can partner with you for every stage of product development to meet your needs. As we say – “LX can take you from the whiteboard to the white box”. So for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Choosing an Internet-of-things platform can be a challenge, not only due to the ever-increasing range of options in the marketplace – but also the ease of working with the platform to meet your end goal. With this challenge in mind we introduce the Realtime.io/Iota system from iobridge – a system suited to real time monitoring and control.

Realtime.io is a technology platform that enables easy development of near real-time Internet-of-Things applications for developers and manufacturers. The Realtime.io platform is a complete, end-to-end solution of hardware, firmware and a cloud platform for the Internet of Things which allows developers to integrate Internet connectivity into their product designs relatively easily with minimal effort required for either hardware or software development.

Realtime.io Cloud Server and Iota technology are aimed at making it easy and cost effective for manufacturers to Internet-enable their products, either in new or existing designs. The Realtime.io cloud server technology acts as a bridge between embedded devices or products running Realtime.io Iota software and user software running either in-browser or in the form of smartphone applications – which allows your devices or products to be monitored and controlled conveniently over the Internet.

Despite being easy to use with minimal development effort, Realtime.io also provides some flexibility in how it is integrated for more advanced developers with existing hardware platforms.

You have the flexibility of choosing your own hardware and developing your own user interfaces or letting ioBridge do it for you. The Realtime.io connected Iota hardware modules from ioBridge provide 12 GPIO pins, eight of which are usable as either digital I/O or as ADC inputs. These embedded Iota modules are available with either Wi-Fi or Ethernet hardware for connectivity between the device and your LAN (and hence the Internet).

Although you can use the Iota hardware modules for relatively easy hardware development of a new product, or relatively easy integration into an existing microcontroller-based design (for example with a simple UART connection between the Iota module and the existing microcontroller).

Commercial users who already have their own custom Wi-Fi or Ethernet-enabled hardware have flexible options in how they integrate with the Realtime.io cloud platform, giving Realtime.io an advantage over some competing platforms such as Electric Imp where their hardware card must always be used.

Rather than using an Iota hardware module with its integrated firmware, you have the option of licensing the Iota firmware library for integration into your existing embedded hardware design, if your design includes an appropriate microcontroller along with Ethernet or Wi-Fi connectivity.

In either case, for commercial licensing, Realtime.io collects a royalty fee either per Iota hardware module provided or per unit of customer hardware shipped integrating Iota firmware. Easy to use breakout boards and development kits are available for hardware development and experimentation using either the Ethernet-connected or Wi-Fi connected Iota hardware modules.

No port-forwarding, dynamic DNS or complicated firewall reconfiguration is required for an Iota-connected hardware system to talk to the Realtime.io cloud service via the Internet, and initial setup of Wi-Fi credentials is easy, making installation and initial deployment of Realtime.io-connected hardware relatively easy for any user.

The combined infrastructure of Realtime.io and Iota was created to provide a near-instant communications link between devices and applications, providing near-real-time two-way operation for both monitoring and control with a software latency of typically less than 10 milliseconds.

Typical end-to-end delays are only about 100 milliseconds, most of which is the unavoidable ping time across the Internet to the Realtime.io server. This is very desirable, since high latency can significantly detract from user experience with Internet-of-Things connected hardware solutions in applications such as home automation.

Everything is API driven, and easy to use for both hardware developers and web developers. By providing API abstraction, Realtime.io enables developers to prototype their connected project ideas easily and then transition to production hardware and software designs very quickly, without requiring expertise in both electronic and software engineering.

ioBridge provides a web API that can be used by Realtime.io customers to develop their own custom applications or to integrate with their own or other third-party systems.

Realtime.io allows you to create web applications based on HTML5, CSS and Javascript with interaction with physical devices, social networks, external APIs, and ioBridge web services. The Realtime.io App Builder allows you to build web apps directly on the Realtime.io platform, with an in-browser code editor, JavaScript library, app update tracking, device manager, and single sign on with existing ioBridge user accounts.

The web client API allows you to interact with Iota-enabled devices connected to Realtime.io cloud servers. This API provides access to HTTP streaming from one device or multiple devices, access to GPIO registers on your devices (and therefore hardware interaction and control), and administrative information such as access to the connection state and IP addresses of the network of connected devices.

The Realtime.io system holds much promise, and through a four year development period the system can deliver on the promises of reliable, secure and scalable integration with new and existing products.

If your organisation is considering bring new IoT-enabled products to market, looking to update existing disparate nodes to a contemporary networked environment – or you have some great ideas and not sure how to start, we can help you at any and all stages of the required processes.

We’re ready to offer our experience and know-how on this and every other stage of product development to meet your needs. As we say – “LX can take you from the whiteboard to the white box”. So for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Freescale Semiconductor and Oracle announced earlier this year that they are working together to develop the “OneBox”, a gateway platform for secured service delivery for Internet-of-Things applications based on open Java technology and Freescale silicon.

So what is OneBox all about? The aim of OneBox is standardising and consolidating the delivery and management of Internet-of-Things services through one gateway box rather than multiple gateway boxes from different vendors.

The idea is that the gateway appliance and its Java-based software stack can “speak” all of the different protocols being used to connect devices to the network in a context of, say, a home automation application – a single gateway that is interoperable with every networked Internet-of-Things device in the home.

For example, the OneBox gateway will have the ability to connect to multiple different kinds of RF networks such as 802.15.4, 802.11, Bluetooth and Bluetooth Low Energy, providing conversion and interoperability between different connectivity standards.

The “smart home” OneBox reference implementation from Freescale runs Java SE Embedded and is powered by a Freescale i.MX 6 series applications processor built on the ARM Cortex-A9 core. OneBox has enough local processing power to handle some real-time data processing, and can then send the processed data up to the cloud if desired.

There, Oracle’s infrastructure will be happy to crunch those bytes for you although you could use whatever cloud infrastructure you’d like – there is no lock-in. This local processing power is advantageous because it improves responsive interaction by removing the latency of a trip out to the remote server – for example, when you push the button to turn your lights on you want an effectively immediate response, not a delay of many seconds before the lights actually turn on.

The entire secured service delivery infrastructure – from the core of the network through the gateway to the small edge nodes – uses Java technology, pitched by Oracle as a unifying, open platform for the Internet of Things.

The Freescale/Oracle development team used Java SE embedded on the gateway box and Java ME embedded for the microcontrollers in their OneBox reference implementation. With its broad adoption, open source model, huge ecosystem and well-defined roadmap, Java technology is being pitched by Oracle and Freescale as ideally suited for Internet-of-Things requirements.

Due to the Java base, the system will be open throughout, without requiring hoops for programmers or device developers to jump through. OneBox offers a secure, standard and open infrastructure model for the delivery of Internet-of-Things services, combining end-to-end software with a converged gateway design to aim to establish a common, open framework for secured Internet-of-Things service delivery and management from the core of the network right through to low-power wireless sensors and other nodes at the edge of the network.

As part of the collaboration, Freescale will join the Java Community Process and work with Oracle and other JCP members to drive development of technical specifications for Java, particularly focusing on Java on resource-constrained platforms such as the low-cost microcontrollers that provide the embedded intelligence in Internet-of-Things enabled products.

Freescale will also work with Oracle and other JCP members on new and enhanced Java APIs to improve the support for Internet-of-Things protocols and features available on their microcontroller hardware.

The addition of a service layer based on enterprise-grade Java as an open standard, along with full security, on top of the whole system including the smallest resource-constrained microcontrollers takes the OneBox platform beyond a typical converged gateway.

Oracle and Freescale see it as a blueprint for an ideal secured service delivery infrastructure for the Internet of Things, one that will solve some of the common problems perceived as limiting the advancement of the Internet of Things.

OneBox is designed, both in terms of hardware and software, to be very modular, so the appropriate connectivity – ethernet, WiFi, 802.15.4/6LoWPAN, ANT, Bluetooth, whatever – can be “plugged in” and the corresponding software blocks needed for a particular service automatically loaded. This modularity supports future standards and a variety of use cases – from home automation and consumer electronics to industrial automation.

Freescale believes that it’s the small players that will bring the majority of innovation to the table, and they have specifically ensured that the OneBox platform is open and based on readily available software and hardware in order to promote participation by smaller players and decrease barriers to entry.

Freescale’s edge node sensors and devices based on Kinetis ARM microcontrollers are cheaply available, with all of the tools needed. Freescale silicon is distributed openly through small-volume distributors, datasheets and documentation for their processors are openly available to all, and Java is openly available to download and license.

After this quick summary it appears that this new idea between Freescale and Oracle could provide the backbone for a new, open-source and easily-adapable Internet-of-things platform for almost any situation. As the technology proceeds to mature we’d be more than happy to examine the possibilies available with your organisation for your benefit.

And we’re ready to offer our experience and know-how on this and every other stage of product development to meet your needs. As we say – “LX can take you from the whiteboard to the white box”. So for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Moving forward from our introduction to the Electric Imp platform, we’ll now consider how it can be integrated into existing or new designs for your commercial products. Using the Electric Imp platform can potentially simplify development complexity and the time-to-market – and doing so is a lot simpler than you can imagine.

Electric Imp integration with your design requires connecting Electric Imp’s backend with the Internet services that you want to use, such as email or Twitter notifications, existing Internet-of-Things data visualisation services like Xively, or your custom application-specific Web services or mobile apps. It also requires interfacing the 802.11b/g/n-connected Electric Imp hardware card with your hardware design.

For relatively easy integration of Internet connectivity into your existing microcontroller-based hardware design, the Electric Imp card can be used simply as a peripheral Wi-Fi gateway that is connected via serial UART to your microcontroller.

Your hardware design simply needs a host microcontroller with a spare 3.3V UART available and a 3.3V power rail with at least 400mA of available current capacity to power the card. A standard SD card socket is used for the Electric Imp, with pin 6 connected to the data line on the ATSHA204 IC which is required by Electric Imp as a unique identifier of each Electric Imp-enabled hardware device.

Note that pin 6 on the card socket must not be connected to ground as with the standard SD card pin-out, and this data line to the cryptography IC must be pulled to +3.3V with a 100k resistor.

A sufficiently large decoupling capacitor (preferably 2.2μF) must also be placed close to the card socket’s Vdd pin. With this simple hardware configuration an existing microcontroller design can be made “Imp-ready” for Internet connectivity (excluding the cost of the Electric Imp itself) at a very low cost – an additional cost of only about one dollar for the SD card socket and ATSHA204 IC in large volume.

Your existing microcontroller can exchange basic messages to and from the Electric Imp card over its serial UART, which can then send them on to the cloud. The Electric Imp IDE allows you to write server-side “agents” which make communication with the Electric Imp hardware easy. “Agent” code runs on Electric Imp’s servers and allows you to execute relatively heavy tasks such as HTTP requests, while “device” code runs on the local Electric Imp silicon.

Electric Imp easily passes messages between the agent and the device, so, for example, you can easily write agent code to allow Electric Imp to communicate with Web services targeted at the Internet of things, such as Xively, and that agent then communicates with the device.

This means, indirectly, that you have a chain of connectivity that is very easy to work with that connects your existing microcontroller to these Internet services. You can push your code down to an Internet-connected Electric Imp remotely, anywhere in the world, from Electric Imp’s web based IDE.

Manufacturers are able to push firmware updates from the cloud out to customer hardware in the field automatically – for example for bug fixes, upgrades or modifications to the APIs they use to talk to their web services.

For new designs built from scratch around Electric Imp, it may make more sense to use the power of the Electric Imp’s built-in microcontroller, and interface your sensors and actuators to the Electric Imp directly. This is likely to result in a reduction in the overall cost and complexity of your hardware system.

Thanks to Electric Imp’s cloud-based approach, your system has benefits like the ability to push firmware updates to customer’s hardware in the field, anywhere in the world, with just a few clicks. Electric Imp development doesn’t require downloading and installing an SDK, or connecting a JTAG probe to your target hardware.

You simply develop your code in Electric Imp’s browser-based IDE and it is pushed down to the Electric Imp over the Internet from Electric Imp’s servers.

For commercial use, where you’re integrating the Electric Imp into a product that you’re marketing commercially and connecting the backend to your own service via a HTTP API, you need to pay service fees to Electric Imp.

As a vendor of a commercial Electric Imp connected product, you can pre-pay for Electric Imp service for many years, or opt to be billed annually for each of your active Electric Imp devices in the field that are enabled and used by customers. This is their model for applications where your product designers are using Electric Imp technology for Internet communications – and with your own app in the Apple iTunes and/or Google Play stores, without Electric Imp branding.

The alternative is that the product designer just incorporates a card socket and ATSHA204 “CryptoAuthentication” IC into their product, which makes the product “Electric Imp Ready”. The user can then plug in their own Electric Imp card and pay a fee to use Electric Imp’s own branded service, allowing many different kinds of devices to be connected to services such as Twitter, SMS and email notifications.

Due to the ATSHA204′s unique serial number, each hardware device can be uniquely detected and thus tell the Electric Imp servers what kind of Imp-enabled device it is when the Imp is plugged into it, and the Imp can then download the appropriate firmware from the cloud for that application. This offers a very simple method of setup and firmware maintenance that can be remotely-controlled and out of the hands of the end-user.

No matter your level of technical proficiency, the Electric Imp platform offers a level of Internet-of-Things integration to match your product or design requirements. Furthermore, your new product’s time-to-market or the time to integrate Electric Imp into existing products is much smaller than existing embedded Wi-Fi solutions.

Here at the LX Group we’ve already completed a variety of products that embed the Electric Imp platform, and are ready to offer our experience and know-how on this and every other stage of product development to meet your needs. As we say – “LX can take you from the whiteboard to the white box”. So for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.