search

CommonGarden / Grow-IoT

Software packages for smart growing environments.
http://commongarden.org/
Other
25 stars 6 forks source link

Support nfc configuration of devices #65

Closed JakeHartnell closed 8 years ago

JakeHartnell commented 8 years ago

It needs to be easier to connect and secure iot devices, I think near field communications technologies are a good fit for this as they are increasingly included in modern phones.

Users would switch the IoT device into pairing mode, open the app on their phone (or watch someday), and place it next to the device. The app confirms success and the user switches the device back into secure mode.

The app would instantly the configure the devices with their owner, a unique id and token, wifi credentials, servers it's allowed to communicate with, etc.

Will mock this up with an RFID reader for the hackathon.

JakeHartnell commented 8 years ago

This is meant to simplify the annoying but prevalent IoT workflow of having to leave the app, go to settings, join the device hosted wifi network, go back to the app, wait, on success go back to change your wifi back to normal. #seriously

JakeHartnell commented 8 years ago

Or we could just do Bluetooth.

JakeHartnell commented 8 years ago

Near field / RFID would be cool because some users such as small businesses could get dongles, allowing gardeners to easily configure new devices / modules. Maybe it should be lower priority though...

JakeHartnell commented 8 years ago

https://www.npmjs.com/search?q=bluetooth https://www.npmjs.com/package/cordova-plugin-bluetooth-serial

gtfierro commented 8 years ago

We aren't going to solve something as broad as "connect and secure IoT devices", but if we define our problem domain well enough, we can probably find a solution that's appropriate.

Is a device a smart pot for a plant? Is it a sensor? What's the communication medium that sensor/thing is using? What kind of configuration does it need to get?

i can think of a couple off the top of my head:

  1. inform a smart pot what kind of plant it will be growing. Assuming the pot is networked, we could give it a URI it can follow to retrieve growing instructions and the like
  2. Associate a smart pot with a local deployment. This is dependent on what kinds of electronics are in a smart pot and how it is networked. If this is a raspberry Pi, a friend of mine has done some cool work collating the udev rules to enable a USB config stick to be plugged into the RPi and configure all aspects of the network, dual-home initialization order, etc

If we're getting into how to secure devices, then we have to start thinking on what kind of authorization and what kind of authentication we want to do, as well as how to bootstrap the administration of these systems. This starts to get at what kind of architecture this system will have.

I like the idea of starting small and concentrating on small, local deployments that archive their own data. Data dumps could then be uploaded to a common database that can do more detailed analytics over a family of deployments. A nice configuration for the "home garden" is a local, off-the-shelf PC (FitPC2 is what I've used most often -- raspberry pi can be unreliable, esp with wireless, and I'm guessing beaglebone black is similar) that can run a database and some configuration services and connects to all of your local sensors and smart potted plants and etc to schedule them and monitor them.

JakeHartnell commented 8 years ago

Closing, thanks for the response, I'll have to get use to not just writing for myself in the issue tracker. This clearly should be many specific tickets.

We aren't going to solve something as broad as "connect and secure IoT devices", but if we define our problem domain well enough, we can probably find a solution that's appropriate.

Ditto.

I like the idea of starting small and concentrating on small, local deployments that archive their own data.

Me too! That's why I picked meteor, because it's easy to spin up your own local or cloud instance... as long as you are brave enough to open the terminal.

gtfierro commented 8 years ago

Thing with meteor is it is great as a web frontend, but that's only one part of the system we need to construct. I doubt we'll have a single binary that will solve all our problems. Ideally, with any GUI app, anything you can do with the GUI you should also be able to do with an API call, which implies that Meteor may not be the central component.

JakeHartnell commented 8 years ago

Thing with meteor is it is great as a web frontend, but that's only one part of the system we need to construct. I doubt we'll have a single binary that will solve all our problems. Ideally, with any GUI app, anything you can do with the GUI you should also be able to do with an API call, which implies that Meteor may not be the central component.

Very true.