[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2m-iwg] MQTT <-> REST+websocket mapping
|
I somehow got that idea, but it would be great, if the field was not editable and showed that temperature (ideally with correct unit;-) right away.
On Mon, Mar 18, 2013 at 8:22 PM,
<m2m-iwg-request@xxxxxxxxxxx> wrote:
Send m2m-iwg mailing list submissions to
m2m-iwg@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
or, via email, send a message with subject or body 'help' to
m2m-iwg-request@xxxxxxxxxxx
You can reach the person managing the list at
m2m-iwg-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of m2m-iwg digest..."
Today's Topics:
1. Re: MQTT <-> REST+websocket mapping (Matteo Collina)
2. Re: Consumer device security (was: M3DA presentation) (T-Rob)
3. Re: Consumer device security (was: M3DA presentation) (T-Rob)
----------------------------------------------------------------------
Message: 1
Date: Mon, 18 Mar 2013 19:09:14 +0000
From: Matteo Collina <matteo.collina@xxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] MQTT <-> REST+websocket mapping
Message-ID:
<CAANuz57+KHwKG2-ycmPWj_iTtctzZd806-p=MZ1bxjZg_+W2Hw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
2013/3/18 UOMo <uomo@xxxxxxxxxxx>
> Matteo/all,
>
> Thanks for the updates. Probably have to see what's discussed on the Paho
> mailing list, too.
>
> 2) I tried that URL and at first it it empty. When you click "Edit" and
> enter any sort of value, like 56 or 32, it keeps coming back with "18" as a
> result. Given the different input, I assume it isn't temperature
> conversion, but I would have hoped to see that "18" in the first place.
>
Actually that's the sensor updating the value :).
Werner, you cannot change my house temperature :).
> And while one may guess that your home in Italy is measuring temperature
> in Degree Celsius, in the World Wide Internet of Things this isn't obvious
> at all.
> A classical example of Units that must be taken into consideration.
>
You are totally right.
I'm not currently addressing that point, which should be taken into
consideration.
However, I believe a standard message representation for sensor data should
emerge, one which includes all possible metadata to allow further
consumption. That should at least support:
1) time
2) space (lat & long)
3) unit of measurements
A full discussion on all possible requirements has been done by the
Semantic Web community in the SSN ontology:
http://www.w3.org/2005/Incubator/ssn/wiki/Report_Work_on_the_SSN_ontology.
3)
> See above, I had a few discussions with the makers of Cosm when it was
> still called Pachube, as their datafeeds vary a lot. Some have decent
> handling of measurement values and units, e.g.
>
> https://cosm.com/feeds/40318
> Energy, wind speed and temperature
> none of them with a proper unit[?]
> A feed from Belgium: https://cosm.com/feeds/66151
> says "?" but is it Celsius, Fahrenheit or Rankine?[?]
> This one has no data feed, but the temperature unit is said to be "c":
> https://cosm.com/feeds/63802
> Not standard compliant, but at least gives a vague idea it seems Celsius[?]
> This air quality Egg from Portland, OR
> https://cosm.com/feeds/81913
> shows "Deg C" among other units, even a bit better.
> And this one from Slowenia
> https://cosm.com/feeds/96652
> wins the "World Cup", not just of Alpine Skiing, by properly declaring "?C
> "[?]
>
>
> If any of these values shall make sense in a Global M2M environment,
> metadata must contain units of measurement, and a unit or code system. That
> could be ISO, USCustomary, Imperial, UCUM or whatever, as long as both
> sides can adjust to the right system to understand each other[?]
>
> 5) Cosm uses OAuth 2.0, at least there is a Beta trial, so is for MQTT
> btw, although it says, it may go away with no further warning[?]
> https://cosm.com/docs/beta/mqtt/
>
The problem with Pachube/Cosm is that is built to store data, not to let
the devices talk and work between themselves in an autonomous way.
Cheers,
Matteo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130318/be833b8c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 329.gif
Type: image/gif
Size: 257 bytes
Desc: not available
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130318/be833b8c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 35F.gif
Type: image/gif
Size: 540 bytes
Desc: not available
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130318/be833b8c/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 330.gif
Type: image/gif
Size: 96 bytes
Desc: not available
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130318/be833b8c/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 33D.gif
Type: image/gif
Size: 104 bytes
Desc: not available
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130318/be833b8c/attachment-0003.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 347.gif
Type: image/gif
Size: 186 bytes
Desc: not available
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130318/be833b8c/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 322.gif
Type: image/gif
Size: 100 bytes
Desc: not available
URL: <http://dev.eclipse.org/mailman/private/m2m-iwg/attachments/20130318/be833b8c/attachment-0005.gif>
------------------------------
Message: 2
Date: Mon, 18 Mar 2013 15:22:22 -0400
From: T-Rob <t.rob.wyatt@xxxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] Consumer device security (was: M3DA
presentation)
Message-ID:
<OF41DB3DB4.C9177448-ON85257B32.0061A069-85257B32.006A6D2D@xxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"
Hi Rick,
Linux was once for hobbyists and tinkerers, not the mainstream public.
Being a hacker platform doesn't preclude mainstream adoption. Failure to
address consumer demand does. The X-10 example wasn't about protocol but
rather the lack of core functionality. Having a device which maintains
state and responds to commands but doesn't allow inquiry of its state and
doesn't reliably broadcast state changes isn't going to get past tinkerers
and hobbyists no matter how slick an interface sits up front.
On the other hand, look at the Smart Home products that are making some
progress lately. Thermostats, net cams, door locks are all now on the
shelves at big box retailers, all have phone apps, all respond to inquiry.
Would you even consider buying a thermostat if after sending a command
you could not then see if the command was received? State inquiry is the
"killer app" of devices. Without it they suck. Actuation is great but it
is second to inquiry, not primary functionality. Actuation without
inquiry is... well, it's X-10.
> I think the reason that instrumenting home appliances hasn't taken
> off is that the value/cost ratio isn't there yet (read: no appliance
> mfg is going to add production cost without good reason), nor are
> there enough compelling reasons for the consumer to be willing to
> pay extra for this capability, beyond those same early adopters who
> grabbed onto stuff like X10, etc....
Leviton dumb dimmers are about $10 on Amazon today. The smart version
about $70 and up to $180. For a freakin' switch. I'm not understanding
price sensitivity as a showstopper issue on a $500 ~ $1,500 appliance.
But, for sake of argument, let's stipulate that the value/cost argument is
correct. In that case, what is the path that gets us there? How do we
add value that consumers will pay for at a price manufacturers will
support? Is it by keeping the device data from them and investing
tentatively in applications to use that data, then waiting to see if
there's a response? Or is it by giving the data to the consumer and
letting them do whatever they want with it? I'm betting the value in a
networked light bulb isn't so much in controlling the bulb from a phone
but rather the ability to program complex behaviors among many different
participating devices from a variety of vendors.
Case in point, in Naperville, IL a group is vigorously fighting smart
meters. Among their tactics is a form letter declaring the meters to be
unlawful wiretapping surveillance devices based on the utility's access to
fine-grained meter readings. The letters have started to go viral and are
being picked up and used by other protest groups.
Meanwhile, the folks at Ube are raking in money to bring their switches
and outlets to market. They won the $1M People's Choice award at Demo 2012
and currently have 1,000 backers spending an average of $200 each on
KickStarter. The core functionality of the devices is sub-metering for
each switch and for each of the two sockets in a dual-outlet device. The
devices transmit data back to Ube but they also do so locally and expose
an API.
Whether Ube's initial success translates to mainstream adoption remains to
be seen. But clearly there's a lot of people who not only don't mind
power metering, but they like it with resolution down to individual
devices and, when offered compelling functionality, don't mind giving that
fine-grained data to their vendor. Would the Ube devices be compelling if
all the pone app did was blindly send commands to the devices and had no
way to know whether they worked or the current state of the device? I
don't think so.
In any case, I don't want to derail the work going on here. I just
thought that if anyone on the net would be likely to respond positively to
the vision of consumer as first point of integration and local device
data, it would be this group. My hope was to spin off a project to work
on that goal but not at the expense of signal-to-noise on the list or of
the other projects.
-- T.Rob
m2m-iwg-bounces@xxxxxxxxxxx wrote on 03/18/2013 01:29:32 PM:
> From: Rick Bullotta <rick.bullotta@xxxxxxxxxxxxx>
> To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>,
> Date: 03/18/2013 01:30 PM
> Subject: Re: [m2m-iwg] Consumer device security (was: M3DA presentation)
> Sent by: m2m-iwg-bounces@xxxxxxxxxxx
>
> Really? The reason X-10's failure was protocol? Respectfully
> disagree. It's because it was for hobbyists and tinkerers, not the
> mainstream public...
>
> I think the reason that instrumenting home appliances hasn't taken
> off is that the value/cost ratio isn't there yet (read: no appliance
> mfg is going to add production cost without good reason), nor are
> there enough compelling reasons for the consumer to be willing to
> pay extra for this capability, beyond those same early adopters who
> grabbed onto stuff like X10, etc....
>
>
>
> -----Original Message-----
> From: m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx
> ] On Behalf Of T-Rob
> Sent: Monday, March 18, 2013 1:22 PM
> To: m2m Industry Working Group
> Subject: Re: [m2m-iwg] Consumer device security (was: M3DA presentation)
>
> Hi Fabien,
>
> I agree with everything you wrote up to "this issue is solving
> itself already." Despite being in sync on the supporting
> statements, somehow we came to opposite conclusions.
>
> We've had X-10 for quite some time now and it never took off.
> Issues with bridging circuits at the breaker box were solved and it
> didn't help adoption. The main issue has been that the devices
> either emitted or received commands but do not respond to state
> inquiry. However, all their communication is designed to be local.
>
> Now there's a big experiment to go the other way. The devices have
> considerably more functionality. Not only do they respond to state
> inquiry, but they often have sensor platforms built in so that a
> switch, for example, might also report temp, humidity, ambient light
> and proximity. However the new generation of devices are primarily
> designed to *not* talk locally and consumer response is predictably
> unenthusiastic.
> The Association of Home Appliance Manufacturers can't figure out
> why consumers haven't responded. According to the chair of their
> task force, "We're asking all those questions and inviting people to
> comment. We need to determine the barriers to getting through. Is it
> technical? Is it regulatory?" I say, no, it's topology and data
openness.
>
> It's not as though consumers aren't interested or that their
> interest isn't measurable. Vendors aren't giving them what they
> want, so consumers are simply routing around the vendors and a host
> of new devices and start-up manufacturers is beginning to emerge.
> The availability of platforms like DigiSpark or Pinoccio mean that
> consumer interest in devices with non-local data will only decline
> over time. They'll either wait for the vendor to get it right or
> buy a cheap, dumb appliance and upgrade it themselves. The
> objection I often hear to this prediction is that advanced hobbyists
> doing custom upgrades aren't going to disrupt the market. My
> counter to that objection is the availability of services to
> customize cell phones. Hacking a phone was once a hobbyist activity
> but with sufficient demand it became a business, and a big one at
> that. If appliance vendors don't get their act together soon,
> someone will think to build a wiring harness that interfaces
> Pinoccio into the
> most common washers & dryers, then sell that kit to independent
> service technicians.
> What vendors fail to realize is that solving the retrofit problem
> also solves the new appliance problem. Consumers won't need the
> vendor version of "smart" device when for the price of a service
> call and $150 per appliance they can add a whole houseful of "dumb"
> devices to the local network and be guaranteed compatibility and
> full access to all of them.
>
> So, no, I don't believe the issue is solving itself already. Or at
> least if it is, it is doing so without participation of industry.
>
> -- T.Rob
>
------------------------------
Message: 3
Date: Mon, 18 Mar 2013 15:22:23 -0400
From: T-Rob <t.rob.wyatt@xxxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>
Subject: Re: [m2m-iwg] Consumer device security (was: M3DA
presentation)
Message-ID:
<OFE2004775.C5E4025A-ON85257B32.00683ADE-85257B32.006A6D49@xxxxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"
Thanks, that clarifies it for me.
I think we are basically in agreement on the user experience and
interface. My only additional stipulations to what you've stated are:
The devices must behave at least as well as a dumb device of the same type
if deployed without connectivity.
Once provisioned, the devices must continue to function when the network
is down.
The devices must expose an API accessible to the local network.
The local transport must support pub/sub topologies.
The most compelling applications require correlation across many different
device types and information sources. They won't emerge until we have a
legal and technological framework to aggregate and correlate it. Right
now, that's easy if the data and app both reside locally, very difficult
if the data flows first to vendors. Hence, local data, API and inquiry is
Apple in this scenario whereas encrypted tunnel of data back to the vendor
is Palm, even with a really good phone app to back it up.
-- T.Rob
From: Fabien Fleutot <fleutot@xxxxxxxxx>
To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>,
Date: 03/18/2013 02:24 PM
Subject: Re: [m2m-iwg] Consumer device security (was: M3DA
presentation)
Sent by: m2m-iwg-bounces@xxxxxxxxxxx
The issue which I was describing as solving itself was the move of
specialized data management toward the cloud, whether internal IT
departments liked it or not. Consumer market is quite trickier indeed.
As for X10, my personal experience is that:
I'm not aware of an X10 hub which is generic and doesn't suck;
I don't trust cheap X10 devices to integrate seamlessly in an ecosystem
I'd build at home.
Let's do the mandatory comparison with the mother of all consumer market
redefinitions, the iPhone introduction: before Apple demonstrated the
level of usability required for non-uber-geeks to want a smartphone,
I'm sure legacy vendors were puzzled about why people wouldn't buy more of
their stuff, and blamed anything but the clumsiness of the experience they
were offering.
For X10 or a competitor to take off, we need to be able to tell regular
folks the following:
Buy this $100-$200 box, plug it on your xDSL router;
>From now on, anything you'll buy with an "X10" logo on it at the DIY store
will be easily accessible on your phone, on your home PC, on remote PCs;
You won't need a geek's help to configure the gizmos, nor the hub, nor the
router; your hardware will inspire you confidence, not fear.
We're still very far from there AFAIK, but I believe it's primarily a
matter of great execution by a vendor. Just as before the iPhone, I'd
never have dreamed of receiving an e-mail, with a video attached to it,
from my mother's smartphone :)
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
------------------------------
_______________________________________________
m2m-iwg mailing list
m2m-iwg@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/m2m-iwg
End of m2m-iwg Digest, Vol 17, Issue 29
***************************************
