On 2/5/2017 4:24 PM, Paul wrote:
> In article <o788ft$i7l$1@dont-email.me>, blockedofcourse@foo.invalid
> 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".
>>>>
>>>> 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
Who said it was going to "work out" their shopping list? You're assuming that
providing hints and guidance based on observation is worth NOTHING!
> Just because someone has cheapest milk does not mena you
> ACTUALLY need any the same or more than last time
Refrigerator doesn't have to tell you that you *need* it but,
rather, that your recent usage habits suggest you consider it.
And, by noting that it is ON SALE this week (at store X), this
knowledge THAT IT GATHERED ON YOUR BEHALF might bias your
choices as to what to purchase this week.
As is shown, below, there are lots of (INEXPENSIVE) ways that the refrigerator
can KNOW what's likely "needed"
> 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.
See above. You've made specious assumptions regarding what the
refrigerator has to do and why.
If I handed my grocery receipts for the past 4 weeks to a 10 year
old child and asked him what I should buy THIS week, wanna bet he'll
be pretty close to knowing what is needed? WITHOUT opening the
refrigerator!
I.e., the fact that the refrigerator compiles this list is
arbitrary; the irrigation controller could just as easily!
But, one tends to associate food with refrigerators so...
> 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)
So, once every N *years* the refrigerator "adds value" to
offset the costs of conveying this information. And, you
consider that sufficient to justify adding components
for that purpose?
> 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)
So, you'r expecting the user to be involved in that decision
making process, right?
You might want to look at what appliance vendors are actually doing.
Of course, you can assume they are all idiots and have no idea of
the needs of THEIR CUSTOMERS. *Or*, you can might come to the
realization that they see where their customers are headed and
are trying to figure out how to get there.
> 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.
Boy, I can see why YOU'd be a poor choice for this sort of task! :>
Imagine a device -- an appliance... say, a REFRIGERATOR -- that is aware
of your purchases. Maybe even items that AREN'T STORED IN THE APPLIANCE
(e.g., toilet paper, cleaning supplies, condoms, etc.). Perhaps it scans
sales receipts fed into it. Or, accesses records of your purchases
"on-line". Or, by querying a "shopping list" app that you used on
your smartphone.
It does this every day for its entire life. It sees EVERYTHING (though
that isn't essential).
How long would it take for it to "notice" that you buy a gallon of milk
EVERY WEEK? Or, that it has been 13 weeks since you bought that megapack
of toilet paper and, based on HISTORICAL OBSERVATIONS, you are probably
due to buy another, RSN (note: no need for the "toilet-tender accessory"!).
A "motivated" youngster could look at our recent purchases and come to
similar conclusions.
[We buy a package of pork tenderloins every 8 weeks. And, have done so for
> 10 years as it is a key ingredient in one of our favorite meals. The
tenderloins are not stored in the refrigerator but, instead, in the freezer.
Tell me when we last purchased them and I can tell you how many are left
in the freezer, without going out there to visually verify.]
Even if we don't need pork (yet), a device could notice that pork
tenderloins are ON SALE this week (and, sales tend to only be for a week
or shorter) and SUGGEST the purchase to us:
"You aren't due to need pork for 3 more weeks; but, it is on sale THIS
WEEK at a significant savings!"
OTOH, if they are GIVING AWAY *tongue* (or other organ meats), we're simply
not interested. And, the device can be reasonably certain of that
conclusion because it has NEVER seen us make such a purchase!
If the device has a display (e.g., touchscreen common nowadays), it
could simply present a list of the items that we purchased most
recently as a reminder to us -- and let us "check off" the items
that we want to repurchase THIS week.
Or, add a PTT switch (push-to-talk) to the door handle so, as you are
peering inside the refrigerator, you can depress the switch and
state: "We need milk". Voice recognition software can take HOURS
to process this audio and correlate likely results with likely terms
(i.e., if "bilk" and "milk" are likely candidates, "milk" is PROBABLY
the correct one -- as it is essentially a limited domain application!
Not often that you purchase "aardvark"!) If the audio is unrecognizable,
it can be preserved in its native form and PLAYED for the user -- either
when the user "downloads" the shopping list *or* included as part of
the download to the smartphone:
Grocery list:
Milk (on sale for $1.59 at Foodbarn)
Salami
Pork tenderloins (two remain)
* Click here for audio list of other items not listed, here
Do we HAVE to buy these items -- and ONLY these items? Of course not.
OTOH, letting the machine "remember" removes the need for manually
inspecting contents (of freezer, refrigerator, toilet paper cache, etc.).
There's three "solutions" -- none of which require weighing contents,
scanning barcodes, vision recognizers, etc.
> 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.
Refrigerators already have cameras in them so you can look inside
your refrigerator without opening the door.
Or, do so from work.
When SWMBO purchased her most recent vehicle, it came with an "automatic
liftgate". I thought this was silly. "Gold plating". I made her aware
of my opinion and she concurred. But, the rest of the vehicle fit her
needs so we just shrugged and figured it was "extra cost" but tolerable.
It didn't take long to realize it was probably one of the MOST useful
features for her -- as she loads the back of the car almost daily with
items that would be tedious to fetch from the back seat.
Point is, you never really KNOW what customers will find useful.
Arbitrarily deciding something is "gold plating" may cost you a
sale (she now comments about how glad she is that she did NOT
purchase a competing vehicle that didn't have that feature!)
> Shopping list criteria is not what should be processed by the fridge
You're right! The TOASTER should handle it! :>
>> 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?
How does the display on the microwave get it's content so you
can watch the local news broadcast while preparing dinner?
How does the TV in the living room get its internet GAME feed?
They all need to access the network infrastructure in order to
access the material that it makes available.
> Then you get confusion about do I stream from the microwave, oven,
> washing machine, fridge, blender, HVAC....
You are streaming *to* the microwave. The front of the microwave being
"prime real estate" for a smallish "TV", data terminal, etc. Would
you rather park a laptop on the kitchen counter so you can check on
your email while making your morning coffee? Or, look at the day's
weather forecast to help determine what you might want to wear?
Or, traffic reports to be forewarned of accidents and construction
detours that you may have forgotten?
Kinda hard to watch a movie/newscast on a blender...
<http://www.samsung.com/us/explore/family-hub-refrigerator/>
> 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
Apparently, manufacturers are interested enough to commit millions of
dollars in research and product development to these ideas. *You*
might not want one but, obviously, they think *someone* does! And,
they are in that business -- so, presumably, have SOME idea of
what THEIR CUSTOMERS are likely to want!
Sony took the "pocket transistor radio" and replaced it with
a "pocket cassette player" and convinced everyone that they needed
them! (walkman)
Your cell phone carrier spends a fair bit convincing you that you
NEED a new phone every couple of years -- despite the fact that
you probably had your original land line set for 30-40 years
without feeling "inadequate".
[You wouldn't be foolish enough to actually CARRY A PHONE, would you?]
>> 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.
Security is an orthogonal issue. When I add an IoT-ish device to my network,
I "introduce" it to the administrative station -- a dedicated network
connection in the equipment closet (i.e., physical security). There, private
keys are installed in the device and its identity recorded with "The System".
Thereafter, when it is connected to a particular network drop (that *I*
select), The System recognizes its location and knows how to encrypt the
traffic to *it* -- without fear of any other device being able to
masquerade as that device *or* command/monitor it. No fear of a user
selecting "PaS5W0rD" or "SexSexSex" or "asdfg". Keys can be long AND
change frequently. And, as the device is in constant communication
with the system, if it "disappears" (because an adversary wants to
reverse engineer the silicon on the device), The System can mark it
as "untrusted".
This is possible because *I* have adopted a standard for how devices
will talk to the system. When the IoT world gets smart, they will
do something comparable.
> For 90% of users a microwave is a microwave
And, for 90% of drivers, a car doesn't need a backup camera.
Or, something to tell them when another vehicle is in their blind spot.
Or, cruise control that senses when they are creeping up on the car
in front of them.
Or, a lift gate/side door that opens/closes itself.
Yet, when folks USE those things, they suddenly decide they were
*worth* the additional cost.
Predicting what people WON'T want is always likely to leave one surprised.
Pet rock, anyone?
>>> 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.
So, just *you* are allowed to use it? Do the neighbors get together and take
a vote?? Or, maybe each neighbor gets to use the mains for a week before
moving on to the next neighbor? Does the guy on the other side of the
wall separating your apartments have a say?
> 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.
So *don't* use a shared medium! D'uh!
Those alternatives are ways of avoiding cabling costs. There are
tradeoffs with all things -- you don't get "ease of connection"
without some consequences!
Every device, here, is wired. That includes the "appliances" as
well as servers/workstations/laptops. As a result, I can ensure that
only devices that should talk to each other CAN talk to each other
despite sharing a common switch.
Spend a week in our guest bedroom with your laptop and all the malware
you can muster -- and you won't be able to talk to ANYTHING in the house
(even though I can give you unfettered access to The Internet!)
Most of my nodes would be hard pressed to gain access to AC mains.
And, virtually ALL of them would "look clumsy" having power cords
running off to the nearest UNUSED outlet -- instead of siting them
where they BELONG.
I have 10 speakers mounted up near (or in) the ceiling. Should I
install receptacles /way up there/ to make the mains accessible to
each of them? What will the next homeowner think/do when he opts
not to have devices sited up there? Just put a cover over the
Jbox and blush each time a guest asks "Why do you have those
blank plates way up near the ceiling?"
>> 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.
So, who is buying these IP thermostats, IP cameras, irrigation systems,
baby monitors, doorlocks, wall switches/outlets, security systems, etc.?
There are increasing numbers of products being offered. And, not in the
"upscale in-flight magazines" but, rather, in home stores, hardware stores,
etc. So, the people who make those types of products -- including
LEGACY PLAYERS -- have obviously decided there is a market.
> The simple fridge, light switch etc is all they can afford.
... until the cost of adding these options falls to a point where NOT having
having them is more costly than having them.
Icemakers used to be optional equipment. I don't think I know anyone
who *doesn't* have one. And, most folks have "in door" ice AND WATER
dispensers!
>> 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.
Because the market is not mature. You have "islands of automation".
Anything you buy is a crap-shoot as to whether it will work with
anything else that is offered next year!
I know dozens of people who use media tanks to serve their audio and
video content. The DVD players replaced by tiny devices that just
act as network taps, "stereos" replaced by "music over wifi" to little
portable speakers that they place wherever they want the music.
When our DVD player died, we replaced it with a small (USFF) PC.
I can replace DVD drives in PC's for far less money than a
consumer DVD player!
And, I can let the PC do double-duty as a DVR.
>> 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.
VoIP is increasingly popular, here. Land-lines are obsolescent
so their ISP effectively gives them phone access. (We've been
exploring this option as well).
Cell phone users use their cellular providers at home.
> Why are you trying to combine an IoT network with a data network. That
> is like combining the water and electricity.
Why not? Do you power your lights from RED electricity and your
other appliances from BLUE electricity? Do you have different
receptacles for different appliances?
Do you only drive on CAR roadways -- unless you're driving a TRUCK
(in which case, you drive on the TRUCK roadway?)
Data is data. Do you really think your VoIP provider is sending
your voice stream over different wires than your on-demand video
stream? And, your web traffic on a THIRD set of wires?
> 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.
So, if I want to listen to music on my laptop, I have to install a
bridge that lets that content flow from the IoT network to the
"data" network? Should my IoT devices be prohibited from accessing
The Internet? And, likewise, prohibit access FROM the Internet?
(then what's the point of having them accessible remotely -- if you
won't let them be accessed remotely?)
Should there be some special mechanism that lets my IoT TV access
the Netflix service FROM THE IoT network -- even though Netflix
is hosted on the (DATA) Internet?
>> 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
Needless duplication of effort. And, an arbitrary partitioning of
capabilities that need not be thus:
"You're an appliance; you aren't allowed to talk to The Internet"
or:
"You're an appliance; when you talk to the Internet, you have to
use this OTHER mechanism cuz you're not as GOOD as a computer!"
(appliance envy!)
> 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
Why should they NOT be mixed?
> b) make every IoT device like a phone able to browse the web etc
Who says EVERY device needs to be able to browse the web? You,
OTOH, are deciding that NOTHING should need that capability.
Will you then be inventing proxies to run on the COMPUTERS
(which CAN access the internet) and a conveyance to port that
information to the IoT devices? What happens when the computer
needs to be replaced or the hosting OS is no longer available?
> c) Actually think ONE Thing must be able to do all things at once
Why not? Why shouldn't your irrigation system be able to check
the local weather forecast? Why should some COMPUTER have to do that
as its proxy -- and then transfer the information to the irrigation
system? Now, TWO devices need to be involved (and understand the
syntax, etc.) in that acquisition task.
Why shouldn't a refrigerator be able to research your grocery choices
this week (cuz it sees that every Monday you HAVE RETURNED from grocery
shopping and, today being Sunday -- gee, how did I know that? -- it
should take the initiative BEFORE you need it!)? Or, note that
there is a report of tainted broccoli florets that seems to match
the broccoli florets that you purchased last week?
Why shouldn't your car determine when you need an oil change -- instead
of relying on you to watch the time/mileage (but be fuzzy on the
actual *wear* that the car sees in that interval)? Or, note that a
recall notice has been posted for its S/N?
Why shouldn't the motorized skylight be able to see that it is
raining and, thus, best close itself? Or, the blinds close themselves
to keep the sun out when it is low in the sky?
Why shouldn't your "internet radio" be able to fetch a podcast
in which it thinks you might have an interest -- based on the previous
podcasts that you've PASSED THROUGH IT?
>> 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.
IoT manufacturers don't talk to anything besides themselves. They
don't have a broad range of product offerings. How many are ESTABLISHED
light switch, TV, kitchen appliance, GDO, AND etc. manufacturers? THAT
is the common mistake made, now. Not *how* they do that talking!
Choice of interconnect technology only affects how easily the device
can be adopted -- not WHETHER it will be adopted.
Which Company X wants to take a risk on interfacing to Company Y's similar
IoT kit -- without assurances that Company Y's products will see widespread
adoption?
IoT vendors are looking for the "killer app" or "beachhead appliance"
that gets them in the door. But, as their offerings are pricey and
cumbersome -- AND their "bench" isn't very deep -- they aren't
able to generate any buying inertia.
What does the $200 IoT thermostat afford me that my $20 "setback"
thermostat doesn't? Why will I want an IoT irrigation system
just because I bought an IoT thermostat?
> 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.
>