Yes totally 
can you please delete my posts up and including the one from the 20th? Thanks… 
hi all
i have just checked this farmware.
it works for me, with farmbot os 7.0.1 and WebApp 7.2.4
Plant stage status is well modified, i have checked in the database… But it is not dynamicaly refreshed in farm designer.
You need to refresh your browser (F5)
i found a little bug: it was logging an error when you set plant stage to None. In 1.0.3 just released version, it log a debug : “Nothing to save”
For plant Name/openfarm_slug filtering, wildcard works.
But keep in mind it’s not a regular expression.
You must set exact name or only wildcard * (with no space before or after…).
i will add this functionnality in next iteration.
Have a good farming
https://raw.githubusercontent.com/rdegosse/Loop-Plants-With-Filters/master/manifest.json
version 1.0.4 : Added sprouted status for plant stage
@renaud Could you add an additional input field for pointer_type? Right nowthe pointer type is fixed to “Plant”, which makes it impossible to filter for GenericPointers like Weeds.
I’d do a Pull request, but I’ve got almost no time for farmwares recently. 
Seems the Loop-Plants-With-Filters does not work with Farmbot OS 8 and 9.
Is there anyone having a version running for OS version 9+ ?
It seems that the provided software still does not have any way to loop on a sequence form plant metadata (check status, date etc… to plant or water a group of plants) ?
@vroyer
the farmwares would need to be updated, just a small fix to the manifest.json file I guess.
Looping over a group of plants is already working and the criteria function will be released very soon I guess.
You can try using amerkay’s Powerloop farmware, I updated the manifest for current OS versions some time ago in my personal fork. Its working, but some old farmware bugs are still present on Powerloop as the farmware is not developed furthermore.
Also note, that there was a timeout for farmwares beeing set to 60s! So if your farmware runs for more than 60 seconds, and those looping farmwares usually do, the process will be cut off.
But with the provided functions in the WebApp you can at least create different groups of plants and loop sequences over them.
Edit: Thanks @jsimmonds, for some reason I didn’t notice that. 
@Ascend @vroyer in current FBOS v9.2.1 the Farmware run time limit was raised to 60s by @RickCarlino 
1 Like
@ascend, Ok, thanks, i’m running FBOS v9.2.1.
I have fixed the manifest, by I guest there is also some code changes to do because the config is now a map (was an array).
Anyway, planting 40 seeds or more will take more than 60s, so farmware is not the right solution to do that job….
But how can I build a sequence to plan a group of plant ?
The Loop-Plants-With-Filters was able to do that job with 4 sub-sequences (init, pick-seed, plant-seed, end) and filters on plant metadata. The farmbot provided software does not still allow to do that ?
@ascend @roryaronson Sorry, by i’m really disappointed with your software !
I bought this farmbot one year ago, and it’s still impossible to build a sequence to loop over a group of plants defined in the farm designer, that makes this farmbot practically unusable to manage a large number of plants (That was possible with the Loop-Plants-With-Filters, but it’s limited to 60s, so not usable for 40 plants or more).
Your current software still requires to build a sequence for EACH PLANT form the farm designer, and that’s just a big joke ?
Your current software still requires to build a sequence for EACH PLANT form the farm designer
@vroyer This was the case in previous versions of FBOS, but is not the case in 2020.
You can iterate over a selected group of plants by creating a group and then passing that group to an execute block (from the “TEST” button in the sequence editor, from an “EXECUTE” block, or from the FarmEvent editor). This feature was released over a month ago.
This week we are almost done with a new “criteria based groups” feature that will allow you to dynamically set a search criteria (such as all plants matching a meta data criteria). All parts of the feature are complete, except for some UI changes. We will begin QA and release the feature as soon as it is stable.
For tasks such as seeding and watering (where filtering is not required), the current groups + execute workflow should suffice.
Please let me know if you require any assistance with setting up point groups or have any questions about how to apply group members to a sequence.
1 Like
Sorry, but in my UI, there is no argument for group of plant in the “execute sequence”, nor in the “test” sequence button.
All computing languages have get, set, if-then-else, call, and loop instructions. You have many sequence commands (home, move, read-sensor, if-then-else, call other sequence, etc…), but no LOOP on a group of plants.
So, there is no way to build this kind of sequence:
-mount tool
-for all plants of a group X {
execute sequence “pick a seed”
execute sequence “move to the plant location”
execute sequence “plant the seed”
}
-unmout tool
That’s a basic for automation !
So if you can do that, please provide an example, that’s really missing …
@vroyer The new workflow can take some getting used to. I have checked my records and you are running a version of FBOS that supports groups. Most likely there is a missing piece of information in one of your sequences and as a result, your groups will not show up on the list as a valid option.
I will detail step-by-step instructions below.
Step One: Create a Group
Create a group by selecting a collection of plants in the plant selection menu and clicking the “MAKE GROUP” button. The number of plants must be greater than 1, otherwise the following steps will not work. For example, if you want to work on 40 plants, you must ensure that the groups panel says “GROUP MEMBERS (40)”.
Step 2: Define a Repetitive Sequence (one plant)
Create a generic sequence to perform a single action on a single plant. Example: A watering sequence that waters only one plant. Instead of selecting a real plant in the “MOVE TO” drop down, select “EXTERNALLY DEFINED”. Set the “default value” to (0,0,0) because it will not be used here. The “Externally Defined” part is the important piece of information - FBOS will replace this externally defined variable with a “real” one later (next step).
Step 3: Apply Repetitive Sequence to a Group
Create a “wrapper” sequence that executes the sequence we created in step 2 via an “EXECUTE” block. The execute block will ask you to fill in the “EXTERNALLY DEFINED” position here. This is where you will select the plant group you created in step one.
Step 4: Test the Sequence
You are now ready to test the group action with the “TEST” button. You will most likely need to make slight adjustments to the sequence to meet your needs precisely, and not everyone will get it right on the first try, you may need to make position adjustments. The “MOVE RELATIVE” block is a useful tool here, as it pprevents FarmBot from losing its place (since the sequence is generic and does not work on a concrete set of X/Y/Z coords).
Another useful tool is the X/Y/Z offset boxes, as this is often required for seeding operations.
2 Likes
Ok, thanks very much for detailed explanation.
So the move command can run with a variable looping on a group of plants, and that does the job (i successfully tested it)
Next step is to filter and update the plant status in state “planted” (or whatever) when running such loop, to be able to recover from a glitch. I hope your next release will be able to do that ?
3 Likes
Next step is to filter and update the plant status in state “planted” (or whatever) when running such loop, to be able to recover from a glitch. I hope your next release will be able to do that ?
Yes, this is what we are working on this month. There are still some issues for us to fix on our end with the UI, but we have tested it on internal builds and have it mostly working. The release will be announced on our newsletter very soon.
Thanks @RickCarlino for that wonderful step-by-step instruction. It probably was a bit confusing for most people, especially for those who did not see the software update announcements.
What do you think about adding this at some time in the “Tours” section of the WebApps help page?
1 Like
That’s a good idea @Ascend. We’re also going to update our documentation, since this is the second time the question has been asked this week.
Thanks again for the explanation, a doc update would be nice.
The sequence on a plant group works, but it still does not update the plan status from “planned” to “planted”, and it cannot recover from a glitch.
But so much technology from a California company working with the NASA to change the world, 9 versions of software, and it is still not possible to update the plant status to properly manage 40 seeds of radish, that’s a bit ridiculous !
How can i explain to my 12 years old son that the farmbot can do that, just a loop with status update on each step ? So please quickly fix that or share the next release code on github, we are contained because of the COVID19 and this is time to make this work properly, time for misleading advertising is finished.
1 Like
@vroyer it sure is time for better software !
I think @RickCarlino would agree that Farmwares should not be cut off after just 60s !
Now that the old Farmware v2 execution bugs have gone, a 5 minute “safety stop” limit for a running Farmware should be totally fine !
What’s a typical end-to-end run-time for your Farmware ?
[edit 0] I personally don’t like Farmwares . . there’s very little you can accomplish while the Internet connection has dropped !!
[edit 1] Why not make this “Farmware run-time timer” configurable !!? somewhere.
@jsimmonds @roryaronson The Loop-Plants-With-Filters farmware was good to build complex sequence using a filtered list of plants, and update plant status while sequence is progressing. With the farm designer v9.2, you can’t even manually update the plant status !
Give up this opensource farmware support while the farmbot software cannot do the same or the equivalent (manage sequence with loop, status filter and status update), it’s just an incomprehensible strategy for an opensource community…
1 Like
@vroyer, as you’ve noticed, some farmwares from the past no longer work with the latest versions of FarmBot OS and require updating to work. This is because we had to make some breaking changes to the way farmware works within FarmBot OS, which is why we incremented from v7 to v8 (marking a major release).
While nobody ever wants to intentionally break integrations, plugins, compatibility, etc, sometimes it is the right decision to make to push the greater platform forward. When we were making this decision, we first looked at the number of farmwares actively installed on our customers’ FarmBots. You might be surprised that the number of unique farmwares that were being used back when v8 came out was less than 10, and the number of FarmBots with those farmwares installed was less than 20. While we immensely value the importance and contribution of our “power users”, we also must recognize that they make up a very small fraction of our customer base. So we must balance the effort expended supporting this small subset of users with the effort spent supporting the vast majority of our users who are not software developers and/or have no interest in finding and using publicly available farmware.
During the v8 build phase, we emailed farmware developers we knew about and discussed plans for how to move forward together. As with most decisions in software development, we had to make tradeoffs. In order to move the core FarmBot feature set forward (adding support for sequence variables via the new “celery script runtime”) farmware would have to be updated.
Unless FarmBot Inc has authored the farmware, we don’t have any control over a 3rd party author updating a farmware other than politely asking. If the author is unable to make an update, and if the farmware is open-source, someone else may feel inclined to pick up where things left off, though nobody is making any guarantees that that will happen.
I hope this sheds some light on the current situation and allows you to understand that we didn’t give up some farmware support for any nefarious reasons, or for no reason at all. We have arrived at where we are today after much deliberation and a lot of calculated decision making.
In terms of FarmBot’s open-source strategy, we are doing everything in our power to support and empower people to make FarmBot better, and are always open to feedback (and PRs!). We not only have licensed all of our technology with permissive open-source licenses, but we have gone above and beyond in providing high quality documentation, CAD models, schematics, a public forum, an open API, hackable hardware, a parts shop, an app experience designed with customizability at its core, and a 3rd party plugin system (farmware). We have done all of this because FarmBot is a very ambitious project that has many moving parts, and our official team is very small. There is no way our team, or any team, could ever realize the full potential of FarmBot. Only an open ecosystem with a strong community that is empowered to make their ideas reality will achieve that.
Okay, so what about these features you want? We want them too! And we’re working on them - every day - and have been building the foundation to get here for years now. We’re also balancing the work on new features with improvements to stability and performance, adding support for our latest electronics, and fielding the myriad of other requests we receive both here on the forum and through our official support email. Check out our GitHub repositories and public project board to see the daily and weekly progress, and feel free to hop in yourself. PRs are welcome, and we’re happy to help anyone who is serious to get started with development.
We also had a meeting yesterday to figure out how to expedite the release of groups based on filters (all weeds, all broccoli plants, all plants that are ‘planned’, etc), and are working on getting out an initial implementation as soon as possible (we’re shooting for next week). After that, as you will see in our project board’s TODO column, next up is improving the MARK AS command to support variables, and a write-in custom option. These features will allow for a very customizable “programming” experience that will offer similar functionality to some of the most popular farmwares.
Additionally, I spoke with Rick this afternoon and we will be lifting the 60s limit on farmware with the next OS release. To be clear, we have not and will not be testing long-running farmware and your mileage may vary. You may run into unexpected issues and your FarmBot may become unstable. We’re doing this because of the feedback in this forum post and to support you all in tinkering. However, we simply don’t have the resources at the moment to fix issues that may arise after 60s of execution, but again, open-source contributions are always welcome.
3 Likes