Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2m-iwg] Consumer device security (was: M3DA presentation)

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
> 



Back to the top