Cloud? IoT? How to start

[snip]

IFTTT? MQTT?

Are those the kinds of things you're looking for?

Before you go ANY further read this short article and think about security first

Yes it is a long link but in some ways it is funny

IoT and Cloud is just naming some random collection of protocols that have existed before.

There is a cartoon/meme you can find out there

"There is no cloud it is just somebody else's computer"

Which is why I refer to IoT as LoT (Lawyer of Things)

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk 
    PC Services 
   Logic Gates  
Education  
  Raspberry Pi Add-ons 
 Timing Diagram Font 
 For those web sites you hate

IoT:

Take a bunch of small devices with no need for internet access. Add internet access with tons of security holes. Set up some dodgy web sites and write some broken smartphone apps to talk to the "things".

Cloud:

Put all your data on somebody else's computer and let _them_ lose it.

--
Grant Edwards               grant.b.edwards        Yow! I have many CHARTS 
                                  at               and DIAGRAMS.. 
                              gmail.com

Is this 'learn' as in 'understand how all the layers work' or 'learn' as in 'pick tool X and learn its API'?

In the former case I suggest installing a VM system, eg Xen, KVM, HyperV or ESXi, and then spinning up some VMs on that. Then, proceed to play with some of the containerisation and high availability tools on top of your VM(s).

All of this is hidden behind APIs like AWS and App Engine. You can pick those up by jumping in at their API level, but it helps to understand what is going on underneath them. In particular, the API is typically vendor-specific - fine if you don't mind being tied to that vendor, less good if you want to pick the right tool for each job.

If this is a product, maybe picking a platform is the way to go to make progress fast - but you should expect to throw the initial version away as you learn what the platform does and doesn't allow you to do.

For the specific case of IoT, the field is still developing; that means there are no 'obvious' front runners as far as services go - it also means that anyone you pick has a risk they shutter the project when they go bust or move onto the next thing. That's why there's something to be said for building your own - if you have the skills. Of course, your customers are still at risk that /you/ go bust.

Theo

IoT doesn't require access to The Internet. Remember, *an* internet just refers to them being able to talk (i.e., to each other).

As to whether they *need* that ability... that depends on the functionality you want to give them. Does your automobile *need* a radio? heater? etc.?

A closed internet is less vulnerable than one that extends into *the* Internet.

*Or*, let them extract whatever THEY consider to be of value for their own needs/gains -- often implicitly at *your* expense! (of course, they will try to convince you that this is to your *benefit* using some perverse logic)

Many cars *do* need the radio ... to perform ignition key/fob code verification. Pull the stereo in the new car and see if it still starts 8-).

For many autos, an after-market stereo upgrade has to leave the old unit connected, powered, and buried in the dash because removing it disables the vehicle.

George

you know of a new car that has a stereo that will pull out?

tim

I'm not sure *where* the hardware and software functionality for the fob-related features resides (haven't purchased a workshop manual, yet; I've been forbidden from tinkering with it until the warranty expires! :> ).

I know there are near-field sensors in each of the driver/passenger doors (approximately) as it will only unlock the corresponding door if *a* fob is sensed in its proximity (I think 37 inches?) as the handle is touched. I assume the same driver-side fob-sensor is used to enable the ignition. I.e., with both of us in the front seat, roughly equidistant from the START button and each carrying a fob, it recognizes which of us is actually *in* the driver's seat and selects that driver's profile (seat position, mirror settings, GPS/phone/stereo settings, etc.)

Likewise, rear hatch won't raise unless a fob similarly detected, there.

"Remote" function will work over reasonably long distances (a block or so?).

And, "dead battery fallback" only operates within an inch or two of the START button.

Don't know if the Sirius "upgrade" is a hardware upgrade, software upgrade or just a bit that enables a feature. Of course, AM/FM require a real radio.

GPS obviously does, as well. As does the "concierge" service (or whatever it is called). And, the BT link to the phone. Hard to imagine

*all* of those using a shared set of hardware.

(E.g., I'd imagine there's more than just an "antenna" in each door sensor; easier to ship a packet of digital data to something that decides whether or not to unlock the doors)

On earlier vintage of this model, the radio/stereo could be *replaced*. Lots of online docs about locating the "code" to enable the radio's functionality (anti-theft). You'd think that if it disabled the car from starting, the questions would be ""I removed my stereo and now my car won't start..."

It's generally clearer to refer to "an inTRAnet".

IoT is largely "control things with your phone". That doesn't necessarily mean using the larger Internet but it's semi-implied that it does. Somewhere around the third person who uses it will expect that.

Yep.

--
Les Cargill

The Internet is AN internet. What you call an intranet is likewise. Would you say IoT was an acronym for Intranet-of-Things? *And* Internet-of-Things? (i.e., the important aspect is that the devices are internetworked, not that they can talk to The Internet.

No, that's just how it is currently marketed. How do you "control" your refrigerator with your phone? It may, however, monitor what you've placed in and removed from it. Or, let you visually examine its contents without opening the door. But, none of that requires The Internet. Or, a phone.

I pretty much have more IoT kit, here, than most homes in the country. Yet, I don't rely on The Internet for *any* of it! (OTOH, I can access and control most of it using a voice channel via the PSTN)

I know someone who is marketing a product where much of the processing is done in the "cloud". He feels that somehow this will make the software immune from ever needing to be ported as OS revisions change and hardware is upgraded. Really? Is that really possible? At some point won't the environment hosting software require maintenance no matter what your host is (assuming they upgrade on a regular basis)?

--

Rick C

The key is to have everything specified in terms of an API, and to program against that API and only that API. A good API is far more valuable than any implementation.

It can make it a lot easier, /provided/ the architecture and implementation are /very/ carefully thought through. The poster child proof-of-concepts are the telecom system and Amazon Web Services.

None of which changes the concept that cloud processing is the triumphant re-invention of timesharing systems, and that it means your data and processing is done on machines owned by another company.

I remember the relief people felt when IBM PCs arrived, because then they were no longer held hostage by the timesharing bureaux.

Over here Siemens is advertising their household appliances by the remote control features :-)

After all, the Stuxnet exploit was first used on Siemens systems :-)

Beats me. If it's an interpreted language, then perhaps - although they seem to have more tools thrash.

--
Les Cargill

Look, I'm just trying to get terminology that is inherently clearer. You can call it food if you want to. :)

An inTRAnet can often lack a backhaul to the larger world. Since that fits what you described...

--
Les Cargill

Right, and at home he's got a paddock full of unicorns that fart rainbows.

As long as the hosting company never changes anything (or goes out of business), hardware never fails, software never needs security updates, protoocols never change, requirements never change, and so on.

IOW, no.

Yes.

You're just pushing some of the maintenance work off on sombebody else and paying them to do it. It's still fallible appplications running on fallible OSes on fallible hardware that's all built and maintained by fallible people. [The _hope_ is that "those people" are better at it than "these people". In some cases that may be true. I'm not convinced it's usually possible to predict which cases those are.]

But now you've made yourself even more dependent on network connections -- which are (surprise!) fallible.

--
Grant

I think the problem with IoT is that vendors are JUST pitching it as "remote control". IMO, there's very little "value added" for most devices if you just allow the user to control it from a distant location.

(Do you really need to control your washing machine, dishwasher, irrigation system, coffee maker, etc. from afar?)

But, the real "value added" requires a fair bit more development effort and "selling"/marketing.

E.g., instead of letting me monitor video from my home via an (insecure! :> ) web app at some remote location, why not have some "smarts" in the cloud service whereby *it* is monitoring the video and alerting me to motion detected in the frame? Instead of letting me turn on the water for my rose bushes (but NOT the cactus) from my office, why not make note of the weather in my neighborhood and decide that their transpirational losses are likely to be excessively high, today, and turn the water on *for* me?

I.e., provide intelligent AGENTS instead of just a glorified DynDNS service.

Today's heavily advertised "solution looking for a problem":

Don't forget the (metaphorical) killer: company goes out of business or switches to incompatible products.