Greenbot

Concept

Greenbot is a small device, outfitted with sensors and a camera, that is placed inside a grow tent/room. Alongside the device is an app capable of seeing the live feeds and storing the data to be analyzed over time.

The two flavors of prototype include co2, temperature, and humidity sensors. Their difference being the cameras, one for flower and one for the vegetative cycle. The flower side camera is night vision capable for longer night cycles, but must shine IR light in the darkness. On the veg side, exists a standard camera whose software detects darkness and does not send any images during the shorter night cycles. Notification parameters can be set alerting a user when a boundary has been crossed.

A different aspect of the concept involves the amount of data Greenbot can collect. Which, over time, can be used to infer insights or predictions about a grow based on its conditions. This information could prove to be invaluable for growers from all market segments.

Goals

• monitor critical processes for a grow
• automate menial tasks involved in growth
• store sensor data in aggregate for analysis
• automatically optimize conditions(one day)

Stack

• raspberry pi - hardware module
• react - client side framework
• redux - state management
• node - hardware side code
• express - api and server layer
• postgres - relational databse
• sequelize - sql orm
• socket.io - websocket interface
• grommet.io - ui library

Specification

Run a Node instance responsible for reading localized sensor data on an RPI. This program would connect to a web server via the websocket protocol, to relay the sensor data in real-time, making it accessible to a web dashboard.

The first challenge here is seamlessly identifying each RPI and tying that device to a newly authenticated user whose role can be either guest or subscriber.

One possible solution is a unique QR code, that upon being scanned, opens a url. This url would contain a query string parameter of a signed JWT with a payload of the a UUID generated on the RPI, which could then be stored alongside the user in the database. The UUID could also be used to...

A better option would be to think of the RPI as just another client, which in reality it is, and have a true authentication handshake. This could be accomplished by using a local storage type mechanism. Stored on the RPI, inside can be a signed JWT that would be sent on initialization, in the http request header. The payload contains a UUID generated and signed on the web server. If present, as well as, related to an authenticated subscriber allow the RPI to connect to the websocket.