Stupid design decisions

On Sat, 4 Feb 2017 14:42:43 -0000 (UTC), mac <acolvin@efunct.com>
wrote:

>
>> There are also a number of smoke detectors that are (or can be)
>> Internet connected.  Many of those also avoid the need for wires to
>> interconnect multiple detectors in a house.
>
>Because, what could go wrong?


They should, at least, continue to function as singleton smoke
detectors even if all the connectivity is bollixed.  Is that good
enough?  That's an interesting question.

When my house was built, the local building code required
interconnected smoke detectors on each floor.  They did *not* require
battery power for the detectors.  IOW, don't have a fire when the
power is out.

IFAIK, the current code requires interconnected detectors, powered off
both mains and a battery.

Now interconnected detectors were pretty new on the market at the
time, and ones powered off both mains and a battery were rarer still.
The real question is was that the best trade-off for the time?
Interconnection is certainly a good thing, and mains powered smoke
detectors are likely powered and function far more of the time than
battery (only) powered ones.

If you get something like a Nest Protect, and put it in an existing
house, and it gets connected, with less than perfect reliability, via
WiFi, to other smoke detectors in the house (where no such thing
existed before), is that not at least a step in the right direction?
Or should be either demand that older buildings be retrofitted with
interconnect wiring, or not have interconnected alarms at all?

In any event, when I figured out that the wired detectors in my house
had no batteries, I simply installed an inexpensive battery operated
stand-alone detector a few feet from the detector on the main floor.
Which deals with most of the issue.

On 05/02/17 08:00, Robert Wessel wrote:
> On Sat, 4 Feb 2017 14:42:43 -0000 (UTC), mac <acolvin@efunct.com>
> wrote:
>
>>
>>> There are also a number of smoke detectors that are (or can be)
>>> Internet connected.  Many of those also avoid the need for wires to
>>> interconnect multiple detectors in a house.
>>
>> Because, what could go wrong?

Start with the company going broke and its servers being
turned off! Then consider technical issues.


> They should, at least, continue to function as singleton smoke
> detectors even if all the connectivity is bollixed.  Is that good
> enough?  That's an interesting question.

https://catless.ncl.ac.uk/Risks/30/09#subj1.1
Stunning mis-design from a very well known and well publicised
high tech company, Tesla.

On Sun, 5 Feb 2017 09:11:30 +0000, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 05/02/17 08:00, Robert Wessel wrote:
>> On Sat, 4 Feb 2017 14:42:43 -0000 (UTC), mac <acolvin@efunct.com>
>> wrote:
>>
>>>
>>>> There are also a number of smoke detectors that are (or can be)
>>>> Internet connected.  Many of those also avoid the need for wires to
>>>> interconnect multiple detectors in a house.
>>>
>>> Because, what could go wrong?
>
>Start with the company going broke and its servers being
>turned off! Then consider technical issues.


Although none of that should really be required for those to run as
singleton smoke detectors.


>> They should, at least, continue to function as singleton smoke
>> detectors even if all the connectivity is bollixed.  Is that good
>> enough?  That's an interesting question.
>
>https://catless.ncl.ac.uk/Risks/30/09#subj1.1
>Stunning mis-design from a very well known and well publicised
>high tech company, Tesla.


Yet another case of something designed as a backup system becoming the
primary system, without meeting all the requirement of the primary
system.  The obvious solution is to allow the car to use a Bluetooth
connection to authenticate the driver's phone.  OTOH, that introduces
a new security issue - your phone can then always unlock the car, even
if it's been stolen and the account disabled.

On 2/5/2017 12:49 AM, Robert Wessel wrote:
> On Sat, 4 Feb 2017 13:00:59 -0700, Don Y <blockedofcourse@foo.invalid>
> wrote:
>
>> On 2/4/2017 4:03 AM, Paul wrote:
>>> In article <o71vmm$qm1$1@dont-email.me>, lcargill99@comcast.com says...
>
>>> If you have a MAINS connected device don't use Wifi use the Mains wiring
>>> you already have to talk yo your base station.
>>
>> Bridging the two legs of the (split) transformer, here, poses challenges
>> for high bandwidth comms when the nodes are on opposite legs.
>>
>> It also suffers from the same congestion that the wireless approach
>> experiences with a "shared medium".
>
> OTOH, the vast majority of IoT devices will likely have very modest
> bandwidth requirements.

The number of device instances that will have low bandwidth requirements
vs. high is immaterial.  What matters is the total bandwidth requirement
per installation site.

Your IoT "doorbell button" will have a data rate at about 0bps -- "peak".  :>
OTOH, the door *camera* that will be triggered by such an event will have a
very high, peak data rate as it streams live video to your phone, PiP TV
display, etc.

This will be true of any/all "media streams" (does your IoT TV have hard wires
to its audio-video source(s)?  does it have hard wires to the 5.1 speakers
distributed around the viewing area?  what about the *other* TV in your
kid's bedroom?  etc.)

There will also be background "maintenance" traffic -- ping'ing each device to
ensure it is still "available", performing status updates, polling, etc.

So, the communications infrastructure has to have peak capabilities
adequate for the composite needs of ALL of these devices that might
be chattering concurrently.  Along with surplus capacity to handle
ADDING nodes at a later date!

And, this assumes a "dumb mote" sort of approach with centralized control
(so, much of the "traffic" can be contained within the "server" instead of
in amongst the field/wiring).

I opted for the other approach -- distributed intelligence so the computational
abilities of the system scale more linearly with the I/O's (add a class of I/O
and it brings horsepower along with it -- instead of just "communications
aparatus").  This places other demands on the network fabric as now that
traffic that would have been contained within a server(s) has to flow between
field nodes (of course, this means that the nodes can actually "get things
done" instead of having to rely on the server(s) for all the "work")

On 2/5/2017 1:00 AM, Robert Wessel wrote:
> On Sat, 4 Feb 2017 14:42:43 -0000 (UTC), mac <acolvin@efunct.com>
> wrote:
>
>>> There are also a number of smoke detectors that are (or can be)
>>> Internet connected.  Many of those also avoid the need for wires to
>>> interconnect multiple detectors in a house.
>>
>> Because, what could go wrong?
>
> They should, at least, continue to function as singleton smoke
> detectors even if all the connectivity is bollixed.  Is that good
> enough?  That's an interesting question.

Will the addition of that hardware/functionality hook expose another
attack surface?  E.g., if I push an endless stream of runt packets
at it (either due to a system flaw *or* a malicious attack), can
I crash the procesor and compromise the functionality that it was originally
intended to provide -- before someone BOLTED ON this connectivity
capability (in the least expensive manner possible)?

> When my house was built, the local building code required
> interconnected smoke detectors on each floor.  They did *not* require
> battery power for the detectors.  IOW, don't have a fire when the
> power is out.
>
> IFAIK, the current code requires interconnected detectors, powered off
> both mains and a battery.

ISTR the reasoning being that folks won't replace batteries promptly
and will end up disconnecting the detector -- because of its annoying,
insistent "chirp".  This leaves them with NO protection.

A hard-wired detector ensures the home remains protected in the presence of
the dead battery.

> Now interconnected detectors were pretty new on the market at the
> time, and ones powered off both mains and a battery were rarer still.
> The real question is was that the best trade-off for the time?
> Interconnection is certainly a good thing, and mains powered smoke
> detectors are likely powered and function far more of the time than
> battery (only) powered ones.

AFAICT, the actual operation of the detector is unchanged.  It is
still a "sampled system" with very low duty cycle -- having AC power
doesn't cause it to check the air more frequently than if battery powered.

And, a battery powered detector will function 24/7/365 -- IF the battery
is maintained!

This, however, implies proactive maintenance (neglecting the case of the 10yr
no-user-serviceable-parts-INCLUDING-BATTERIES-inside) as waiting for the
detector to start chirping to signal the need for a new battery is likely
to lead to the abovementioned user behavior.

> If you get something like a Nest Protect, and put it in an existing
> house, and it gets connected, with less than perfect reliability, via
> WiFi, to other smoke detectors in the house (where no such thing
> existed before), is that not at least a step in the right direction?

First, assume its reliability is AS GOOD AS a "less sophisticated"
product.  Otherwise, there may not be an "upside" to its desirability!
Forget cost, consider what the added complexity does to the reliability
of the device.  Then, consider how having this mechanism for causing
*that* device to alarm (false positive) can affect the usage pattern,
but NOT the usage of the non-WiFi device.

Second, if interconnectability is a desirable goal, then a flakey/faulty
interconnection is inherently a deficiency.  Having "reverse" on a car
isn't really a "feature" -- despite the fact that a car WITHOUT reverse
can still "get you to market".

> Or should be either demand that older buildings be retrofitted with
> interconnect wiring, or not have interconnected alarms at all?

The problem is one of writing *a* guideline for ALL installations.
Here -- and I suspect in many homes -- the bedrooms are clustered
together.  And, the requirement is for one in/outside each bedroom.
Wiring them together doesn't alert sleepers elsewhere in the house
to a potential alarm condition as they can all hear each others'
detectors sounding -- even if not interconnected.

OTOH, homes with split floor plans, bedrooms on two or more floors,
etc. could benefit from the ability to alert other sleepers of
a condition detected IN ANOTHER PART OF THE HOUSE -- *before* the
condition progresses to also jeopardize their immediate environs.

> In any event, when I figured out that the wired detectors in my house
> had no batteries, I simply installed an inexpensive battery operated
> stand-alone detector a few feet from the detector on the main floor.
> Which deals with most of the issue.

That's what we originally did.  Then, "upgraded" during one of our
remodels.  However, the floorplan still has all of the detectors
(smoke+CO) within arm's reach of each other.  So, it's just EXTRA
LOUD instead of providing any advanced warning from "other parts
of the house".

[I was dismayed at how non-authoritative the folks at the local
fire department were re: location of detectors.  Instead of having
hard-and-fast rules, you could talk around them and they'd be willing
to agree with virtually any logical argument you could present.
Doesn't inspire confidence!  :< ]

On 2/5/2017 2:11 AM, Tom Gardner wrote:
> On 05/02/17 08:00, Robert Wessel wrote:
>> On Sat, 4 Feb 2017 14:42:43 -0000 (UTC), mac <acolvin@efunct.com>
>> wrote:
>>
>>>
>>>> There are also a number of smoke detectors that are (or can be)
>>>> Internet connected.  Many of those also avoid the need for wires to
>>>> interconnect multiple detectors in a house.
>>>
>>> Because, what could go wrong?
>
> Start with the company going broke and its servers being
> turned off! Then consider technical issues.

I can't believe (?) that a smoke detector has to contact the
manufacturer's server before it can contact its *peer* smoke
detector in the next room!  (?)

I also don't see the need for a real 802.11 stack just to chat
with another smoke detector WITHOUT RUNNING WIRES in the home.

This sounds like a case for "shoot the engineer"...

>> They should, at least, continue to function as singleton smoke
>> detectors even if all the connectivity is bollixed.  Is that good
>> enough?  That's an interesting question.
>
> https://catless.ncl.ac.uk/Risks/30/09#subj1.1
> Stunning mis-design from a very well known and well publicised
> high tech company, Tesla.

Actually, people regularly rely on assumptions that are baseless.
When you quiz them ("And what if there is no cell phone coverage?")
you can almost see the clutch drop out of their thought process
as they then stumble to reengage it:  "Huh?"

We call these colossal FAILS *bugs* (, latent).

In article <o75bqe$n0q$1@dont-email.me>, blockedofcourse@foo.invalid 
says...
> 
> On 2/4/2017 4:03 AM, Paul wrote:
..... 
> > I see enough issues with Wifi in houses not working or because three
> > people are streaming they get buffering (partly due to low broadband
> > speed). Often the heat efficient houses have foil backed dry wwalling
> > (plasterboard), making each room into its own Faraday cage. Let alone
> > the ones with stone walls a foot or more thick.
> 
> Or, other emanations that cause retransmissions, etc.
> 
> Note that not all comms can be easily "buffered" without appreciably
> impacting performance or the UX.  Would you want your VoIP phone to
> incur a lengthy lag just to ensure a sufficient buffer IN the device
> to provide continuous speech in the presence of congestion?
> 
> > If you have a MAINS connected device don't use Wifi use the Mains wiring
> > you already have to talk yo your base station.
> 
> Bridging the two legs of the (split) transformer, here, poses challenges
> for high bandwidth comms when the nodes are on opposite legs.
> 
> It also suffers from the same congestion that the wireless approach
> experiences with a "shared medium".
> 
> Finally, any shared medium makes it problematic to contain the traffic
> from eavesdroppers *or* malicious attack -- even if that is just a DoS
> attack.

If you need high bandwidth for smoke detectors, light switches and the 
like then you are doing TOO much!!!

Most devices do not need to update every ms more like 1s to 30s, with
response to command probably less than 0.5 second.

What the hell are you expecting to send to all these devices even 1000
devices on a polled network with base controller can organise when they 
should poll, based on priority smoke detector much higher than light 
switch. If you cannot do all devices in 1 second then the amount of data 
is too big, the biggest part should be some form of GUID and type ID
the rest of the data should be less than that.

At quick top of head calculation it should be doable in 10Mb link speeds 
which is easily doable on mains. I can get cheap mains networking that 
does 500Mb for streaming video. This sort of control network should NOT
need high bandwidth. If it does then you are over specifying the IoT
processor and its requirements in each node.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/LogicCell/>   Logic Gates 
Education 
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate

In article <o76b4c$clc$1@dont-email.me>, blockedofcourse@foo.invalid 
says...
> 
> On 2/4/2017 9:36 PM, Grant Edwards wrote:
> > On 2017-02-04, Don Y <blockedofcourse@foo.invalid> wrote:
> >
> >>> The real issues with IoT are protocols, security and longeveity.
> >>>
> >>> Protocols I bet every manufacturer has their own 'extensions' to any
> >>> existing protocol.
> >>
> >> This can easily be addressed by Standards.
> >
> > Yep, and the great thing about Standards is that there are so many
> > different ones to choose from.  And so many different flavors of each
> > one.  And if you don't like any of them, you can always just write a
> > new Standard.
> 
> That's why *groups* write standards instead of individual organizations
> (even if those groups are composed of organizations).  Its not in THEIR
> best interest to go rogue with a corporation-specific standard -- unless
> they KNOW they can command a chunk of the market without risking losing
> it to some other players (e.g., Beta vs. VHS).

Autonomous groups SHOULD write standards and still they will be 
implemented differently, in the days of X25, there was different 
implementations for nearly EVERY country that used it.

Big players changed how things are done

> > Generally once somebody mentions "IoT" or "Industrie 4.0", I just stop
> > listening...
> 
> IoT is far too new/evolving.  People can't decide what the IoT

IoT is just a rebranding of network connected devices otherwise my 
network facing printers with their web interfaces and SNMP which have
done this for 15 years and more  are somehow different.


> environment will look like, how much of it will be covered in
> standards (i.e., which OSI layers), what the goals of the market will
> be, etc.

It is rebranding just like 'Cloud' BS first of all

	"There is NO cloud it is just someone elses computer"

Cloud is a rebranding of a mixture of things

	Web/FTP and other usages

	1960's buying of mainframe time slices

> Beyond the MECHANICS of communication, there's the whole semantic
> issue -- how do you codify *meaning* across an unconstrained set of
> devices/applications?

Most using Bluetooth, unlicensed ISM radio bands, Wifi band and some
using fixed wiring protocols that have been around for years.

One of my clients is moving a lot of their stuff AWAY from wifi to
wired due to site installation problems as their product involves
monitoring fridges, freezers for large establishments. The wifi or radio
is sporadic on a few sites or so clogged with employees phones 
continually using wifi bands a stheir phone apps continually phone home.
 
> So, individual players are trying to bring their own mini-ecosystems
> to the market and, of course, they are too narrow in scope.  You then
> end up with little islands of automation that do little more than
> give you remote control.

That unlike my 30 year old light switch may in 5 years be unsupported
unrepairable, not compliant etc..


-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/LogicCell/>   Logic Gates 
Education 
<http://www.pcserviceselectronics.co.uk/pi/>  Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate

On 05/02/17 18:10, Don Y wrote:
> On 2/5/2017 2:11 AM, Tom Gardner wrote:
>> On 05/02/17 08:00, Robert Wessel wrote:
>>> On Sat, 4 Feb 2017 14:42:43 -0000 (UTC), mac <acolvin@efunct.com>
>>> wrote:
>>>
>>>>
>>>>> There are also a number of smoke detectors that are (or can be)
>>>>> Internet connected.  Many of those also avoid the need for wires to
>>>>> interconnect multiple detectors in a house.
>>>>
>>>> Because, what could go wrong?
>>
>> Start with the company going broke and its servers being
>> turned off! Then consider technical issues.
>
> I can't believe (?) that a smoke detector has to contact the
> manufacturer's server before it can contact its *peer* smoke
> detector in the next room!  (?)
>
> I also don't see the need for a real 802.11 stack just to chat
> with another smoke detector WITHOUT RUNNING WIRES in the home.
>
> This sounds like a case for "shoot the engineer"...

Well, yes.

I remember a ong-running advert for a car, where every
feature was marked "No", e.g.
   water-cooled engine: no
except for
   central door locking: yes[1]
[1]all doors can be reached from the drivers seat

On 2/5/2017 2:31 PM, Paul wrote:
> In article <o75bqe$n0q$1@dont-email.me>, blockedofcourse@foo.invalid
> says...
>>
>> On 2/4/2017 4:03 AM, Paul wrote:
> .....
>>> I see enough issues with Wifi in houses not working or because three
>>> people are streaming they get buffering (partly due to low broadband
>>> speed). Often the heat efficient houses have foil backed dry wwalling
>>> (plasterboard), making each room into its own Faraday cage. Let alone
>>> the ones with stone walls a foot or more thick.
>>
>> Or, other emanations that cause retransmissions, etc.
>>
>> Note that not all comms can be easily "buffered" without appreciably
>> impacting performance or the UX.  Would you want your VoIP phone to
>> incur a lengthy lag just to ensure a sufficient buffer IN the device
>> to provide continuous speech in the presence of congestion?
>>
>>> If you have a MAINS connected device don't use Wifi use the Mains wiring
>>> you already have to talk yo your base station.
>>
>> Bridging the two legs of the (split) transformer, here, poses challenges
>> for high bandwidth comms when the nodes are on opposite legs.
>>
>> It also suffers from the same congestion that the wireless approach
>> experiences with a "shared medium".
>>
>> Finally, any shared medium makes it problematic to contain the traffic
>> from eavesdroppers *or* malicious attack -- even if that is just a DoS
>> attack.
>
> If you need high bandwidth for smoke detectors, light switches and the
> like then you are doing TOO much!!!

But IoT isn't limited to smoke detectors and light switches.

What do you do when your refrigerator initiates a web search to
determine who has the cheapest MILK, this week?  Then, follows up with
another search for EGGS, KETCHUP, etc.?

Meanwhile, the LCD display that replaces the front door of your
microwave oven is presenting live streaming video -- while your
kids are playing an interactive internet game on the TV in the
living room.

> Most devices do not need to update every ms more like 1s to 30s, with
> response to command probably less than 0.5 second.
>
> What the hell are you expecting to send to all these devices even 1000
> devices on a polled network with base controller can organise when they
> should poll, based on priority smoke detector much higher than light
> switch. If you cannot do all devices in 1 second then the amount of data
> is too big, the biggest part should be some form of GUID and type ID
> the rest of the data should be less than that.

See above.

Or, are you willing to redefine the devices to be allowed to participate
on your IoT network?

> At quick top of head calculation it should be doable in 10Mb link speeds
> which is easily doable on mains. I can get cheap mains networking that
> does 500Mb for streaming video.

Will it run in an apartment house setting where your neighboring
apartments are ALSO using the mains for THEIR devices?  And, the
apartment complex distributes "free CATV" using the same mechanism?

If you can do it with AC mains, then the same sort of non-problem
exists wirelessly.

> This sort of control network should NOT
> need high bandwidth. If it does then you are over specifying the IoT
> processor and its requirements in each node.

I ran 100Mb PoE to all of my nodes.  I regreted not running Gbe but the
hassles of handling the cable were just not worth the trouble in
"old construction".

I have 10 IP cameras.  What should they do with their video -- because I
don't want to "over spec'" the requirements for each node!?  Should they all
stream live video OVER THE AC MAINS to a central server that does the
real-time motion detection *and* capture?  Or, send it wirelessly?
If I do motion detection in the local node (by "over spec'ing" the
node's capabilities), that eliminates the PROCESSING requirement on
the remote server -- but, still doesn't eliminate the need to dispatch
the (now compressed!) video to that "repository".  So, there is still
a high bandwidth requirment.

Should the 6 audio channels for each "TV" be dispatched over hard wires to
the 6 speakers "near" each TV?  While the HD video is being dispatched to
the TV -- and, separately, collected from cable/satellite/OTA sources?
If I put smarts in the nodes (beyond simply reproducing lossless, baseband
audio), then I can reduce the bandwidth requirements for THAT audio.
Though, increase the complexity at the source (to mix, compress and transcode
the audio channels accordingly)

And the VoIP service?  etc.

Shared media, IMO, are NOT the answer -- despite being the easiest to
implement (for the consumer).  Instead, you want to be able to contain the
traffic and its bandwidth requirements to resources that you can scale
at will (i.e., add another network drop -- instead of having to petition
for another frequency allocation).

As with storage NEEDS increasing to fill the available disk SPACE, I
expect bandwidth requirements to fill the available bandwidth.

If you want to instill some QoS guarantees to ensure the smoke detectors
get preferential treatment -- or, the VoIP system -- then you complicate
the design of the system and the responsibilities for the user (*he* has
to resolve any competition for scarce resources)