Running time of sequence/regimen

Is there a way I can see in the software the time a sequence or regimen is running so I can schedule the one right after the other?


1 Like

In my experience, when two sequences are scheduled in an overlapping fashion, the second sequence gets “queued” and executed once the first one finishes.

I have yet to find out what happens when they are scheduled at the same time (I have two plant groups that used the same regimen).

@Stephanvl The best way to handle this would be to add a “wrapper sequence”. That is to say, if you must run A, B and C in sequential order, you must create a fourth sequence D:


You would then schedule sequence D (and only sequence D) in a FarmEvent. Do not attempt to time each sequence or guess how long it will take since this can lead to unexpected behavior.

This is a bit of FarmBot OS trivia, but I will try to provide an answer without going too low level. In the case that a FarmEvent takes up too much time and overlaps the time slot for the next running farm event, FBOS will wait for a pre-defined “grace period” (15 minutes). If the FarmEvent cannot run within two minutes of the expected time slot, then the farm event is simply dropped.

The code that handles this logic can be found here: farmbot_os/scheduler.ex at b67cae90c403919e209f14c111bade5da4489cb7 · FarmBot/farmbot_os · GitHub

I hope this helps! I am happy to answer any other questions you may have.

This is interesting to me because I like to view the FarmBot as this 24/7 gardener that doesn’t complain about their bad back and horrible working hours. Why couldn’t Farm Events be pushed back indefinitely (or… max 24 hours, which would indicate your schedule is too full)?

The reason I’m asking is because I’m struggling getting my head around Nested sequences and Plant Groups and their intended usage.

If Regimens are designed to string Sequences together to form the basis of plant-care for a type of plant, it makes sense to keep these garden-agnostic. Meaning that a Regimen doesn’t know about the plants in your garden at all.


I’m planning on growing 30 radishes in my garden. But I don’t want to harvest all 30 at the same time. So I’m making groups of 3 radishes, meaning I’ll end up having 10 groups.

Each group is assigned the same Radish Regimen, but using Farm Events, the start date for each group is staggered. But they all use the same set of sequences to be cared for.

Radish like lots of water. My Regimen dictates they are watered daily. But since all groups are using the same Regimen, they will all be watered at the same time in the Farm Events.

I get the feeling once I get to the point where 3 or 4 groups are “active” at the same time, FarmBot will struggle caring for my radishes after group 3, simply because their triggers are going to be dropped.

I don’t want to create a Radish (copy 1) Regimen just to be able to manually offset the watering time on each day. I think that goes against the design intent of Regimens. But I think something needs to change in order to prevent many events that happen to get scheduled at the same time to become dropped.

1 Like

In my experience all Sequences run concurrently :open_mouth:

[ edit ]

If this behaviour defies the ‘official’ use-cases then I’d love to help fix :slightly_smiling_face:

You’re right, I was really referring to two Farm Events. The first event was scheduled at 18:30 and the second at 18:40. However, due to the way the first event’s sequences currently work (see Nested sequences and Plant Groups) it took 15 minutes instead of the anticipated <10.

But even so, while the second event was scheduled at 18:40, it promptly started working about 20 seconds after the first event completed.

We had this discussion a long (> 4 years?) ago. It was a very long discussion but unfortunately, I didn’t take notes. Long story short, there were a lot of subtle edge cases created if we did the approach you are recommending (and we did consider it!).

I haven’t had time to reply to that thread yet, but it’s on my TODO. Details to follow. Sorry, busy week on our end.