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
Stupid design decisions
Started by ●January 5, 2017
Reply by ●February 4, 20172017-02-04
Reply by ●February 4, 20172017-02-04
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
Reply by ●February 4, 20172017-02-04
> There are also a number of smoke detectors that are (or can be) > Internet connected. Many of those also avoid the need for wires to > interconnect multiple detectors in a house.Because, what could go wrong?
Reply by ●February 4, 20172017-02-04
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.
Reply by ●February 4, 20172017-02-04
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!"
Reply by ●February 4, 20172017-02-04
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
Reply by ●February 4, 20172017-02-04
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]
Reply by ●February 5, 20172017-02-05
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
Reply by ●February 5, 20172017-02-05
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.
Reply by ●February 5, 20172017-02-05
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.
