Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #25662 > unrolled thread
| Started by | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| First post | 2017-01-05 21:14 -0600 |
| Last post | 2017-01-30 23:44 -0600 |
| Articles | 20 on this page of 70 — 17 participants |
Back to article view | Back to comp.arch.embedded
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 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-02-05 04:36 +0000 |
| Message-ID | <o76a4f$cu$2@reader1.panix.com> |
| In reply to | #25748 |
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. Generally once somebody mentions "IoT" or "Industrie 4.0", I just stop listening... -- Grant
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-02-04 21:55 -0700 |
| Message-ID | <o76b4c$clc$1@dont-email.me> |
| In reply to | #25751 |
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). > 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 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. Beyond the MECHANICS of communication, there's the whole semantic issue -- how do you codify *meaning* across an unconstrained set of devices/applications? 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.
[toc] | [prev] | [next] | [standalone]
| From | Paul <paul@pcserviceselectronics.co.uk> |
|---|---|
| Date | 2017-02-05 21:39 +0000 |
| Message-ID | <MPG.3301ac00cf71b112989816@172.16.0.1> |
| In reply to | #25752 |
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
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-02-05 15:55 -0700 |
| Message-ID | <o78ae0$oeb$1@dont-email.me> |
| In reply to | #25761 |
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!
[toc] | [prev] | [next] | [standalone]
| From | Paul <paul@pcserviceselectronics.co.uk> |
|---|---|
| Date | 2017-02-05 23:38 +0000 |
| Message-ID | <MPG.3301c7c518348ee2989819@172.16.0.1> |
| In reply to | #25764 |
In article <o78ae0$oeb$1@dont-email.me>, blockedofcourse@foo.invalid says... > > 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!). Bluetooth, Zigbee and mesh networks promised 20 years ago. Most of the promises are vapourware. > 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. You are capable of operating that 90% of users are not. > 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! Back to Zigbee and Mesh 20 years ago > >> 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. For 5% of technology adopters who will ever afford these things or even think they need them, until they lose mobile phone coverage. > 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. A lot of hotels use a room cardkey switch to do this already also means only when a VALID user is in the room does anything happen. > >> 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. No many use these things in many ways > The freezers don't "coordinate their use of power" to minimize the > PEAK demand (many electric tariffs are peak-demand-related). All of this is extrapolated vapourware when most cant forecast how much EXTRA their permanent services will use. Most of this is aimed at the 5% technology adopters because it is new with nect to NO standards ... > > 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? :> The important part is monitor as compared to control. If the monitoring system changes or is replaced there is not an issue. As it is the target cost of freezer monitor is less than $20, and the gateway is interchangeable. If it fails other solutions can be found or temporary stop gaps or even people going back to physically measuring temperatures at regular intervals can be used as backup. Most controlled systems are heading to it must be controlled or thrown out on failure. If the controlled or connected system with its proprietary protocols is unsupported more likely the whole freezer has to be replaced and has no backup plan. > 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! Change is inevitable progress is not Many NEW things and CHANGES occur quite a lot are short lived 3D TV, certain Samsung phones classic recent example. -- 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]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-02-05 21:25 -0700 |
| Message-ID | <o78tnp$762$1@dont-email.me> |
| In reply to | #25767 |
On 2/5/2017 4:38 PM, Paul wrote:
> In article <o78ae0$oeb$1@dont-email.me>, blockedofcourse@foo.invalid
> says...
>>
>> 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!).
>
> Bluetooth, Zigbee and mesh networks promised 20 years ago.
> Most of the promises are vapourware.
They all have met their promises. They allow data to move -- but
don't impart any MEANING to that data! E.g., BT profiles lend
some general idea as to the content -- though they don't GUARANTEE
that the content is as expected.
E.g., I can deliver seismographic data over an FTP profile
or an audio profile. And, no device knows how to interpret
that data!
What are the nouns and verbs for a GDO? TV? Doorbell?
Do we create "classes/profiles" for each of these? So,
if you want to "connect" a surveillance camera to a
"doorbell (button)", they will magically KNOW how to
interoperate?
"OK, when someone presses the doorbell button, start
capturing video for 15.37 seconds..."
>> 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.
>
> You are capable of operating that 90% of users are not.
But that's only because I see the interrelationships and am
designing them into the implementation. Someone with more
resources could virtualize all of these interfaces/devices
and concoct an "interface description language" that eliminates
much of this need.
A big part of my design is a scripting language to allow
"average joes" to modify the performance of the system
(either by writing the scripts directly or sourcing them
from others who are more capable in that regard).
The point is the implicit acknowledgement that an IoT
*site* is more than setting a baby monitor by the crib
so you can listen in the kitchen.
>> 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!
>
> Back to Zigbee and Mesh 20 years ago
No. Those don't *know* anything about the semantics of the
messages and data that are being exchanged. They just
handle the lower layers (OSI) of the model.
>>>> 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.
>
> For 5% of technology adopters who will ever afford these things or even
> think they need them, until they lose mobile phone coverage.
So you don't rely on a smart phone for remote control!
E.g., my neighbor can call the house, authenticate herself
and command my garage door closed -- if she notices that I've
left it open "all day". Doesn't need her cell phone or an
internet connection to do so.
I can borrow someone else's phone/payphone and do the same
when I'm away.
>>>> 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.
>
> No many use these things in many ways
>
>> The freezers don't "coordinate their use of power" to minimize the
>> PEAK demand (many electric tariffs are peak-demand-related).
>
> All of this is extrapolated vapourware when most cant forecast how much
> EXTRA their permanent services will use.
>
> Most of this is aimed at the 5% technology adopters because it is new
> with nect to NO standards
There were no standards when automobiles were invented.
There were no standards for DTV just a decade ago.
Technologies need time to mature. IoT is just babble, today.
No one has a "killer app" that is driving the industry. The
Nest thermostat was "cute". But, little more.
"What does this BUY ME that I don't already have?"
>>> 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? :>
>
> The important part is monitor as compared to control.
>
> If the monitoring system changes or is replaced there is not an issue.
> As it is the target cost of freezer monitor is less than $20, and the
> gateway is interchangeable. If it fails other solutions can be found
> or temporary stop gaps or even people going back to physically
> measuring temperatures at regular intervals can be used as backup.
>
> Most controlled systems are heading to it must be controlled or
> thrown out on failure. If the controlled or connected system with its
> proprietary protocols is unsupported more likely the whole freezer has
> to be replaced and has no backup plan.
That's an implementation decision. If I want to safeguard against my
car not starting, I can have a second vehicle, bicycle, hoof-it, etc.
Its a cost-risk-benefit analysis that *I* do. The calculus may
resolve differently for someone with different priorities.
>> 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!
>
> Change is inevitable progress is not
>
> Many NEW things and CHANGES occur quite a lot are short lived 3D TV,
> certain Samsung phones classic recent example.
If a technology ADDS VALUE, it is likely to be persistent -- until
made obsolete by a newer one.
No real value to pet rocks. VCRs had a long run before giving way to
other recording/playback media.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-02-04 17:26 -0600 |
| Message-ID | <o75nmp$3ig$2@dont-email.me> |
| In reply to | #25745 |
Paul wrote: > In article <o72h3q$uad$1@dont-email.me>, <snip> > > 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. > If I have to actually consider the security of something, then that is a strong indicator that it should be done without. <snip> -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-02-04 16:56 -0700 |
| Message-ID | <o75pkk$9lm$2@dont-email.me> |
| In reply to | #25749 |
On 2/4/2017 4:26 PM, Les Cargill wrote: > Paul wrote: >> In article <o72h3q$uad$1@dont-email.me>, > <snip> >> >> 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. > > If I have to actually consider the security of something, then > that is a strong indicator that it should be done without. Lock on the front door of your house? Automobile? etc. [You *do* understand that many newer cars are easily vulnerable to hacking their door locks -- and other features]
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-02-03 21:40 -0600 |
| Message-ID | <o73i7k$1hs$1@dont-email.me> |
| In reply to | #25739 |
Don Y wrote:
> 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)
>
I don't are what their problem is. They've rendered themselves low in
reliability because of it.
>>> 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.
>
Possibly.
>> 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.
>
I use it for lamps that are behind furniture and hard to get to. It's
fine. I think three outlets were $20.
They're crappy - I turned off a power strip with one still on,
and it roasted it. You have to turn the light off with the remote switch
before removing power. But they're simple enough you could
probably fix it.
> 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.
Yep, yep, yep.
> 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*...")
>
But I could see where an "Alexa, check the lights for me" thing might
help with that.
> 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.
It's anything but clear that that will save money, and by extension
anything else. Charging a big thermal mass always costs more
than keeping it regulated.
> 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.
I've gotten to where I sort of checklist everything so it's in a known
state before it goes out of my sight. But it's not that far to walk to
the garage.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-02-03 21:48 -0700 |
| Message-ID | <o73mcb$dlu$1@dont-email.me> |
| In reply to | #25742 |
On 2/3/2017 8:40 PM, Les Cargill wrote:
> Don Y wrote:
>> 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)
>
> I don't are what their problem is. They've rendered themselves low in
> reliability because of it.
IMO, this is the problem with the trend towards "selling services"
and "ongoing relationships" -- instead of just selling a PRODUCT
that has a defined functionality (that can be assessed at time of
purchase).
>> 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*...")
>
> But I could see where an "Alexa, check the lights for me" thing might help with
> that.
Yes -- but now you're looking for an *agent* -- who acts on your
behalf. Not just an extension of the "power cord".
>> 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.
>
> It's anything but clear that that will save money, and by extension
> anything else. Charging a big thermal mass always costs more
> than keeping it regulated.
That depends on what else impacts that mass. Surely, if I'm going to
be out of the house during the peak cooling load -- but *returning*
just as outdoor temperatures become "more reasonable" -- then it
is silly to try to maintain the house at a cool/comfortable
temperature and humidity throughout the day when I could QUICKLY
bring it to a comfortable setting just by venting the house to the
cooler evening air.
Likewise, silly to maintain the indoor temperature overnight
(in winter) at a "comfortable for waking uses" level when you
can, instead, bring the house up to that temperature in a
matter of minutes (GFA).
Do you keep the house illuminated when unoccupied? etc.
>> 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.
>
> I've gotten to where I sort of checklist everything so it's in a known
> state before it goes out of my sight. But it's not that far to walk to
> the garage.
You're *capable* of making that "short trip" as well as REMEMBERING
to make it!
If you'd a physical/mental disability/deficiency, that might not be
the case. How do you verify the doors are all closed AND LOCKED
without physically inspecting them? The lights off without examining
them? The stove/oven off, etc.
I have a pot of water HEATING on the stove almost continually to
address my "hot tea" habit. It's so "automatic" that I forget
whether or not the stovetop is ON, presently -- or not. I
rely on a "whistling" tea kettle to alert me to the fact:
"Ah, I must have left the stove on cuz I can hear the kettle
whistling..."
Frequently, I'll hear the kettle when not expecting it -- simply
because I put it on and then wandered off to continue my
current activity, got preoccupied with that activity and was
only reminded of the kettle by the subsequent "whistle".
So common is this that my "checklist" before driving away from the
house is:
- verify garage door has been closed and has ACTUALLY closed
- make sure the stovetop is off!
Being able to remotely examine these states and/or control them
only addresses part of the problem; if I *FORGET* to examine
them "locally", am I really more likely to examine them
REMOTELY?? Wouldn't it be wiser for an AGENT to notice that
I've left the house and take corrective actions on my behalf?
[toc] | [prev] | [next] | [standalone]
| From | Paul <paul@pcserviceselectronics.co.uk> |
|---|---|
| Date | 2017-02-04 11:03 +0000 |
| Message-ID | <MPG.32ffc5744663f9ea989813@172.16.0.1> |
| In reply to | #25738 |
In article <o71vmm$qm1$1@dont-email.me>, lcargill99@comcast.com says... > > Robert Wessel wrote: > > On Thu, 2 Feb 2017 19:49:27 -0500, rickman <gnuarm@gmail.com> wrote: .... > > 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. The real issue there is the insistence that every IoT device MUST be Wifi ! 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. If you have a MAINS connected device don't use Wifi use the Mains wiring you already have to talk yo your base station. -- 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]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-02-04 13:00 -0700 |
| Message-ID | <o75bqe$n0q$1@dont-email.me> |
| In reply to | #25744 |
On 2/4/2017 4:03 AM, Paul wrote: > In article <o71vmm$qm1$1@dont-email.me>, lcargill99@comcast.com says... >> >> Robert Wessel wrote: >>> On Thu, 2 Feb 2017 19:49:27 -0500, rickman <gnuarm@gmail.com> wrote: > .... > >>> 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. > > The real issue there is the insistence that every IoT device MUST be > Wifi ! They don't. My home is all PoE wired/powered. But, the costs (DM+DL) for doing so are considerably higher than a wireless approach. And, it doesn't lend itself well to "old construction". OTOH, there literally aren't enough receptacles to plug in all of these devices if each was wall-wart powered! > 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.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-05 01:49 -0600 |
| Message-ID | <k4md9cppavb0005dh5lldcmsb0lsr4vobf@4ax.com> |
| In reply to | #25747 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-02-05 10:43 -0700 |
| Message-ID | <o77o3r$ine$1@dont-email.me> |
| In reply to | #25753 |
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")
[toc] | [prev] | [next] | [standalone]
| From | Paul <paul@pcserviceselectronics.co.uk> |
|---|---|
| Date | 2017-02-05 21:31 +0000 |
| Message-ID | <MPG.3301a9f1af63c5b1989815@172.16.0.1> |
| In reply to | #25747 |
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
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2017-02-05 15:22 -0700 |
| Message-ID | <o788ft$i7l$1@dont-email.me> |
| In reply to | #25760 |
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)
[toc] | [prev] | [next] | [standalone]
| From | Paul <paul@pcserviceselectronics.co.uk> |
|---|---|
| Date | 2017-02-05 23:24 +0000 |
| Message-ID | <MPG.3301c48472f545fb989818@172.16.0.1> |
| In reply to | #25763 |
In article <o788ft$i7l$1@dont-email.me>, blockedofcourse@foo.invalid
says...
>
> 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.?
Anyone doing that and relying on the machine to work out their shopping
list is asking for a DISASTER
Just because someone has cheapest milk does not mena you
ACTUALLY need any the same or more than last time
For fridge at home you have had 6 visistors for a few days your
milk consumption went up for that period, you do not need the same
amount for next week. Or are on holiday for two weeks or out of
town for 2 days.
There are two many variables that have to be input even into a
shopping list for forthcoming events.
ALL the fridge needs to tell you you is
I am working efficiently (no faults)
Impending failures (pump not operating smoothly
possible door seal issue, not reaching temperature)
Fridge is cooling for thermal mass inside and
the DIFFERENT types of items that need to be at
DIFFERENT temperatures.
Current temperature is ....
Power failure ocurred at xx temp rose to yy at zz
Power restored.. after xx time temp was yy restored to zz
at ... (decision can only be made depending on contents)
Putting other things inside to scan barcodes and weigh EACH item
or similar to work out actual usage makes the fridge too expensive.
Just because you take milk out of fridge does not mean you actually used
some because you got called away before putting milk in coffee or tea.
So just returned the milk to the fridge.
Putting other sensors inside to monitor each item or even doing image
analysis, is making a gold plated fridge with technology that will be
ignored. Just like do I need a light switch to tell me the mains
voltage, frequency, the value of the dimmer setting on the panel of the
switch this is Big REDUNDANT and WASTED data.
Shopping list criteria is not what should be processed by the fridge
> 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.
Why does every device have to stream elsewhere?
Then you get confusion about do I stream from the microwave, oven,
washing machine, fridge, blender, HVAC....
More tat multi-function products that are gone like 3D TV in a few years
> > 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.
Of stupid ideas
> Or, are you willing to redefine the devices to be allowed to
participate
> on your IoT network?
That for 90% of users becomes too confusing and leaves the security
issues open again.
For 90% of users a microwave is a microwave
> > 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?
There are always outliers
Adding filters or clamps to supply at local electricity supplier point
is not difficult and can often be done by clamp ferrites. Actually has
always been the recommeded practice over here. As it is the pairing
between two premises needs co-operation of both parties.
If others are using mains for distribution of signals there will always
be an issue.
If using Wifi there will be MORE places with issues, from poor coverage
due to building construction, and growing congestion of wifi users in
one location by multitude of devices then you have to move to a
different band and oh please update your IoT to new band and hope they
will work.
> 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.
You are part of the 5% of high technology adopters, the vast majority of
the public are NOT, The vast majority in connected countries do not have
the budgets for adding all this.
The simple fridge, light switch etc is all they can afford.
> 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)
The number of housholds I have seen adopt IP audio streams in this
country and my small area with some high spenders is TWO, and one of
them regretted putting it in with all the different protocols,
connectivity issues and subscriptions.
> And the VoIP service? etc.
Number of users over here of VoIP outside commercial use is small as
they use their mobile phones, and then in home the phone over wifi.
Why are you trying to combine an IoT network with a data network. That
is like combining the water and electricity.
Leave the data network on wifi as for most folks it is better separate
Put the infrastructure and IoT on different network completely with
gateway. That is how I see it deployed effectively for industrial,
commercial and domestic right now.
Your infrastructure network has to be more permanent than your data
network that is subject to fads and random changes from your internet
provider change of wifi, change of ISP.
> 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).
Hence infrastruce IoT on mains as the majority of units need to
connected to mains anyway.
Data networks over existing cable/wifi
I know of plenty of functioning IoT, remote monitoring etc in CURRENT
use that split the IoT network of sensors etc into its own network
then use gateway to conect to internet, have used wifi but now going to
ethernet from gateway to routers. They do NOT use wifi for the IoT to
gateway. This is ACTUAL products in COMMERCIAL use.
> As with storage NEEDS increasing to fill the available disk SPACE, I
> expect bandwidth requirements to fill the available bandwidth.
Only if you try to
a) mix them
b) make every IoT device like a phone able to browse the web etc
c) Actually think ONE Thing must be able to do all things at once
> 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)
Only if you try to make IoT devices all must use the same network as
data services. This is the COMMON mistake of IoT manufacturers NOW.
Basically the greedy practice of all apps, devices, computer addons
software package from manufacturers
"They have bought our xxxxx and that is ALL they use"
When the manufacturers of a lot of tat products remember their product
is part of the mix, different things should be on different
infrastructure for many reasons.
--
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]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2017-02-06 03:51 +0000 |
| Message-ID | <o78rss$4hb$1@reader1.panix.com> |
| In reply to | #25766 |
On 2017-02-05, Paul <paul@pcserviceselectronics.co.uk> wrote: > Anyone doing that [...] is asking for a DISASTER Um, it's the IoT. I thought that was the point. -- Grant
[toc] | [prev] | [next] | [standalone]
| From | Paul <paul@pcserviceselectronics.co.uk> |
|---|---|
| Date | 2017-02-06 10:11 +0000 |
| Message-ID | <MPG.33025c3e51f742fe98981b@172.16.0.1> |
| In reply to | #25768 |
In article <o78rss$4hb$1@reader1.panix.com>, invalid@invalid.invalid says... > > On 2017-02-05, Paul <paul@pcserviceselectronics.co.uk> wrote: > > > Anyone doing that [...] is asking for a DISASTER > > Um, it's the IoT. I thought that was the point. Most of it beoomes LoT (Lawyer of Things, as soon as it involves connectivity to '"cloud" or servers as you then have to understand fully all the Levels of Service and contract terms. Just hope the nroadband link does not fail. -- 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]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-06 20:07 -0500 |
| Message-ID | <o7b6hl$2s1$1@dont-email.me> |
| In reply to | #25775 |
On 2/6/2017 5:11 AM, Paul wrote: > In article <o78rss$4hb$1@reader1.panix.com>, invalid@invalid.invalid > says... >> >> On 2017-02-05, Paul <paul@pcserviceselectronics.co.uk> wrote: >> >>> Anyone doing that [...] is asking for a DISASTER >> >> Um, it's the IoT. I thought that was the point. > > Most of it beoomes LoT (Lawyer of Things, as soon as it involves > connectivity to '"cloud" or servers as you then have to understand fully > all the Levels of Service and contract terms. > > Just hope the nroadband link does not fail. Can you say "indemnification"? For some reason indemnification has become universal in terms and conditions of Internet web sites. Once in awhile you will find one that either doesn't include this requirement or limits it to entirely reasonable conditions such as your violation of the law. But 99% of web sites require you to indemnify them against "any claim or demand, including reasonable attorneys' fees, made by any third party due to or arising out of Content you submit, post, transmit, modify or otherwise make available through the Yahoo Services, your use of the Yahoo Services, your connection to the Yahoo Services, your violation of the TOS, or your violation of any rights of another." for example. Notice the clause, "your use of the Yahoo Services". You don't have to do anything wrong. You just have to be related to the claim. I've even seen terms that refer to your "alleged" breach of the terms of conditions or laws. So nothing has to be proven. IoT will be run by lawyers and terms like these. -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web