A controller, two sensor buses and a pump bus.
GrowRoom is a bus concentrator. Sensors and pumps plug into one controller per room over standard cables, and the gateway built into that controller reports to the cloud, where the app and the portal pick it up.
In the room
One per room
Anywhere
The gateway makes outgoing connections only, so nothing on your network needs opening.
What each piece does.
Every part has one job, and a fault in one is meant to stay in that part.
The controller
A single board with an industrial-class processor. Sensors plug in along one long side, on RS-485 buses; pumps along the other, on CAN and RS-485. Expansion headers take the equipment outputs, and the WiFi gateway module sits in one corner of the same board.
Air and water sensor buses
Air sensors share one RS-485 bus. Water-chemistry probes share a second, electrically isolated one, so a probe sitting in nutrient solution does not pick up your room's ground noise. Each sensor has its own address.
Pump drivers
Each dosing pump has a small driver of its own, planned in its own case: a processor, a motor driver and an encoder input, with one RJ45 cable back to the controller. It receives a command such as "dispense 5.0 mL" and reports back when it is done.
The gateway
It joins your 2.4 GHz WiFi, reports readings to the cloud and collects commands. Setup is over Bluetooth from the phone app, which shows the networks the gateway can see.
What happens when you press "dispense".
Dosing is the one action that puts something into your reservoir, so it is the most guarded.
- 01
You confirm
The app asks you to confirm the pump and the volume. Viewers cannot send commands at all; operators, admins and owners can.
- 02
The pump checks
The pump refuses if it is disarmed, busy or asked for an out-of-range volume, and says which. Every pump starts disarmed after power-up.
- 03
It doses and reports
It runs until its encoder has counted the volume, then reports what it delivered. It stops early on a stall or after 120 seconds, and says so.
Status: the pump firmware is written and answers commands on the bench, and the safeguards are in it. No real dose has been run yet. See the status page.
What happens when something fails.
The behaviour below is what the system is designed to do, with its current test status.
| If this happens | Status | The system |
|---|---|---|
| Internet drops at your site | Working | The cloud notices after 5 minutes of silence and raises a "room offline" alarm. The gateway keeps retrying. |
| Internet returns after an outage | Working | Lights, fans and heaters return to their last state. Irrigation does not restart on its own; water running with nobody present is the riskier mistake. |
| Schedules during an outage | Planned | Today schedules run in the cloud. Moving them onto the controller, so a room keeps its routine offline, is a launch requirement. |
| A pump loses contact | In development | It stops itself after 30 seconds without commands. During a dose it uses its own stall and time limits. |
| A pump stalls mid-dose | In development | It stops after 2 seconds without encoder movement and reports the dose as stalled, with the volume delivered so far. It does not fall back to timed dosing. |
| A gateway update fails | Working | The previous firmware keeps running. An image with a bad signature is rejected. |
| Mains power is lost | To be confirmed | There is no battery backup. The gateway reconnects from stored settings. Pumps start disarmed. Controller behaviour after power loss is still being defined. |
See the parts, with their specifications.
Every figure on the hardware page says where it comes from: the manufacturer, our design, or still to be confirmed.