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

Groups > comp.arch.embedded > #25764

Re: Stupid design decisions

Show all headers | View raw

On 2/5/2017 2:39 PM, Paul wrote:
>>> 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.

No, that just limits IoT to "remote control".  I.e., lets you migrate
the user interface, even dynamically.

What IoT promises/suggests is for devices to know how to interoperate
and communicate (with each other!).

I run a rule-based system.  So, I have to write a shitload of rules.
My water heater can't inherently know that it should "sleep" at
certain times of the day (when there will be little/no demand)
and be "prepared" at other times.  The washing machine can't
know that the water heater has been sleeping and, thus, the hot water
available might not be at the required temperature for an effective
wash cycle.  And, neither of them can inherently know that I take showers
at a particular time of day!

So, if I buy IoT enabled appliances, what does it *buy* me?  Maybe
I can drag out my cell phone and command the water heater to raise
its set-point half an hour before I'm ready to step into the
shower?  And, likewise, inhibit the washing machine from running a
wash cycle (unless it wants to use COLD water!) in that same
period lest it compete with the quantity and quality of the hot water
available to me in the shower.

Instead, you want devices that can discover each other AND discover
each other's capabilities.  Then, "discover" the user and adapt their
concerted actions to his benefit!

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

No, that's simply not worth the effort.  Do you *really* care if you
can turn your back porch light on from your desk at work?  Or, check
to see if you've remembered to close the garage door while you're
waiting for your aircraft to depart?

Connectivity ONLY gives you those things.

If a 100-unit hotel/motel has remote enabling of the HVAC in each
individual unit, that (by itself) saves the staff ONE trip to each
room per visit (to turn the HVAC on as the visitor checks in;
household cleaning staff can turn it OFF in their normal course
of duties after he's checked out).

OTOH, if this remote control ABILITY is exploited by an intelligent
AGENT to *stagger* the energy demands for the hotel/motel as a whole
by ensuring that only one subset of the OCCUPIED rooms can draw
on the electricity required to heat/cool their respective rooms
*now*, then the benefits of that remote control are greatly multiplied.

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

Yes, but they're just using it for remote control and monitoring.
The freezers don't "coordinate their use of power" to minimize the
PEAK demand (many electric tariffs are peak-demand-related).
And, when conditions are such that duty-cycle limiting each
individual freezer's power needs leaves one or more freezers unable
to meeting their cooling requirements (hypothetical), do they
know how to *shed* their individual requirements in favor of maintaining
the freezer(s) with the most perishable items?
     "Boy, I had my compressor running for the full timeslice that I've
     been allotted and I *still* can't maintain the desired temperature
     specified for me!  These folks are going to be really upset to
     discover their ICE CREAM is melted..."

     "Yeah, I'm in a similar predicament.  Its a shame to think about
     all the STEAKS that the cafeteria won't be able to serve due to
     spoilage!"

     "You guys think YOU'VE got it bad?  Imagine what happens when the
     hospital staff -- annoyed at having to eat hamburger instead of steak
     and jello instead of ice cream -- discovers that their BLOOD SUPPLY
     is tainted!"

IMO, IoT only has value if the networked devices can then form a
gestalt that adds value beyond their individual values.  That
means having more in the mix than just "connectivity".

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

And the bit of kit that you design to monitor their freezers will
somehow remain supported and compliant?  :>

Any time you adopt/embrace a technology that *is* moving forward, you
risk it CONTINUING to move forward -- at the expense of leaving you behind!

We've been looking at replacing some toilets.  For *decades*, maintaining
a toilet was a no-brainer; the guts had been reasonably standardized
so that even with variations in manufacturing techniques and approaches to
the problem, you'd have affordable options at your corner store.

Now, not so.

While the cost of the fixture isn't much... and, the effort to install
it isn't difficult nor tedious (nor challenging)... it is still not
the sort of decision you want to make lightly and CHANGE if you
choose wrong!

Given that each manufacturer has come up with their own "innards"
for their products, how do you know which manufacturers have made
bad design choices that will bite *you* a year or two down the
line (recall changing toilets isn't something you do on a whim)?
Which will remain viable producers?  Which will *abandon* their
products (because only you and three other j'mokes happened to
buy them)?

*So* much easier/safer when things were static and mature!

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web