playing around with the sequence builder, it dawned on me that there will be a lot of reinventions of the wheel.
So I’m thinking to build a little sequence hub, to which you can upload your sequences and from which you can download other people’s sequences.
In the farmbot frontend app, this would require a JSON export/import mechanism.
As I don’t want to reinvent the wheel with this myself, I was wondering: Is anybody working on something similar, or are there plans to set up something like this by the farmbot team?
The AST must be properly formed or it will be rejected by the bot and/or API. I am planning on doing a write up about how it works soon, but have not yet gotten around to it.
If you are familiar with Typescript, you can see interface definitions for all of the different AST nodes here.
Right now, we have a custom validator for these nodes written in Ruby, but I would really like to switch over to something more reusable like JSON schema so that people could write third party tools and editors for things similar to what you are suggesting.
I’m happy to help with any other questions you may have.
A great place to start with this @creimers is adding import and export buttons on the frontend. The biggest challenge though is that most sequences will be utilizing imported coordinates from tools and soon plants, weeds, parent sequences, groups of plants, etc. So for a sequence to be really usable by someone else it will need to either bring along its dependencies (which sounds like a bad idea), or drop its dependencies and require the user to “re-wire” them which might make the imported sequence useless if it has a lot of dependencies…
@RickCarlino Yes, I saw the TS interfaces and also started analysing the redux store. Thanks.
@roryaronson I have a basic export button integrated, but as of now it’s not able to export nested sequences. Why do you think bringing along its dependencies is a bad idea? Too much clutter? Maybe there’s a way to encourage users to compose small, reusable sequences.
On the other hand, sharing complex and nested and very specific sequences can potentially also be useful if you look at it as a source of inspiration more than a no brainer import…
Passing dependencies indeed will be a tough one to tackle. Over the next few weeks, we will be modifying the structure of sequences to have a parameter/argument list (probably in the “args” attr of “sequence” nodes). This will make things more portable, similar to how a traditional programming language might use parameter passing for dependency injection (think: Angular 1 dependency injector, where everything is listed in a parameter list before running) we will eventually add a UI so that the user can import these things before running them.
Importing dependencies seems useful to someone who is just starting out so, as you mentioned, they do not have to reinvent the wheel. But for someone who has their tools, sequences, plants, etc already established, they probably wouldn’t want to import a bunch of things just to help someone troubleshoot or just to poke around. Because then they will need to go through and delete stuff in multiple places if they decide they don’t want to use it, and they might miss something, or delete the wrong thing. For example: if the imported sequence included a tool that had the same name as an existing tool, it would be unclear which one to delete. Or if a child sequence was named the same as an existing sequence. Maybe during import there could be checkboxes for the user to selectively import dependencies?
Also, there is u huge overlap for most used sequences and all the common tools/trays.
Some other other software that come to my mind right now, is zabbix and templating:
you can define macros with k=>v and use that in template, defined later.
defined named regular expressions
This leads me to an idea of abstract (shareable) sequence. Tools are defined elsewhere, and create name/value list with coordinates. Also pins are defined as table with name and value. All this dependencies could use some place-holder, later populated.
Just a rough idea.
The import feature would make it easier to write some simple macro-expanded language. Or even full verification on server side, for dependencies.
I would like to re-light this topic.
My thoughts, as a new FarmBot’r, are that I would like to see how others are developing their sequences, regimes, events, farm designs and such. This info would help me in developing my own, and I would be able to contribute my own methods and structures.
Understood that some aspects may be specific to an individual FarmBot, but, as long as this is understood, it would be up to the community to “take with grains of salt”.
I see a lot of folks reaching beyond the Web UI and doing (and posting (a good thing)) lots of raw hacking (either editing the scripts or developing their own). What I see lacking is conversation about “working with the tools we have” posts…
Having said that…
What about adding a Forum Topic like “Sequence Building”, “Farm & Sequence Design”, and/or “Basic to Advanced FarmBot Web UI Structure Building”?
The overall concept would be to create a space for the FarmBot Community to post, share and find Sequence and Web UI learnings…
Adding the Gurus of FB… @roryaronson, @RickCarlino, @connor, @Gabriel, @Ascend
Hi, concerning the import/export feature for sequences, I believe that we would be able to reach a much bigger part of the community than we currently do as there are people around who would be able to develop sequences for gardening, work on new tools or who just would get those people started who are not so much into programming (yet).
Advantages would be
data backup
simple version control during development of sequences
sharing sequences
providing sequence templates to get people started.
offline editing of sequences
I see the discussed issues with dependencies etc. but I think if we would start with a simple import check before overwriting anything without anything more, this would already be a great benefit for every single user and also the community.
It’s not that simple unfortunately. Or, it is possibly doable for hobbyists, but there are a lot of usability problems that a CSV system would not be able to address. I don’t have time to go into the details unfortunately (you may have noticed the spike of support requests we’ve gotten this week) but I will tell you that I am answering your question from experience gained through experimentation for the exact idea you are suggesting.
With that being said, you could try it out. I’ve built very simple prototypes of your idea and they can cover 80% of the use cases. The 20% part is what makes it difficult and not a viable solution for non-technical end-users.
I have used https://makecode.microbit.org with people who wanted to learn about programming. There, you can switch over to JS and share text. That’s not a real import and export, but it does the job. Would that be an option?
@jensGeorgsen I don’t think so, but explaining the issues would take more time than I have unfortunately. A code sharing site would work for simple sharing or use by hobbyists, but it would not be adequate for production use as an official feature (if you do some experiments, I think you will quickly find out why).
My advice would be for you to try it out and see how far you get. I can answer any questions you have along the way.
That’s absolutely true @jensGeorgsen and to clarify, FarmBot intends to implement the feature you are suggesting. It’s already on the roadmap. The main issue is that we’re limited on developer resources and we’ve felt it is better for us to focus on bug fixes and weed detector improvements in 2020.
I would be very interested in this as well. Im just getting started with Farmbot and it would be a great start to be able to import/start with some pre-built sequences. I would think that similar plants would have similar growing/watering patterns that could be leveraged. Any timeline for this feature?
Is there an easy way to get started except from creating all sequences from scratch? Other than the forums, how can users leverage the experience of other users.