Enhanced Program Logic

Software
1

Hi all,
I am missing two things very much:

  1. create a random number for MoveTo commands. In order for placing the soil sensor or for watering the plants, I would like to move to a position with a random range, to not always hit the same point.
    Is there a chance to implement this maybe as a farmware? Or does anyone have another idea?

  2. It would be so helpful if one could save some information or a state in one sequence (e.g. soil moisture value, which tool is mounted, … ) and read this in another sequence for some logic.
    Any ideas how to do this at the moment? Any plans for the near future to have this feature?

Thanks
Markus

1 Like
2

create a random number for MoveTo commands.

This feature does not exist yet, but we have gotten some requests for it.

Is there a chance to implement this maybe as a farmware?

Yes, it is possible to implement this as a Farmware. Please avoid adding too much logic to Farmware, as the system is going to change drasticly in the next 18 months (details below).

It would be so helpful if one could save … information or … state in one sequence … and read this in another sequence for some logic.

This is on the road map. We are planning on making big changes to the “MARK AS…” step to increase its usefulness. We have not started work on this yet.

Any ideas how to do this at the moment?

If you are comfortable with software development and have a very specific set of requirements, the best way to solve the problem is to write an external “remote control” server. I made an example of that here.

As a side note, users are highly discouraged from authoring new Farmware, or relying on Farmware as their main means of device control. Farmware adoption has been extremely low (< 10 users), while also suffering from many legacy support issues. We’ve made the decision that the next version of the Farmware system will be a complete re-write and there will most likely not be a migration path, since so few people have used the system.

This was not an easy decision for us. For the 8 people that currently write Farmware, it was tough news to bear. I explain my logic a bit more in this Github thread:

The reality with [farmware] is that it has eaten up huge chunks of our developer hours (sometimes entire work weeks). I only have evidence of 8 other people actually authoring farmware … we’ve spent countless weeks implementing these features, hunting bugs and making compromises elsewhere in the system to allow for on-device scripting support. I can’t say it makes sense from a business perspective to continue encouraging people to write on-device software, at least with the way it is currently architected.

1 Like
3

@RickCarlino

Has the subject of FBOS-Next been created as a Topic here ? I’d love to contribute :slight_smile:

4

@jsimmonds We haven’t yet, but I’d be happy to talk about it if you did!

Here are the basic ideas:

  • No more hosting of code on remote servers, such as Github. Code will be hosted on the API and directly uploaded to the device.
  • Restricted subset of commands for security (sharing) and to prevent accidental interference with CeleryScript runtime.
  • No tool chain installation or desktop requirements. Instead, we will put an integrated code editor (probably Monaco) into the Web App and you will be able to author Farmware from any machine with a web browser.
  • Embedded languages only. Supporting full-featured languages on the target has been problematic. Eg: Lua, DukTape Javascript (instead of Node), mRuby (instead of Ruby), MicroPython (instead of Python).

These are just ideas but they form the general idea of what the new Farmware environment will look like. Feedback is welcome (in a separate thread, preferably).

1 Like
5

@mbuchberger1967 could you tag it with farmware, please?

→ Very interesting things
@RickCarlino would you open a new thread to brainstorm about farmware 2.0? Instead of Monaco, have you considered sth like jupyter or zeppelin.
Hosting code on SCM-Servers were always a good idea in software development why are you want to go away from this best practise? I think a good CI/CD-Process to deploy future farmwares to the devices worth its weight in gold.
Just support one language (my favorite: Python) that’s my recommendation to save time
(IMHO)

1 Like
6

Farmbot is a simple machine, but it’s complicated to control it. “Farmware” never felt right. I did develop several farmwares for my private use to make farmbot more intelligent - such as the basic task of moving from A to B without hitting anything. Farmware was too much of a pain and I eventually ended up hosting my code externally. Being able to write code in the UI seems a good approach, at least it sounds better than the weird sequence editor (please remove it). But you need to do it right to convince people with a software background, we’re not happy with limited functionality or drag&drop coding.

1 Like
7

Eh ? what is “my code” and by externally you mean hosting a WebApp ?

. . . Absolutely correct.

8

Eh ? what is “ my code ” and by externally you mean hosting a WebApp ?

A .net core console app, runs in a container on a NAS and remotely controls farmbot. It does water the plants depending on weather. For this season I was looking forward to make more use of sequences, but I will be switching back to my little .net app.

9

I appreciate your feedback @ooswald. We’re having a very fast-paced week at FarmBot, so my responses on the forum have been shorter than usual (and sorry for the lack of replies @jsimmonds)

That sounds like an interesting setup, and I would love to learn more about your NAS if it natively supports containers.

“Farmware” never felt right.

Can you name some of the things that felt off to you? In my own experience, I’ve felt that Farmware’s write-compile-deploy-reinstall cycle was a bit cumbersome and could easily be fixed by running the software off-device where reloads and software updates are faster. This is why I’ve been contemplating the idea of adding a Monaco editor as a half-way point between Farmwares as they currently are and the alternative of external application hosting. It seems to offer the flexibility of external hosting (fast reloads, easy experimentation), while solving some of the pain points (many users are discouraged by the complexity of external hosting or having a second machine running).

10

Can you name some of the things that felt off to you?

I feel the same way on the dev cycle like you noticed. Probably my biggest challenge was debugging - one can spend a lot of time to get a complex sequence/farmware running properly. Discovery of “good” farmwares was not easy, too.

Having the ability to provide code in the UI, if not too limited, will be a great addition for most farmbot users.

Removing farmware, however, is another story :smiley: perhaps “Farmware” would become an extensions / package manager, or a library for reusable snippets.

Thinking about it - along the way I briefly used node-red to remote control farmbot. It runs great on a Pi, and it could basically replace the sequence editor, farmware and the new code editing feature :wink:

11

Hi Guys,

@ooswald Good points especially about debugging and potential local Pi server idea.

Could we please move the discussion to FarmBot OS and WebApp post-v9?

There are 3 threads related to the same topic at the moment.

Kind regards
Rob

12

Good point @whitecaps. I will lock this thread.