Re: [m2m-iwg] DeviceHive

[UOMo <uomo@xxxxxxxxxxx>]

Ian/Rick/all,

Indeed, but so is almost every leading and mature Embedded solution in the last 10 or more years

This is an article about the greenhouse and home automation vendor I wrote that device to DDE to RMI bridge 10 years ago to remotely control its devices from a Mobile Web Application based on J2EE (that's what it was called then at least)

http://www.hortidaily.com/article/825/Germany-RAMs-VisuSpectrum-allows-researchers-to-visualize-adjusted-light-spectra

The company web site (sorry only German, but several members of this list seem from Germany, so I figured it might help them)
http://www.ram-group.com/

You won't find a single non-PC or Windows application there. Also in Dubai with our NFC and Ticket vending project for Xerox/ACS I remember all Embedded devices there (and in other countries including Switzerland or several US States including NY/NJ) run Windows CE. It is possible they experiment with Windows Phone/Embedded now, but most will remain there, after all the whole "LTS" aspect is very big for those customers, too. They won't jump to Android or Windows Phone 8 and replace Millions of devices

At least the readers for Smart Containers here in Scandinavia used with Maersk are either Windows CE or Psion (Symbian), too. All pretty much technologically the same generation of our Mobile Web Clients for the RAM solution I did 10 years ago.

Having a Windows server may not be such a bad thing, though an (Embedded) Java equivalent running on e.g. a Raspberry Pi could be an interesting challenge and addition to this Github project (I'll ask Stephen Chin about it tonight when I see him again at GR8Conf)

The broad variety of client devices, J2ME (compatible with the latest CLDC8/MEEP once that goes Final) Android or other platforms are equally supported, that looks very interesting there.

The scripting language of choice is Python, that will make it interesting and potentially useful for the colleagues here at Maersk in my current team (and maybe even those dealing with remote container access and management) 

It may not be the first language of choice for the Lua community, but Python and Lua are not that different, so maybe somebody could add Lua to the DeviceHive stack, too?

Thanks Ian for mentioning it.

Werner

On Thu, May 23, 2013 at 9:39 AM, <m2m-iwg-request@xxxxxxxxxxx> wrote:

------------------------------

Message: 2
Date: Wed, 22 May 2013 20:48:46 +0000
From: Rick Bullotta <rick.bullotta@xxxxxxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] DeviceHive
Message-ID:
        <C7D31C647F791B439B6E65E10053D5370DA44669@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Content-Type: text/plain; charset="us-ascii"

Just took a look. Seem another protocol missing a metamodel and concrete data/command formats.  Server is .NET only for now.


From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of Ian Skerrett
Sent: Wednesday, May 22, 2013 4:42 PM
To: m2m Industry Working Group
Subject: [m2m-iwg] DeviceHive

Does anyone have experience with DeviceHive?  http://www.devicehive.com/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130522/62feaafb/attachment.html>

------------------------------

Message: 3
Date: Wed, 22 May 2013 21:00:36 +0000
From: Rick Bullotta <rick.bullotta@xxxxxxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] DeviceHive
Message-ID:
        <C7D31C647F791B439B6E65E10053D5370DA446B2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>

Content-Type: text/plain; charset="us-ascii"

A few other observations:


-          Kind of a "one size fits all" command approach that leaves the payloads pretty much a black box - needs to be more specific command types/formats/associated semantics

-          I like some of the higher level object semantics and the device typing, although it is incomplete and doesn't really let you discover the device's capabilities (another "black box" blob for that)

-          Similar to the approach we've taken at TW where the "pipe" and "wire format" could be just about anything (JSON or binary over HTTP, web sockets, raw sockets, serial/BT), so I like that part ;-)

-          Device registration doesn't require any authorization, which is a pretty big security hole

-          The concept of a "network" is an interesting organizational concept which I also agree with - enables faux multi-tenancy and bulk permissions to be managed more easily.  We call them "ThingSpaces" but same basic idea.

-          I like some of the QoS stuff built into the command structure to allow lifetime for commands.  Should be more structure/specifics to the command status/flags though

That's a quick brain dump if it helps.


From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of Rick Bullotta
Sent: Wednesday, May 22, 2013 4:49 PM
To: m2m Industry Working Group
Subject: Re: [m2m-iwg] DeviceHive

Just took a look. Seem another protocol missing a metamodel and concrete data/command formats.  Server is .NET only for now.


From: m2m-iwg-bounces@xxxxxxxxxxx<mailto:m2m-iwg-bounces@xxxxxxxxxxx> [mailto:m2m-iwg-bounces@xxxxxxxxxxx] On Behalf Of Ian Skerrett
Sent: Wednesday, May 22, 2013 4:42 PM
To: m2m Industry Working Group
Subject: [m2m-iwg] DeviceHive

Does anyone have experience with DeviceHive?  http://www.devicehive.com/