[OpenTRV-dev] IBM comment on Launchpad network / data-flow architecture...

[Bruno Girin]

On 3 July 2015 at 13:58, Damon Hart-Davis <damon at opentrv.uk> wrote:

> http://www.earth.org.uk/note-on-IoT-comms-backhaul.html#app1
>
> Any followup comments?
>

Here goes.

The IBM view is interesting and reflects the fact that a lot of their
offering thrives on a cloud infrastructure. I agree that a cloud store
provides operational benefits in terms of data processing. However that
doesn't mean that the solution should depend on a cloud store. Here are my
reasons why a data platform shouldn't be essential:

1. Internet connections can fail, both in the domestic and commercial
worlds (as aptly demonstrated by my ADSL dropping dead on Friday night due
to a massive storm) which would result in missing data if the concentrator
is unable to operate in disconnected mode.

2. There are already dozens of IoT platform offerings on the market: at the
moment, every single piece of IoT hardware you can buy comes with its own
platform that requires custom integration to make it talk to other
platforms (HyperCat notwithstanding) and an iOS or Android app to configure
the device which results in a lot of silos so it would be nice to change
that. The current approach allows OpenTRV to let customers use the data
platform of their choice and move away from silos.

3. Designing and operating a cloud data platform is complex and expensive
so even if that was something OpenTRV wanted to do, it would probably
require a larger team than the current one.

That said, a data platform can be a nice addition for large commercial
deployments where one doesn't exist yet. The way for OpenTRV to offer that
could be an open source implementation that people would deploy on their
own infrastructure or cloud.



Now for a competing view on this, if you were to ask Cisco, they are
currently pushing the concept of smart devices at the edge of the network,
i.e. devices that fit in a network router and have the power of a
RaspberryPi 2 and can do some of the processing on premise before it leaves
the network. The reasoning behind this is that you can then implement an
efficient feedback loop to control on-premise devices without a round trip
to the internet (e.g. change the room's target temperature as a result of
local changes).

My £0.02

Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20150706/9962d0bb/attachment.html>