In the version 7 documentation https://software.farm.bot/v7/docs/account-limitations it states:
While you technically can pair multiple devices to one account, we do not officially support this and it may result in unexpected behavior
Is this a constraint in v9 and if so what might cause the unexpected behavior?
Hmmm. I was wondering how to manage my second and third farmbots when I get them.
It would be great to be able to share sequences between accounts, too.
That is no longer the case and there are far too many assumptions baked into the application to allow for this. Adding multi-device setups (or “workspaces”) will require a substantial effort on our part. It is on our roadmap, however. This is going to become a focus after we finish a few higher priority features, such as random move_abs commands and the ability to use variables in the MARK AS step.
An important clarification: there has never been a point where multi-device setups were useful or stable in the post-v1.2 era. The feature half-existed at one point (which I will describe later for historical reasons). The comment you read was mostly intended for curious developers that may have noticed our DB schema (Users <=> Device) is a one-to-many relation despite presenting a one-to-one relation in the UI.
A bit of a historical note might help clarify:
In 2013, before FarmBot was a company selling kits to the public, it was a side project for me.
There were less than 10 FarmBots in the world during this period.
At this point in our history, the sequence editor was essentially just a form with basic actions.
There were no groups, no sequence variables, no regimens and Farm Events were a brand new feature.
We began work on OpenFarm around this time but it had no integration with the FarmBot Web App.
During this time, I added a dropdown to the nav bar to allow the user to switch between multiple devices.
It was useful for simple things like testing RPCs against multiple devices or that sort of thing, but suffered from a variety of problems.
For example, the device would share all the same points (and garden).
Due to the numerous problems and the fact that we were building FarmBot as a tool for personal use, we decided to just dump the feature and focus on single-user setups to save time and reduce the number of edge-cases the device would have. We couldn’t have imagined how popular FarmBot would become at schools and how many customers have purchased a second or third device for their gardens. In this case, hindsight truly is 20/20.
Hopefully that helps shed some light on the comments you will find in very old documents and hopefully the comments don’t leave anyone with the impression that multi-device setups were fully functional at any point in the lifetime of the project.
Thanks @RickCarlino so to enable multiple Farmbots would changes need to be made to all levels of the stack not just the WebApp but the FBOS etc as well?
changes need to be made to all levels of the stack not just the WebApp but the FBOS etc as well?
The short answer is that you are correct, it will require a lot of changes. Since we will need to work on this feature soon, and because you’ve asked, I will outline a possible solution.
Since we plan to support multiple users (schools) and multiple devices (businesses / power users), we will add a “farm” resource which is essentially the same thing as a “workspace” or “project” seen in numerous commercial software products such as Trello or Github.
saved_gardens resource.farm will need a default_device that cannot be empty. This will be necessary for legacy FBOS versions that do not understand what a “farm” is.farm will have many (at least one) devicesfarm will have many (at least one) usersCurrently, the MQTT channel is structured as follows:
bot/DEVICE_ID_HERE/from_clients: This channel will receive inbound RPC requests that the device must process.
bot/DEVICE_ID_HERE/from_device: Responses to inbound RPC requests will be sent back to clients from this channel.
bot/DEVICE_ID_HERE/status: The bot's "state tree" is constantly updated on this channel. This will include information such as the X/Y/Z coordinates and the bot's sync status.
bot/DEVICE_ID_HERE/logs: Logs intended to be read by humans are sent here. This is identical to the "ticker" seen in the web app.
The good news is that the MQTT channel structure already incorporates a device_id, so controlling multiple devices is just a matter of adding more pub/sub pathways. Minimal changes would be needed for the AMQP/MQTT adapter.
For the Web App, a substantial effort will be required, as the entire application was built on the assumption that there is only one device.
Examples:
currentDevice() will need to be reworked.Probably OK- The following resources will most likely not need any changes.
Will Require Schema Updates
The following resource will need to replace the device_id with a farm_id.
Supporting old FBOS versions and migrating the data may be tricky.
Not Sure
Because we have had a one-to-one mapping of users and devices, a large chunk of the authentication / token system will need to be reworked to perform checks based on a user_id or farm_id.
Adding multi user / device setups will cause many changes in the UI. I will focus only on the essential ones.
There are a couple places where the system disregarded the device_id. There may be legacy resources that are using junk values (such as 0) for the device_id.
Hey @RickCarlino,
I’d like to use the FarmBot Web App to keep track of multiple “farms” (shelves of strawberries) and this is one of the biggest blocks to doing so. I don’t mind doing some work to get it going; especially when you’ve written out where changes will be needed.
I have a dev environment set up for working on the web app, but I don’t have a FarmBot (yet), so my work would likely be limited to the web app.
You mentioned that you’ll need to work on this soon… 6 months ago. So before I jump in, I wanted to double check that:
Thanks!
We’re discussing the multi-bot/multi-user feature this week as a possible next task for us. Many customers have requested it, especially in schools. Unfortunately it’s not the only feature request and we only have two developers here at FarmBot.
If you are interested in diving in to software testing but don’t want to spend the money on a full device, you can simply flash FBOS onto an SD card and run it on a Raspberry Pi 3 with an Arduino Mega attached to the USB port. On your Web App settings, select “FarmBot Genesis v1.2” as your device model. This will allow you to test most features that do not require a motor. If you need help with this, feel free to start a new thread.
I am also happy to answer any specific questions you have about the codebase, database schema, etc… in a separate discussion thread.
To answer your questions:
We have not started work on this feature yet.
We do not have any mockups or specs to show publicly yet. We’re in talks with some of our larger customers who are already running multi-device setups in production to see what their needs are.
I really appreciate your offer to help us develop this feature. I don’t think this is an appropriate first contribution for a project outsider though. Implementing the feature will require understanding of each of the database tables in use, the auto-sync system, plus legacy support considerations for older accounts.
The feature will require us to:
Modify nearly every table in the database
Publish a new version of FBOS that conforms to the new schema
Devise a gradual migration scheme so that legacy devices do not break during the transition period.
Simply put, it is not a good first task for an outsider to the project and will need thousands of lines of code changes across the API, UI, FBJS and FBOS. It will take several weeks to complete if worked on full-time. It’s also extremely high-risk from a QA perspective and will require several days / weeks of testing before launch.
If you are already experienced in software development and urgently need multi-device management, a faster option might be to write custom software that controls the device without changing the core source code. This could be accomplished pretty easily if you have a background in Javascript / NodeJS + FarmBotJS (FarmBotJS is the Javascript library that powers the UI).
Stay tuned for more details. I am happy to answer any software development questions you have in a seperate discussion thread.
@RickCarlino I’m also interested in helping Farmbot with this feature. We had a stab at it a while back made the DB changes and a first cut of the screen etc but our priorities changed. Keen to help with any mockups, requirements gathering, may be able to help with user testing.
Let me at it 
I’d enjoy a “Test Pilot” role with the pre-releases !
@whitecaps @jsimmonds We always appreciate your help! I will pass this interest along as we prioritize the next set of features to work on.
Fair, I’m sure you have plenty of good options to pick. I’m glad to hear it’s getting considered though!
Yeah, that’s a good reality check. I did go digging through the source and I found most of what I was looking for, but it’ll take some time for me to get comfortable.
Funny enough, I’m coming at it in pretty much that direction. I already have custom software for controlling my systems, and I was hoping to dip my toe into FarmBot by using it to keep track of what I plant where. I think for now my solution will be to create 6 accounts and have one for each “device”.
Thanks for taking the time to help work out a solution!
No problem @TheHackmeister ! 
The “one account per device” idea is probably the best option until we roll out the multi-device feature.
Additional note for any software developers that find this thread later on via search:
The FarmBot Web App was built using a standard REST client and FarmBotJS. If you need special features that don’t exist and would like to build them yourself, the best way to get started is by using FarmBotJS + the REST client of your choice (our current favorite is Axios). Those two tools are enough for most every feature a developer would want to build.
Additionally, we have publicly available documentation for software developers. If something is still not clear in the developer docs, please let us know in a new thread. We’re always happy to help third party developers learn the platform.
Hi @RickCarlino, do you have any update on the one account multiple device feature? Still keen to be involved in the design and testing. Possibly programming early next year.
@whitecaps It’s on the road map, but has not entered the planning phase yet unfortunately. There’s only two of us writing code (Gabe and myself) so progress often moves at a slower pace than anyone would like. I don’t foresee us working on this feature in Q1 but will keep you posted if that changes.
@RickCarlino have you had any external open source contributors work on a feature like this in the past?
Just wondering if we fork the code and start work on it how difficult (i.e. has it been done before) the merge back to the main branch will be?
Also asking as a change like this cuts deep into almost every repo \ software layer you have.
@whitecaps We’ve had plenty of people contribute to the software, but typically the contributions are small and focused to a single purpose. Examples of this are spelling fixes, styling fixes and minor bug fixes. Implementing a multi-device / multi-user setup would be the biggest outside contribution ever. That’s not to say it can’t be done, but it would require a level of effort the project has not seen in 7 years of existence. It would require an understanding of Elixir, Ruby on Rails and ReactJS. We also have a requirement that new code additions are accompanied by corresponding unit tests, so it is critical that the feature be well tested.
I think a good first step would be to begin familiarizing yourself with the code base and learning how the bigger pieces fit in, then dive deeper in to specific problems before attempting to make large changes.
I would be happy to help you along the way. DM me if you have specific questions about the code base and I would be happy to answer them.