Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #25662 > unrolled thread

Stupid design decisions

Back to article view | Back to comp.arch.embedded

Contents

  Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-01-05 21:14 -0600
    Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-06 12:27 -0700
    Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-06 14:51 -0500
    Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-01-06 20:22 +0000
      Re: Stupid design decisions David Brown <david.brown@hesbynett.no> - 2017-01-08 17:11 +0100
        Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-08 17:10 -0500
          Re: Stupid design decisions Dimiter_Popoff <dp@tgi-sci.com> - 2017-01-09 11:30 +0200
            Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-09 04:58 -0500
              Re: Stupid design decisions Dimiter_Popoff <dp@tgi-sci.com> - 2017-01-09 13:10 +0200
              Re: Stupid design decisions Clive Arthur <cliveta@nowaytoday.co.uk> - 2017-01-09 11:15 +0000
              Re: Stupid design decisions David Brown <david.brown@hesbynett.no> - 2017-01-09 13:48 +0100
          Re: Stupid design decisions Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-02-08 17:40 -0500
        Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-01-10 21:42 -0600
    Re: Stupid design decisions Tim Wescott <seemywebsite@myfooter.really> - 2017-01-06 15:33 -0600
    Re: Stupid design decisions Ed Prochak <edprochak@gmail.com> - 2017-01-30 12:28 -0800
      Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 13:52 -0700
        Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-01-30 20:55 +0000
          Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 14:18 -0700
            Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-01-30 21:20 +0000
              Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 14:31 -0700
                Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-01-30 23:37 -0600
                  Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 23:20 -0700
                  Re: Stupid design decisions Ed Prochak <edprochak@gmail.com> - 2017-01-30 22:29 -0800
                  Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-31 02:10 -0500
          Re: Stupid design decisions Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-01-30 22:30 +0100
          Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-31 02:00 -0500
        Re: Stupid design decisions Ed Prochak <edprochak@gmail.com> - 2017-01-30 22:18 -0800
          Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 23:36 -0700
          Re: Stupid design decisions jladasky@itu.edu - 2017-01-31 16:01 -0800
            Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-02 09:47 +0000
              Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-02-02 06:35 -0500
                Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 16:26 -0600
                  Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-02-02 19:49 -0500
                    Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 01:27 -0600
                      Re: Stupid design decisions Les Cargill <lcargill99@comcast.com> - 2017-02-03 07:18 -0600
                        Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-03 10:14 -0700
                          Re: Stupid design decisions Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2017-02-03 10:12 -0800
                            Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-03 14:10 -0700
                            Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-04 11:15 +0000
                              Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-04 13:52 -0700
                                Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-02-05 04:36 +0000
                                  Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-04 21:55 -0700
                                    Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-05 21:39 +0000
                                      Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 15:55 -0700
                                        Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-05 23:38 +0000
                                          Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 21:25 -0700
                              Re: Stupid design decisions Les Cargill <lcargill99@comcast.com> - 2017-02-04 17:26 -0600
                                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-04 16:56 -0700
                          Re: Stupid design decisions Les Cargill <lcargill99@comcast.com> - 2017-02-03 21:40 -0600
                            Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-03 21:48 -0700
                        Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-04 11:03 +0000
                          Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-04 13:00 -0700
                            Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 01:49 -0600
                              Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 10:43 -0700
                            Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-05 21:31 +0000
                              Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 15:22 -0700
                                Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-05 23:24 +0000
                                  Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-02-06 03:51 +0000
                                    Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-06 10:11 +0000
                                      Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-02-06 20:07 -0500
                                  Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 21:08 -0700
                  Re: Stupid design decisions mac <acolvin@efunct.com> - 2017-02-04 14:42 +0000
                    Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 02:00 -0600
                      Re: Stupid design decisions Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-05 09:11 +0000
                        Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 03:51 -0600
                        Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 11:10 -0700
                          Re: Stupid design decisions Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-05 22:22 +0000
                            Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 16:01 -0700
                      Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 11:03 -0700
      Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-01-30 23:44 -0600

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#25724

On Mon, 30 Jan 2017 14:31:51 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>> And they always _start_ the chirping in the middle of the night....
>
>Of course!  Or, when the weather is lousy (we don't "stock" spare
>batteries).
>
>Hence the practice of replacing all batteries on New Year's Eve...
>(or, pick some other "memorable day")


Or worse, they start actually going off in the middle of the night for
no reason.

Moved into a new house about 20 years ago, and that winter we had a
run of very cold days in January.  These are wired units, so that the
ones on all three floors go off if there's a problem.  So they start
going off.  For no apparent reason.  I finally figured out that the
(metal) conduit for the upstairs one ran into the attic and was not
insulated.  Enough warm air was flowing up into that conduit in the
-15F attic, that it was generating enough condensation to drip into
the back of the unit (and apparently getting into the sensing
chamber).

It didn't take long to figure out that it was the upstairs detector
going off, and that it seemed to be stuck on (although I had not
isolated the actual cause at the time).  What *really* freaked me out
was that I took the detector from the first floor and moved it
upstairs (figuring one in the basement and one by the bedrooms was a
reasonable partial configuration until I could replace the faulty
one), and then an hour later, *that* one started going off!  At that
point it's "obvious" that there's something going on other than bad
smoke detectors, after all what are the odds that two of them go bad
in a period of a few hours?

Warning systems, and our interaction with them is fraught with
difficulties and dangers.  It reminds me of something that happened to
a Delta (I think) 727 in the 80s.

A flight from Miami to somewhere in the Caribbean (not a long flight)
was proceeding when the oil pressure indicators on one of the engines
dropped to zero.  The crew shut down the problematic engine, and
despite being a bit past the halfway point, turned back to Miami
because of the better facilities (and remember, this was a very short
flight to begin with).  So far nothing really exciting.  On their way
back the oil pressure on a *second* engine drops to zero.  The crew,
of course, says, OK, clearly some issue that's causing the oil
pressure gauges to go wonky, because, what are the odds that you lose
oil pressure on two completely independent engines.  They continue to
head for Miami, they're on the horn with their maintenance base
discussing electrical systems and whatnot, when the oil pressure on
the *third* engine drops to zero.  Which of course just reinforces the
diagnosis of some common fault with the instruments.  Shortly
thereafter one of the two remaining engines (remember the first was
shut down) actually dies.  At which point they had a considerable "Oh
S***!" moment, as they realized that they were flying on a single
engine with no oil in it.  The rest of the event is not really
relevant (the last engine ultimately died, but they managed, after
numerous attempts, to get the first engine restarted, and they, just
barely, dragged themselves to MIA, and everyone was safe).

And how do three completely independent engines all lose oil pressure
at roughly the same time?  Well, it seems the mechanic who serviced
the chip detectors (basically a fancy version of the traditional
magnetic drain plug on your car engine), serviced all three of them,
and neglected to install the same gasket in each when he was
reassembling them.

[toc] | [prev] | [next] | [standalone]

#25727

On 1/30/2017 10:37 PM, Robert Wessel wrote:
> On Mon, 30 Jan 2017 14:31:51 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>>> And they always _start_ the chirping in the middle of the night....
>>
>> Of course!  Or, when the weather is lousy (we don't "stock" spare
>> batteries).
>>
>> Hence the practice of replacing all batteries on New Year's Eve...
>> (or, pick some other "memorable day")
>
> Or worse, they start actually going off in the middle of the night for
> no reason.

Well, there's nothing that can prevent that, a priori.

Thankfully, ours don't seem to "tattle" to their peers when the
battery in one starts to fail.  Doing so would be REALLY annoying!

> Moved into a new house about 20 years ago, and that winter we had a
> run of very cold days in January.  These are wired units, so that the
> ones on all three floors go off if there's a problem.  So they start
> going off.  For no apparent reason.  I finally figured out that the
> (metal) conduit for the upstairs one ran into the attic and was not
> insulated.  Enough warm air was flowing up into that conduit in the
> -15F attic, that it was generating enough condensation to drip into
> the back of the unit (and apparently getting into the sensing
> chamber).

Hmmm... interesting!

> It didn't take long to figure out that it was the upstairs detector
> going off, and that it seemed to be stuck on (although I had not
> isolated the actual cause at the time).  What *really* freaked me out
> was that I took the detector from the first floor and moved it
> upstairs (figuring one in the basement and one by the bedrooms was a
> reasonable partial configuration until I could replace the faulty
> one), and then an hour later, *that* one started going off!  At that
> point it's "obvious" that there's something going on other than bad
> smoke detectors, after all what are the odds that two of them go bad
> in a period of a few hours?

Yeah, I had a disk drive "fail" some years ago.  Had never had a drive
fail up to that point in time so figured my luck had simply run out.

I <frowned>, pulled the drive and replaced it with its "cold spare" -- only
to see the spare fail, immediately, as well.

I can believe *a* drive failing -- but not two (though they were identical
hardware and "content") in the span of a few minutes!

[Driver bug was scrambling the drives' superblocks]

> Warning systems, and our interaction with them is fraught with
> difficulties and dangers.  It reminds me of something that happened to
> a Delta (I think) 727 in the 80s.
>
> A flight from Miami to somewhere in the Caribbean (not a long flight)
> was proceeding when the oil pressure indicators on one of the engines
> dropped to zero.  The crew shut down the problematic engine, and
> despite being a bit past the halfway point, turned back to Miami
> because of the better facilities (and remember, this was a very short
> flight to begin with).  So far nothing really exciting.  On their way
> back the oil pressure on a *second* engine drops to zero.  The crew,
> of course, says, OK, clearly some issue that's causing the oil
> pressure gauges to go wonky, because, what are the odds that you lose
> oil pressure on two completely independent engines.  They continue to
> head for Miami, they're on the horn with their maintenance base
> discussing electrical systems and whatnot, when the oil pressure on
> the *third* engine drops to zero.  Which of course just reinforces the
> diagnosis of some common fault with the instruments.  Shortly
> thereafter one of the two remaining engines (remember the first was
> shut down) actually dies.  At which point they had a considerable "Oh
> S***!" moment, as they realized that they were flying on a single
> engine with no oil in it.  The rest of the event is not really
> relevant (the last engine ultimately died, but they managed, after
> numerous attempts, to get the first engine restarted, and they, just
> barely, dragged themselves to MIA, and everyone was safe).
>
> And how do three completely independent engines all lose oil pressure
> at roughly the same time?  Well, it seems the mechanic who serviced
> the chip detectors (basically a fancy version of the traditional
> magnetic drain plug on your car engine), serviced all three of them,
> and neglected to install the same gasket in each when he was
> reassembling them.

Bad *process*.  There's a reason you have different ways of
verifying things in hi-rel systems (so the process -- or its sole
author/implementor -- doesn't become the "single point of failure").
Same reason the original author never proofreads his work!

[toc] | [prev] | [next] | [standalone]

#25728

On Tuesday, January 31, 2017 at 12:37:02 AM UTC-5, robert...@yahoo.com wrote:
> On Mon, 30 Jan 2017 14:31:51 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
> 
> >> And they always _start_ the chirping in the middle of the night....
> >
> >Of course!  Or, when the weather is lousy (we don't "stock" spare
> >batteries).
> >
> >Hence the practice of replacing all batteries on New Year's Eve...
> >(or, pick some other "memorable day")
> 
Halloween for me. Fall, before the furnace starts really getting used.
> 
> Or worse, they start actually going off in the middle of the night for
> no reason.
> 
> Moved into a new house about 20 years ago, and that winter we had a
> run of very cold days in January.  These are wired units, so that the
> ones on all three floors go off if there's a problem.  So they start
> going off.  For no apparent reason.  I finally figured out that the
> (metal) conduit for the upstairs one ran into the attic and was not
> insulated.  Enough warm air was flowing up into that conduit in the
> -15F attic, that it was generating enough condensation to drip into
> the back of the unit (and apparently getting into the sensing
> chamber).
> 
> It didn't take long to figure out that it was the upstairs detector
> going off, and that it seemed to be stuck on (although I had not
> isolated the actual cause at the time).  What *really* freaked me out
> was that I took the detector from the first floor and moved it
> upstairs (figuring one in the basement and one by the bedrooms was a
> reasonable partial configuration until I could replace the faulty
> one), and then an hour later, *that* one started going off!  At that
> point it's "obvious" that there's something going on other than bad
> smoke detectors, after all what are the odds that two of them go bad
> in a period of a few hours?

Again to make it relevant to C.A.E.:
   All part of the same batch production run?
> 
> Warning systems, and our interaction with them is fraught with
> difficulties and dangers.  It reminds me of something that happened to
> a Delta (I think) 727 in the 80s.
> 
> A flight from Miami to somewhere in the Caribbean (not a long flight)
> was proceeding when the oil pressure indicators on one of the engines
> dropped to zero.  The crew shut down the problematic engine, and
> despite being a bit past the halfway point, turned back to Miami
> because of the better facilities (and remember, this was a very short
> flight to begin with).  So far nothing really exciting.  On their way
> back the oil pressure on a *second* engine drops to zero.  The crew,
> of course, says, OK, clearly some issue that's causing the oil
> pressure gauges to go wonky, because, what are the odds that you lose
> oil pressure on two completely independent engines.  They continue to
> head for Miami, they're on the horn with their maintenance base
> discussing electrical systems and whatnot, when the oil pressure on
> the *third* engine drops to zero.  Which of course just reinforces the
> diagnosis of some common fault with the instruments.  Shortly
> thereafter one of the two remaining engines (remember the first was
> shut down) actually dies.  At which point they had a considerable "Oh
> S***!" moment, as they realized that they were flying on a single
> engine with no oil in it.  The rest of the event is not really
> relevant (the last engine ultimately died, but they managed, after
> numerous attempts, to get the first engine restarted, and they, just
> barely, dragged themselves to MIA, and everyone was safe).
> 
> And how do three completely independent engines all lose oil pressure
> at roughly the same time?  Well, it seems the mechanic who serviced
> the chip detectors (basically a fancy version of the traditional
> magnetic drain plug on your car engine), serviced all three of them,
> and neglected to install the same gasket in each when he was
> reassembling them.

Yup, same batch.

One more reason for me to keep the more expensive new detector.
A couple years newer, different model (though same manufacturer),
and therefore clearly a different batch. 8^)

Oh and it uses 2 doubleA batteries instead of the 9-volt.

ed

[toc] | [prev] | [next] | [standalone]

#25731

On 1/31/2017 12:37 AM, Robert Wessel wrote:
>
> And how do three completely independent engines all lose oil pressure
> at roughly the same time?  Well, it seems the mechanic who serviced
> the chip detectors (basically a fancy version of the traditional
> magnetic drain plug on your car engine), serviced all three of them,
> and neglected to install the same gasket in each when he was
> reassembling them.

Pretty scary, no?  Now, consider that nuclear power plants are subject 
to that exact same sort of single point of failure mechanism.  I've 
mentioned this in a couple newsgroups before, but I don't think I've 
mentioned it here.  The North Anna nuclear power station in Virginia was 
hit by an earthquake a few years ago.  The station shut down and cut off 
from the outside power.  Six diesel generators start up to power the 
cooling water pumps.  After 15 or 20 minutes one engine fails.  When 
they later analyzed what happened they found the head gasket was 
installed incorrectly because... the installation *procedure* was 
written incorrectly.

That easily could have resulted in *all* the generators failing and both 
reactors in the power plant turning into another Fukushima.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#25722

Am 30.01.2017 um 21:55 schrieb Grant Edwards:

> The problem is I don't know which of the half-dozen of them is upset.

That stops being a problem once you realize that it doesn't really 
matter which of them is the first to go.  As soon as the first of them 
complains, you replace _all_ their batteries, preferably with a batch of 
same-model batteries, from the same shop, with equal date stamps.

After the first round of this, all the batteries are the same type and 
age, so when the first one goes, all the others will likely go soon 
enough after that they best be replaced right away, too.

Or to put it into terms more applicable to c.a.e.: globally forced 
synchronization avoids the problems of asynchronous, spatially 
distributed event sources.

[toc] | [prev] | [next] | [standalone]

#25730

On 1/30/2017 3:55 PM, Grant Edwards wrote:
> On 2017-01-30, Don Y <blockedofcourse@foo.invalid> wrote:
>> On 1/30/2017 1:28 PM, Ed Prochak wrote:
>>
>>> BIG ONE: detector companies, PLEASE change the low battery
>>> signal to something more easily located!!!
>>
>> People KNOW where their smoke detectors are located.
>
> The problem isn't that I don't know where the smoke detectors are.
> The problem is I don't know which of the half-dozen of them is upset.
>
> This could be solved easily with an LED...

I've had exactly the same problem.  I have two new units and I guess 
enough time had gone by that one battery needed replacement.  The two 
units are on two levels open to a common cathedral ceiling room.  I 
could not tell which unit was the problem.  I thought taking the battery 
out would make the noise go away and tell me which battery needed 
replacing, but it seems they have a rather large backup cap so that even 
without the battery they would continue to chirp every 10 minutes.  What 
a PITA.

I'm not sure how an LED would help.  You'd have to be looking at it when 
it went off.  Rather they need to do what one of my very old units did - 
it had a button to test the warning buzzer.  If you pressed that when 
the battery was low, it would also sound the chirp or something like 
that.  Too bad that unit went bad a decade ago.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#25726

On Monday, January 30, 2017 at 3:52:58 PM UTC-5, Don Y wrote:
> On 1/30/2017 1:28 PM, Ed Prochak wrote:
> > So together we investigate, and After a few chirps,
> > we manage to locate the culprit. Under a dust tarp,
> > on a shelf, is one of the old smoke detectors that
> > I removed over three years ago!!!
> 
> Yeah, I spent some time the other day chasing down what was obviously
> an "alarm clock".  Apparently, only rings for a minute or two, then
> self-resets.  So, if you're not in the garage (which is where it was,
> sitting in a pile of items to be recycled) when it goes off, you'd
> never know!
> 
> I figure I've just saved the folks at the recycling plant a hassle or two!
> 
> > So two rants:
> >
> > BIG ONE: detector companies, PLEASE change the low battery
> > signal to something more easily located!!!
> 
> People KNOW where their smoke detectors are located.

I had TWO detectors: one smoke, one CO, located about 12 feet apart
with the furnace in between and a shelf in between. And I could not
tell which was chhirping!

>  The goal
> of the alarm in the detector is to be as loud and annoying as
> possible.

I said NOTHING about the alarm. Comon Don you are better than that.

> 
> > Small one: Batteries obviously last more than one year!
> 
> Of course!  You can buy detectors with non-replaceable batteries
> (the entire detector is discarded after 10 years)

You couldn't do that twenty years ago when that old detctor
was installed.
> 
> > (but I am still replacing them yearly, better safe than cheap.)
> 
> Yup.  It also gives you a reminder to test the thing and remind
> yourself what it sounds like when it sounds off (ours are
> combination units so the alarms for smoke and Co are different).
> As well as testing the interconnect -- to make sure ALL sound
> when *any* sounds!

yes our smoke detectors are interconnected, which is another reason
I kept the combo smoke/CO detector. And knowing the old CO detector
was likely still okay, I put it in the garage. (I don't use my
fireplace much any more.)
> 
> > End of story.
> 
> A $60 leson you will undoubtedly not need to repeat!  :>

I hope so, but my brain gets so overloaded from work wsometimes
that I cannot guarantee it.  8^)

Enjoy,
  ed

[toc] | [prev] | [next] | [standalone]

#25729

On 1/30/2017 11:18 PM, Ed Prochak wrote:
> On Monday, January 30, 2017 at 3:52:58 PM UTC-5, Don Y wrote:
>> On 1/30/2017 1:28 PM, Ed Prochak wrote:
>>> So together we investigate, and After a few chirps,
>>> we manage to locate the culprit. Under a dust tarp,
>>> on a shelf, is one of the old smoke detectors that
>>> I removed over three years ago!!!
>>
>> Yeah, I spent some time the other day chasing down what was obviously
>> an "alarm clock".  Apparently, only rings for a minute or two, then
>> self-resets.  So, if you're not in the garage (which is where it was,
>> sitting in a pile of items to be recycled) when it goes off, you'd
>> never know!
>>
>> I figure I've just saved the folks at the recycling plant a hassle or two!
>>
>>> So two rants:
>>>
>>> BIG ONE: detector companies, PLEASE change the low battery
>>> signal to something more easily located!!!
>>
>> People KNOW where their smoke detectors are located.
>
> I had TWO detectors: one smoke, one CO, located about 12 feet apart
> with the furnace in between and a shelf in between. And I could not
> tell which was chhirping!

As I've mentioned before, you need a range of frequencies to localize most
sound sources.

Listen to a cricket, chirping ENDLESSLY in a room.  You can wander around
until you are exhausted and still not deterministically identify its
location -- you have to hope to SPOT it or otherwise stumble across it.

>>  The goal
>> of the alarm in the detector is to be as loud and annoying as
>> possible.
>
> I said NOTHING about the alarm. Comon Don you are better than that.

There is one "annunciator" in the device.  It is chosen to be
"as loud and as annoying as possible".  The designers didn't add
a *second* device just to help you locate a "bad battery"!

>>> Small one: Batteries obviously last more than one year!
>>
>> Of course!  You can buy detectors with non-replaceable batteries
>> (the entire detector is discarded after 10 years)
>
> You couldn't do that twenty years ago when that old detctor
> was installed.

Yes, but older detectors tended to eat batteries at a higher rate.
So, you wouldn't typically plan on it *lasting* more than a year.

>>> (but I am still replacing them yearly, better safe than cheap.)
>>
>> Yup.  It also gives you a reminder to test the thing and remind
>> yourself what it sounds like when it sounds off (ours are
>> combination units so the alarms for smoke and Co are different).
>> As well as testing the interconnect -- to make sure ALL sound
>> when *any* sounds!
>
> yes our smoke detectors are interconnected, which is another reason
> I kept the combo smoke/CO detector. And knowing the old CO detector
> was likely still okay, I put it in the garage. (I don't use my
> fireplace much any more.)

We have gas heat (and hot water) so CO is a possible "normal
occurrence" -- if something "goes wrong" with an appliance.

Here, CO detectors are contraindicated in garages!  I guess
the fear is one of "false alarms".  I've been looking for a
suitable "temperature sensor" for the furnace room as most
other detectors are ill-advised, there.

[Apparently, a lot of the places you'd think would be prime
locations for smoke and CO detectors are "not advised"]

>>> End of story.
>>
>> A $60 leson you will undoubtedly not need to repeat!  :>
>
> I hope so, but my brain gets so overloaded from work wsometimes
> that I cannot guarantee it.  8^)

You need to find pleasant diversions!  :>  I spent most of today wading
through piles of recycled equipment:  "Gee, I wonder what THIS is?
And, what is it supposed to do??"  (Had two friends in surgeries and
knew I would need something to act as a diversion lest I "waste" the
day worrying about them!)

[Managed to "find" a hand tool another friend had misplaced a week or two
ago thereby earning her ebullient gratitude.  Always fun to watch a woman
*jump* for joy!  ;)  And, both friends appear to have come through their
surgeries well, so... A Good Day!]

[toc] | [prev] | [next] | [standalone]

#25732

On Monday, January 30, 2017 at 10:18:58 PM UTC-8, Ed Prochak wrote:

> I had TWO detectors: one smoke, one CO, located about 12 feet apart
> with the furnace in between and a shelf in between. And I could not
> tell which was chhirping!

Yes, that's a real problem that I have also experienced.  The very short chirp of a smoke detector, when it echoes off a bare wall or floor (I still have acoustical "oatmeal" ceilings in my house), can be harder to locate than you might imagine.

I used to have only one smoke detector in the whole house.  It was easy then.  When we remodeled two bathrooms, the city's code inspector came through and made us add a LOT of detectors.  Including the carbon monoxide sensor, now I have nine of them!

[toc] | [prev] | [next] | [standalone]

#25733

In article <bbf94f2b-607b-4fa0-8e7c-d0a7a59d19fa@googlegroups.com>, 
jladasky@itu.edu says...
> 
> On Monday, January 30, 2017 at 10:18:58 PM UTC-8, Ed Prochak wrote:
> 
> > I had TWO detectors: one smoke, one CO, located about 12 feet apart
> > with the furnace in between and a shelf in between. And I could not
> > tell which was chhirping!
> 
> Yes, that's a real problem that I have also experienced.  The very 
> short chirp of a smoke detector, when it echoes off a bare wall or 
> floor (I still have acoustical "oatmeal" ceilings in my house), can be 
> harder to locate than you might imagine.
> 
> I used to have only one smoke detector in the whole house.  It was easy 
> then.  When we remodeled two bathrooms, the city's code inspector came 
> through and made us add a LOT of detectors.  Including the carbon 
> monoxide sensor, now I have nine of them!

What they need is a latching elctromechanical like I have on some RCD 
outlets, where by you have a small hole/window through which you
can view something solid which has two colour labels like Red and Green
so you can inspect if necessary with a torch.

That way even if the battery has died completely it can be SEEN if
battery is OK or not on that unit.

You still inspect the however many but you

  Don't have to wait for chirrup

  CAn see if battery is completely dead

  Can regularly inspect status

  If clever enough can show battery fault because someone has removed
  the battery to satisfy inspection regimes.

Still have chirrup to say battery going but quicker to find the actual
one.

-- 
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

[toc] | [prev] | [next] | [standalone]

#25734

On 2/2/2017 4:47 AM, Paul wrote:
> In article <bbf94f2b-607b-4fa0-8e7c-d0a7a59d19fa@googlegroups.com>,
> jladasky@itu.edu says...
>>
>> On Monday, January 30, 2017 at 10:18:58 PM UTC-8, Ed Prochak wrote:
>>
>>> I had TWO detectors: one smoke, one CO, located about 12 feet apart
>>> with the furnace in between and a shelf in between. And I could not
>>> tell which was chhirping!
>>
>> Yes, that's a real problem that I have also experienced.  The very
>> short chirp of a smoke detector, when it echoes off a bare wall or
>> floor (I still have acoustical "oatmeal" ceilings in my house), can be
>> harder to locate than you might imagine.
>>
>> I used to have only one smoke detector in the whole house.  It was easy
>> then.  When we remodeled two bathrooms, the city's code inspector came
>> through and made us add a LOT of detectors.  Including the carbon
>> monoxide sensor, now I have nine of them!
>
> What they need is a latching elctromechanical like I have on some RCD
> outlets, where by you have a small hole/window through which you
> can view something solid which has two colour labels like Red and Green
> so you can inspect if necessary with a torch.
>
> That way even if the battery has died completely it can be SEEN if
> battery is OK or not on that unit.
>
> You still inspect the however many but you
>
>   Don't have to wait for chirrup
>
>   CAn see if battery is completely dead
>
>   Can regularly inspect status
>
>   If clever enough can show battery fault because someone has removed
>   the battery to satisfy inspection regimes.
>
> Still have chirrup to say battery going but quicker to find the actual
> one.

I think this would be a great application for a spot of eInk if they can 
make it cheaply enough.  That stuff takes a bit of power to change, but 
holds its state for a long time with no power.  It would only need a 
quarter inch square or maybe a simple logo showing the battery dead.  A 
battery with the slashed circle over it would do I suppose.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#25735

On Thu, 2 Feb 2017 06:35:38 -0500, rickman <gnuarm@gmail.com> wrote:

>On 2/2/2017 4:47 AM, Paul wrote:
>> In article <bbf94f2b-607b-4fa0-8e7c-d0a7a59d19fa@googlegroups.com>,
>> jladasky@itu.edu says...
>>>
>>> On Monday, January 30, 2017 at 10:18:58 PM UTC-8, Ed Prochak wrote:
>>>
>>>> I had TWO detectors: one smoke, one CO, located about 12 feet apart
>>>> with the furnace in between and a shelf in between. And I could not
>>>> tell which was chhirping!
>>>
>>> Yes, that's a real problem that I have also experienced.  The very
>>> short chirp of a smoke detector, when it echoes off a bare wall or
>>> floor (I still have acoustical "oatmeal" ceilings in my house), can be
>>> harder to locate than you might imagine.
>>>
>>> I used to have only one smoke detector in the whole house.  It was easy
>>> then.  When we remodeled two bathrooms, the city's code inspector came
>>> through and made us add a LOT of detectors.  Including the carbon
>>> monoxide sensor, now I have nine of them!
>>
>> What they need is a latching elctromechanical like I have on some RCD
>> outlets, where by you have a small hole/window through which you
>> can view something solid which has two colour labels like Red and Green
>> so you can inspect if necessary with a torch.
>>
>> That way even if the battery has died completely it can be SEEN if
>> battery is OK or not on that unit.
>>
>> You still inspect the however many but you
>>
>>   Don't have to wait for chirrup
>>
>>   CAn see if battery is completely dead
>>
>>   Can regularly inspect status
>>
>>   If clever enough can show battery fault because someone has removed
>>   the battery to satisfy inspection regimes.
>>
>> Still have chirrup to say battery going but quicker to find the actual
>> one.
>
>I think this would be a great application for a spot of eInk if they can 
>make it cheaply enough.  That stuff takes a bit of power to change, but 
>holds its state for a long time with no power.  It would only need a 
>quarter inch square or maybe a simple logo showing the battery dead.  A 
>battery with the slashed circle over it would do I suppose.


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.

[toc] | [prev] | [next] | [standalone]

#25736

On 2/2/2017 5:26 PM, Robert Wessel wrote:
> On Thu, 2 Feb 2017 06:35:38 -0500, rickman <gnuarm@gmail.com> wrote:
>
>> On 2/2/2017 4:47 AM, Paul wrote:
>>> In article <bbf94f2b-607b-4fa0-8e7c-d0a7a59d19fa@googlegroups.com>,
>>> jladasky@itu.edu says...
>>>>
>>>> On Monday, January 30, 2017 at 10:18:58 PM UTC-8, Ed Prochak wrote:
>>>>
>>>>> I had TWO detectors: one smoke, one CO, located about 12 feet apart
>>>>> with the furnace in between and a shelf in between. And I could not
>>>>> tell which was chhirping!
>>>>
>>>> Yes, that's a real problem that I have also experienced.  The very
>>>> short chirp of a smoke detector, when it echoes off a bare wall or
>>>> floor (I still have acoustical "oatmeal" ceilings in my house), can be
>>>> harder to locate than you might imagine.
>>>>
>>>> I used to have only one smoke detector in the whole house.  It was easy
>>>> then.  When we remodeled two bathrooms, the city's code inspector came
>>>> through and made us add a LOT of detectors.  Including the carbon
>>>> monoxide sensor, now I have nine of them!
>>>
>>> What they need is a latching elctromechanical like I have on some RCD
>>> outlets, where by you have a small hole/window through which you
>>> can view something solid which has two colour labels like Red and Green
>>> so you can inspect if necessary with a torch.
>>>
>>> That way even if the battery has died completely it can be SEEN if
>>> battery is OK or not on that unit.
>>>
>>> You still inspect the however many but you
>>>
>>>   Don't have to wait for chirrup
>>>
>>>   CAn see if battery is completely dead
>>>
>>>   Can regularly inspect status
>>>
>>>   If clever enough can show battery fault because someone has removed
>>>   the battery to satisfy inspection regimes.
>>>
>>> Still have chirrup to say battery going but quicker to find the actual
>>> one.
>>
>> I think this would be a great application for a spot of eInk if they can
>> make it cheaply enough.  That stuff takes a bit of power to change, but
>> holds its state for a long time with no power.  It would only need a
>> quarter inch square or maybe a simple logo showing the battery dead.  A
>> battery with the slashed circle over it would do I suppose.
>
>
> 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.

That's gotta jack up the price.  Isn't a smoke detector still in the $20 
ballpark?  I guess they can put a raspberry pi zero in for only $5.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#25737

On Thu, 2 Feb 2017 19:49:27 -0500, rickman <gnuarm@gmail.com> wrote:

>On 2/2/2017 5:26 PM, Robert Wessel wrote:
>> On Thu, 2 Feb 2017 06:35:38 -0500, rickman <gnuarm@gmail.com> wrote:
>>
>>> On 2/2/2017 4:47 AM, Paul wrote:
>>>> In article <bbf94f2b-607b-4fa0-8e7c-d0a7a59d19fa@googlegroups.com>,
>>>> jladasky@itu.edu says...
>>>>>
>>>>> On Monday, January 30, 2017 at 10:18:58 PM UTC-8, Ed Prochak wrote:
>>>>>
>>>>>> I had TWO detectors: one smoke, one CO, located about 12 feet apart
>>>>>> with the furnace in between and a shelf in between. And I could not
>>>>>> tell which was chhirping!
>>>>>
>>>>> Yes, that's a real problem that I have also experienced.  The very
>>>>> short chirp of a smoke detector, when it echoes off a bare wall or
>>>>> floor (I still have acoustical "oatmeal" ceilings in my house), can be
>>>>> harder to locate than you might imagine.
>>>>>
>>>>> I used to have only one smoke detector in the whole house.  It was easy
>>>>> then.  When we remodeled two bathrooms, the city's code inspector came
>>>>> through and made us add a LOT of detectors.  Including the carbon
>>>>> monoxide sensor, now I have nine of them!
>>>>
>>>> What they need is a latching elctromechanical like I have on some RCD
>>>> outlets, where by you have a small hole/window through which you
>>>> can view something solid which has two colour labels like Red and Green
>>>> so you can inspect if necessary with a torch.
>>>>
>>>> That way even if the battery has died completely it can be SEEN if
>>>> battery is OK or not on that unit.
>>>>
>>>> You still inspect the however many but you
>>>>
>>>>   Don't have to wait for chirrup
>>>>
>>>>   CAn see if battery is completely dead
>>>>
>>>>   Can regularly inspect status
>>>>
>>>>   If clever enough can show battery fault because someone has removed
>>>>   the battery to satisfy inspection regimes.
>>>>
>>>> Still have chirrup to say battery going but quicker to find the actual
>>>> one.
>>>
>>> I think this would be a great application for a spot of eInk if they can
>>> make it cheaply enough.  That stuff takes a bit of power to change, but
>>> holds its state for a long time with no power.  It would only need a
>>> quarter inch square or maybe a simple logo showing the battery dead.  A
>>> battery with the slashed circle over it would do I suppose.
>>
>>
>> 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.
>
>That's gotta jack up the price.  Isn't a smoke detector still in the $20 
>ballpark?  I guess they can put a raspberry pi zero in for only $5.


The combination smoke+CO alarms seem to be more in the $40-60 range.
The Nest Protect (smoke+CO+WiFi) is $99.

One of complaints about the whole IoT thing is not that I disbelieve
people are going to put WiFi (or something) ports on the back of
billions of items (I'm certain they are), it's that they'll be able to
charge big markups for something like that.  I'm pretty sure I won't
pay $99 for a smoke/CO2 detector.  So I suspect that we will have
billions of IoT devices, but the average BOM for the "IoT" bit is
going to be well under a dollar.

[toc] | [prev] | [next] | [standalone]

#25738

Robert Wessel wrote:
> On Thu, 2 Feb 2017 19:49:27 -0500, rickman <gnuarm@gmail.com> wrote:
>
>> On 2/2/2017 5:26 PM, Robert Wessel wrote:
>>> On Thu, 2 Feb 2017 06:35:38 -0500, rickman <gnuarm@gmail.com> wrote:
>>>
>>>> On 2/2/2017 4:47 AM, Paul wrote:
>>>>> In article <bbf94f2b-607b-4fa0-8e7c-d0a7a59d19fa@googlegroups.com>,
>>>>> jladasky@itu.edu says...
>>>>>>
>>>>>> On Monday, January 30, 2017 at 10:18:58 PM UTC-8, Ed Prochak wrote:
>>>>>>
>>>>>>> I had TWO detectors: one smoke, one CO, located about 12 feet apart
>>>>>>> with the furnace in between and a shelf in between. And I could not
>>>>>>> tell which was chhirping!
>>>>>>
>>>>>> Yes, that's a real problem that I have also experienced.  The very
>>>>>> short chirp of a smoke detector, when it echoes off a bare wall or
>>>>>> floor (I still have acoustical "oatmeal" ceilings in my house), can be
>>>>>> harder to locate than you might imagine.
>>>>>>
>>>>>> I used to have only one smoke detector in the whole house.  It was easy
>>>>>> then.  When we remodeled two bathrooms, the city's code inspector came
>>>>>> through and made us add a LOT of detectors.  Including the carbon
>>>>>> monoxide sensor, now I have nine of them!
>>>>>
>>>>> What they need is a latching elctromechanical like I have on some RCD
>>>>> outlets, where by you have a small hole/window through which you
>>>>> can view something solid which has two colour labels like Red and Green
>>>>> so you can inspect if necessary with a torch.
>>>>>
>>>>> That way even if the battery has died completely it can be SEEN if
>>>>> battery is OK or not on that unit.
>>>>>
>>>>> You still inspect the however many but you
>>>>>
>>>>>   Don't have to wait for chirrup
>>>>>
>>>>>   CAn see if battery is completely dead
>>>>>
>>>>>   Can regularly inspect status
>>>>>
>>>>>   If clever enough can show battery fault because someone has removed
>>>>>   the battery to satisfy inspection regimes.
>>>>>
>>>>> Still have chirrup to say battery going but quicker to find the actual
>>>>> one.
>>>>
>>>> I think this would be a great application for a spot of eInk if they can
>>>> make it cheaply enough.  That stuff takes a bit of power to change, but
>>>> holds its state for a long time with no power.  It would only need a
>>>> quarter inch square or maybe a simple logo showing the battery dead.  A
>>>> battery with the slashed circle over it would do I suppose.
>>>
>>>
>>> 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.
>>
>> That's gotta jack up the price.  Isn't a smoke detector still in the $20
>> ballpark?  I guess they can put a raspberry pi zero in for only $5.
>
>
> The combination smoke+CO alarms seem to be more in the $40-60 range.
> The Nest Protect (smoke+CO+WiFi) is $99.
>

Hasn't Google essentially savaged Nest already? I just read a thing
about it a year or so back and wrote the entire line off.

> One of complaints about the whole IoT thing is not that I disbelieve
> people are going to put WiFi (or something) ports on the back of
> billions of items (I'm certain they are),


Yeauuuugh....

> it's that they'll be able to
> charge big markups for something like that.  I'm pretty sure I won't
> pay $99 for a smoke/CO2 detector.  So I suspect that we will have
> billions of IoT devices, but the average BOM for the "IoT" bit is
> going to be well under a dollar.
>

In quantity, there's no reason to think the prices wound diverge that
much. It's just that the deployment case for IoT devices isn't that
clear because you have to then have other infrastructure in place. Just
putting the SSID on all the lightbulbs in the house sounds exhausting.

I know that for remote light switches, the IoT version is twice or more
the price of just a non-IoT version, and you have to use a phone to run
'em. I have a few of the non-IoT remote light switches, and they are
at disposable price levels.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#25739

On 2/3/2017 6:18 AM, Les Cargill wrote:
>> The combination smoke+CO alarms seem to be more in the $40-60 range.
>> The Nest Protect (smoke+CO+WiFi) is $99.
>
> Hasn't Google essentially savaged Nest already? I just read a thing
> about it a year or so back and wrote the entire line off.

Sounds familiar.  But, other players are entering the market for
other, more traditional, reasons.  (AFAICT, Google wanted a beachhead
to gather more "intelligence" about the customer; they might now have
realized that this is not the way to do so -- "media consumption"
is probably a more effective mechanism)

>> One of complaints about the whole IoT thing is not that I disbelieve
>> people are going to put WiFi (or something) ports on the back of
>> billions of items (I'm certain they are),
>
> Yeauuuugh....
>
>> it's that they'll be able to
>> charge big markups for something like that.  I'm pretty sure I won't
>> pay $99 for a smoke/CO2 detector.  So I suspect that we will have
>> billions of IoT devices, but the average BOM for the "IoT" bit is
>> going to be well under a dollar.
>
> In quantity, there's no reason to think the prices wound diverge that
> much.

For *wireless* devices, I imagine the cost difference will approach
zero.  "Quantity" is A Really Big Number for these sorts of devices.

> It's just that the deployment case for IoT devices isn't that
> clear because you have to then have other infrastructure in place. Just
> putting the SSID on all the lightbulbs in the house sounds exhausting.

The real issue is a lot bigger than the (physical) infrastructure
and "initial configuration".  These can all be addressed to minimize
their practical and virtual costs (TCO).

> I know that for remote light switches, the IoT version is twice or more
> the price of just a non-IoT version, and you have to use a phone to run
> 'em. I have a few of the non-IoT remote light switches, and they are
> at disposable price levels.

Exactly.  There have been numerous attempts at "remote control"
(even if "remote" is limited to just another room in the house)
over the decades.  None have "stuck" -- "remote control" isn't
worth much.

And, its a cognitive loading issue.

Think of what its like when you approach a bank of 4 light switches.
Even if you KNOW which switch controls which "light", there is an
inherent pause as your mind sorts out which light it *wants* to
illuminate/extinguish.

Now, put EVERY "switch" (control/sensor) in your house on a 5" diagonal
screen.  It's easier to WALK to the switch in question and  toggle it
than it is to drag out your phone, FIND the control for THAT
switch, inspect the current state of the "device/light" and
toggle it as appropriate.  Then, hope you NOTICE the fact that
someone else has turned it on in the time following -- but preceding
when you retire for the evening ("Ah, better check the lights again
to see which ones are on *NOW*...")

Yeah, you may find use for the feature if you live alone and want
to keep the indoor temperature, lighting, etc. in a "deep sleep"
sort of state until JUST before you return home from work/whatever.
But, it's unlikely that you'll want to do much more than "turn
the heat up" before heading home.  Or, turn on the spa so it is up
to temperature before you need it.

And, not likely that your schedule will vary significantly from
day to day that this couldn't be automated (minimizing the value
of "remote control").  What if you FORGET??

Scant few of us live in homes that are so large that it's easier
(more convenient) to open an app to verify that the garage door
is closed vs. just walking over to someplace where you can
directly/indirectly observe its state.

[toc] | [prev] | [next] | [standalone]

#25740

On 02/03/2017 09:14 AM, Don Y wrote:

 > [snip IOT stuff
>
> Yeah, you may find use for the feature if you live alone and want
> to keep the indoor temperature, lighting, etc. in a "deep sleep"
> sort of state until JUST before you return home from work/whatever.
> But, it's unlikely that you'll want to do much more than "turn
> the heat up" before heading home.  Or, turn on the spa so it is up
> to temperature before you need it.
>
> And, not likely that your schedule will vary significantly from
> day to day that this couldn't be automated (minimizing the value
> of "remote control").  What if you FORGET??
>

My $20 Honeywell thermostat already does a fixed schedule.  If I happen 
to be out a couple hours later than expected, the heat turns on a couple 
hours before I get home and it's just fine.

> Scant few of us live in homes that are so large that it's easier
> (more convenient) to open an app to verify that the garage door
> is closed vs. just walking over to someplace where you can
> directly/indirectly observe its state.

Built myself one of those.  The key realization is that, it's not 
whether I want to know whether the garage door is open or closed, I just 
want it to be closed.  An MSP430, a burglar alarm switch, and half a 
dozen discretes sip little enough power that I can run the whole thing 
off of the power the door opener runs to the pushbutton on the wall.  If 
it's been open too long, it gets closed.  No Internet/app/nonsense required.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

[toc] | [prev] | [next] | [standalone]

#25741

On 2/3/2017 11:12 AM, Rob Gaddi wrote:
> On 02/03/2017 09:14 AM, Don Y wrote:
>
>> [snip IOT stuff
>>
>> Yeah, you may find use for the feature if you live alone and want
>> to keep the indoor temperature, lighting, etc. in a "deep sleep"
>> sort of state until JUST before you return home from work/whatever.
>> But, it's unlikely that you'll want to do much more than "turn
>> the heat up" before heading home.  Or, turn on the spa so it is up
>> to temperature before you need it.
>>
>> And, not likely that your schedule will vary significantly from
>> day to day that this couldn't be automated (minimizing the value
>> of "remote control").  What if you FORGET??
>
> My $20 Honeywell thermostat already does a fixed schedule.  If I happen to be
> out a couple hours later than expected, the heat turns on a couple hours before
> I get home and it's just fine.

Our HVAC needs are highly variable.  Today, we're running the ACbrrr;
last week, the heat.  Other times we may call on the evaporative cooler
one day and the ACbrrr the next.

This is complicated by our "dynamic" (heh heh heh) lifestyles -- its hard
to predict when the house will be occupied, when its occupants will be
asleep vs. active, etc.

Old thermostat supported two schedules (weekday & weekend) for heating and
another two for cooling.  But, if Monday's needs differ from Thursday,
there's no way to compensate (beyond "manual").  And, if THIS Monday
differs from NEXT Monday...  <frown>

>> Scant few of us live in homes that are so large that it's easier
>> (more convenient) to open an app to verify that the garage door
>> is closed vs. just walking over to someplace where you can
>> directly/indirectly observe its state.
>
> Built myself one of those.  The key realization is that, it's not whether I
> want to know whether the garage door is open or closed, I just want it to be
> closed.  An MSP430, a burglar alarm switch, and half a dozen discretes sip
> little enough power that I can run the whole thing off of the power the door
> opener runs to the pushbutton on the wall.  If it's been open too long, it gets
> closed.  No Internet/app/nonsense required.

I'd be pissed if our garage door opted to close itself.  I rarely carry keys on
my person.  And, often exit the house through the garage door (which may have
been open because I just drove home, or SWMBO just departed, or I was carting
the recyclables out, etc.) to visit with a neighbor (I'm within sight of the
door so not likely someone will sneak into the house while it remains open).

Or, to do some yardwork in the front yard.

OTOH, if the current occupants of the house have retired (regardless of time
of day), then, chances are, the door should be closed.  Likewise, if the
door was *commanded* closed but that action aborted (because something
was detected in the path of travel *or* the motor load sense tripped),
then we should be alerted to this fact and, if the day passes without
us noticing it, the door should probably close itself (or attempt to
do so), later.

There are lots of similar "what if's" in a typical home.  What if the
house is unoccupied (or occupants "indisposed") but the stovetop is ON?
Or, the water supply to the washing machine?  Or, the porch light still
burning despite the sun being up?  Or...

Being *able* to control each of those things doesn't necessarily
result in a better "life experience".

[toc] | [prev] | [next] | [standalone]

#25745

In article <o72h3q$uad$1@dont-email.me>, 
rgaddi@highlandtechnology.invalid says...
> 
> On 02/03/2017 09:14 AM, Don Y wrote:
> 
>  > [snip IOT stuff
> >
> > Yeah, you may find use for the feature if you live alone and want
> > to keep the indoor temperature, lighting, etc. in a "deep sleep"
> > sort of state until JUST before you return home from work/whatever.
> > But, it's unlikely that you'll want to do much more than "turn
> > the heat up" before heading home.  Or, turn on the spa so it is up
> > to temperature before you need it.
> >
> > And, not likely that your schedule will vary significantly from
> > day to day that this couldn't be automated (minimizing the value
> > of "remote control").  What if you FORGET??
> >
> 
> My $20 Honeywell thermostat already does a fixed schedule.  If I happen 
> to be out a couple hours later than expected, the heat turns on a couple 
> hours before I get home and it's just fine.
> 
> > Scant few of us live in homes that are so large that it's easier
> > (more convenient) to open an app to verify that the garage door
> > is closed vs. just walking over to someplace where you can
> > directly/indirectly observe its state.
> 
> Built myself one of those.  The key realization is that, it's not 
> whether I want to know whether the garage door is open or closed, I just 
> want it to be closed.  An MSP430, a burglar alarm switch, and half a 
> dozen discretes sip little enough power that I can run the whole thing 
> off of the power the door opener runs to the pushbutton on the wall.  If 
> it's been open too long, it gets closed.  No Internet/app/nonsense required.

The real issues with IoT are protocols, security and longeveity.

Protocols I bet every manufacturer has their own 'extensions' to any 
existing protocol.

Security, something like over 90% of products have next to no security
on them, as they had to ship something to keep up with the market.

Longeveity

1/	Will the Wifi band they use still be connectable to easily in 10 
	to 20 years time. Building infrastructure is that and longer time
	scales. How many of you update your light switches as often as
	phones and computers or there OS.

	How many of us have 30+ year old light switches?

	How many of you can easily connect to network 10b2 devices (that 
	is coax 10Mb LAN), they only really disappeared 10 years ago.

2/	In 10 years time, will the company or service provider still be 
	around or absorbed and killed off by someone else ?

3/	In 10 years time will the company or service provider still
	support that range?

4/	In 1 to 2 years when your phone is OS updated or you change
	phones will ALL the apps you require STILL work?

5/	In 5+ years time will the protocols or infrastructure software 
	still be availble, supported or laughed about as it is not
	the newest piece of tat with pretty pictures the salesmen want 
	to sell.

-- 
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

[toc] | [prev] | [next] | [standalone]

#25748

On 2/4/2017 4:15 AM, Paul wrote:
> In article <o72h3q$uad$1@dont-email.me>,
> rgaddi@highlandtechnology.invalid says...
>>
>>> Scant few of us live in homes that are so large that it's easier
>>> (more convenient) to open an app to verify that the garage door
>>> is closed vs. just walking over to someplace where you can
>>> directly/indirectly observe its state.
>>
>> Built myself one of those.  The key realization is that, it's not
>> whether I want to know whether the garage door is open or closed, I just
>> want it to be closed.  An MSP430, a burglar alarm switch, and half a
>> dozen discretes sip little enough power that I can run the whole thing
>> off of the power the door opener runs to the pushbutton on the wall.  If
>> it's been open too long, it gets closed.  No Internet/app/nonsense required.
>
> 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.  The problem is always that an 800
pound gorilla can opt to bend the rules (MS) and coerce designs to adopt
THEIR standards (which they can then freely change -- being 800 pounds has
its prerogatives!) to the dismay of other "players".

> Security, something like over 90% of products have next to no security
> on them, as they had to ship something to keep up with the market.

Agreed.  But, to be fair, I think many folks designing kit are simply
naive as to the risks involved.
    "Why would anyone want to crash your irrigation system?"
    "Who cares as to their motivation!  *I* care that it's
    very expensive to replace all of those plantings because SOMEONE
    came up with a reason to crash it!"
(Why would someone want to commandeer the controls in a moving
automobile, not their own?)

Additionally, even among those wary of the risks, I doubt many have
the skills to actively evaluate the risks and attack surfaces in
their products.  The "components" (e.g., BT stack) are often
well beyond their capabilities and level of education/experience.
(how many folks could write something as "simple" as a four-function
floating point library?)  The same applies to an understanding of the
protocols and their associated risks.

Then, you have to start thinking of more esoteric exploits and vectors.

E.g., with a mass-marketed device, an attacker has all the time in
the world to buy one (or ten) and study its implementation.  Or,
*share* information with other similarly motivated folks.

Once educated, he can scour prospective targets to find folks who
rely on the compromisable (is that even a word?) devices.

Have an IP camera guarding your front door?  Or, an externally mounted
irrigation system?  etc.  Has the installation been hardened to ensure
that compromising one of these accessible nodes doesn't render the system's
security moot?

My neighbor has a home security system.  All of the sensors are wireless
(cuz the business wants to sell a MONITORING SERVICE and, thus, is
interested in keeping the "free installation" costs close to ZERO!).

I'm sure I could figure out who's hardware is being used -- just by
packet sniffing.

Of course, any designer worth his salt wouldn't make such a system
vulnerable to jamming.  So, instead of each sensor reporting
error conditions, the system would undoubtedly poll all sensors,
periodically (i.e., the system would need configuration information
at the time of each installation/modification).

And, to prevent obfuscating a possible alarm report in a polling
interval (by jamming the report from "sensor_FrontDoor"), the "base"
(which is undoubtedly WIRED) would note too many successive polling
errors as a sign of trouble and alarm on that condition.

So, the OBVIOUS attack vectors are covered...

But, if I deliberately start interfering with ONE sensor "often enough"
that its reliability comes into question -- necessitating a replacement
(and service call from vendor!), I can eventually coerce the vendor
or the home occupant to ignore (or disable!) reports from that sensor.
That resource (FrontDoor) is then unprotected -- despite the occupant
PAYING for "whole house protection".

Etc.

[Red/Blue team exercises are delightfully informative!  And, folks
who haven't engaged in them are at a huge disadvantage -- cuz they
are completely clueless as to the number of cracks in their armor!]

> Longeveity
>
> 1/	Will the Wifi band they use still be connectable to easily in 10
> 	to 20 years time. Building infrastructure is that and longer time
> 	scales. How many of you update your light switches as often as
> 	phones and computers or there OS.

With the investment as large as it is (or, "could be"), there would
be forces brought to bear to maintain some compatibility path.  Over
time, the "lagging adopters" would pay increasing premiums to keep
their feet firmly planted in the past -- but, they'd still be able to
buy parts and services (somewhere).

The home I grew up in used a novel "push button" circuit breaker.
Big market, lots of competitors.  Yet, 60 years later, I can still
find a replacement -- if I look REALLY HARD.

> 	How many of us have 30+ year old light switches?
>
> 	How many of you can easily connect to network 10b2 devices (that
> 	is coax 10Mb LAN), they only really disappeared 10 years ago.
>
> 2/	In 10 years time, will the company or service provider still be
> 	around or absorbed and killed off by someone else ?

That isn't important if there are standards in place.  Others can
(will?) step up to offer drop in replacements -- for parts and
services.

> 3/	In 10 years time will the company or service provider still
> 	support that range?
>
> 4/	In 1 to 2 years when your phone is OS updated or you change
> 	phones will ALL the apps you require STILL work?

Vendors have tried to avoid this exposure by sticking to a web interface
to software that THEY maintain (on a server that acts as the "mapping agent"
for their devices in the field).

But, this requires the vendor to maintain that service, indefinitely!

> 5/	In 5+ years time will the protocols or infrastructure software
> 	still be availble, supported or laughed about as it is not
> 	the newest piece of tat with pretty pictures the salesmen want
> 	to sell.

A salesman might laugh or try to coerce you into buying an "iPhone 7".
But, if you resist, he'll still be eager to sell you a replacement
charger for your iPhone 6!

Personally, I imagine much of this kit having a relatively high turnover
rate (exceptions being major appliances -- though even those are moving
to a shorter upgrade cycle).  It's difficult to design consumer kit
cheaply AND reliably -- esp when it sees 24/7/365 duty!

For items that currently see regular replacement (small appliances,
"media players", GDOs, etc.) this will just be reflected by a (possible)
difference in price/installation ease.  The *real* problems will
be the more traditionally "durable" items that rarely see replacement
(e.g., light switches, HVAC kit, etc.).  There, the potential reduction
in durability will be most noticeable:
     "I need a new lightswitch for the bathroom; mine crashed!"

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web