IoT technologies have become a natural part of our life. And therefore the number of IoT protocols has grown exponentially. Device manufacturers (e.g. wearables, sensors, or temperature / light / environment controllers) use their own protocols for communication and cloud enablement. The cloud infrastructure can also use custom protocols of a higher level to receive device state updates and management information.
Some platforms use low-level protocols (e.g. COAP) to interact with devices and MQTT to communicate with a central hub. Others use their own standards, built upon HTTP or WebSockets. Central hubs in turn can use a variety of protocols and methods for marshalling data. And imagine the mashup of all those protocols to connect to external services.
The DeviceHive project development team has explored the possibility of integrating the DeviceHive data platform with SAP Hana DB. DeviceHive allows third party IoT device developers to concentrate on business tasks and the distinctive features of a project by shifting the data and device management to the platform. SAP Hana DB provides analytical tools integrated with data storage.
This approach can be used as a reference architecture solution based on devices that use Ubuntu Core. In our example, the devices collect data from the sensors and transmit it to the cloud for further analysis.
The DeviceHive platform allows us to collect data sent by devices in various ways. One of the most convenient ways that is available immediately after server installation is to use the data stream in an Apache Kafka server. The data flow available from Kafka topics contains device notifications. Aggregation and data analysis received from the sensors on the fly makes it possible to create a real-time monitoring system.
The DeviceHive team has released a new version of their gateway for Android N. DeviceHive Android Gateway for Bluetooth Low Energy devices makes it possible to connect multiple Bluetooth Low Energy devices to DeviceHive IoT clouds through a single Android device. Now it’s possible to connect sensors, buttons, indicators, wearables, and any other BLE devices to prototype solutions even faster.
All that’s needed is to start the gateway, connect it to the device, and send a command (or subscribe to sensor data notifications).
Here is a presentation showing common use cases for the DeviceHive Gateway on Android.
This quick tutorial will help to start prototyping the solutions faster.
A panel hosted by DataArt
A recent Patient Engagement Innovation panel discussion hosted by DataArt on June 9th, 2016 at the Harvard Club of New York City brought together top technology executives from major hospitals and healthtech companies in an enticing dialogue on patient engagement innovation. The event was attended by 80 healthcare industry professionals.
Daniel Piekarz, VP & Partner, Healthcare & Life Sciences, DataArt moderated the discussion and was joined by Chaim Indig, CEO, Phreesia, Dr. Barry Goetz, Director of Clinical Informatics, Population Health and Ambulatory Care, Northwell Health, Dr. Ashish Atreja, Chief Technology Innovation and Engagement Officer, Department of Medicine, Mount Sinai Health System, Mony Weschler, Chief Technology & Innovation Strategist, Montefiore Medical Center and John Donohue, Associate CIO, University of PA Health System.
The third Phocuswright Europe Conference was held at the Convention Centre Dublin on the 10-12 of May 2016 and drew the continent’s top players to exchange views on the trends in technology for the European travel market. The theme was “Unsettled yet Undeterred”, reflecting the backdrop of Europe’s bumpy economic recovery and reduced spending on travel.
The travel industry DNA is changing, with important shifts happening from one year’s Phocuswright to the next.
Stephen Kaufer, CEO, Tripadvisor, emphasized the company’s shifting focus from a review resource to one that accommodates instant bookings. KAYAK and Google have also introduced direct bookings.
Today IoT is expanding it’s borders and creeping into our daily lives. Devices are placed everywhere, various size from tiny things to monstrous automatic machinery. The internal device architecture and design form the constraints on the device behavior. Device protocol, operational cycle, and time are often limited by batteries, the underlying hardware, and existing libraries. The variety of protocols and message types means a typical solution to unite them involves implementing bridge-adapters that are capable of transforming data into a common format.
Bridges are often seen as a pipe accepting messages and passing them to the next collector or adapter-bridge. The central business logic resides in the middle. Central logic responsible for accepting and handling all the messages. The replies are sent back, routed through the channels back to the device and client. A typical solution will require several type of adapters to be deployed. With an increasing number of bridges, fault tolerance requirements should be kept. At this point, cluster maintenance and monitoring becomes important task.
Modern internet technologies are constantly changing the way people communicate with each other. Various platforms and resources successfully connect producers and consumers, employers and job applicants, buyers and sellers. Social networks create communities and unite people who share common interests, from hobbies to business. The trading community is no exception.
What has changed?
For decades, POS workplaces have been built on standard PCs. Starting with DOS, then moving to other operating systems, COM-ports have been replaced by USB, but the situation hasn’t changed much: industrial PCs are put inside a specially designed computer casing.
Traffic accidents in the UK, 1979-2004.
Whether you are a journalist, a researcher or a data geek, in order to start working with large data sets, you have to complete laborious tasks of setting-up an infrastructure, configuring an environment, learning new unfamiliar tools and coding complicated apps – with DC/OS you can start crunching those numbers within minutes.
Let’s start with a problem of analyzing a set of data and take a road safety data from Great Britain, 1979-2004. While the data set might seem small, some of the analysis might require distributed processing and we should have an environment that allows our processing jobs to scale horizontally. To achieve this, we’ll be running a DC/OS cluster on top of a cluster of virtual machines. We’ll be using AWS EC2 in this scenario, but the same solution can be ported to other public and private clouds.