Sequence code blocks and API calls

Feature Requests
1

@RickCarlino following on from the future alternatives to Farmware discussion here Farmware MoveAbsolute and ExecuteSequence not working.

There are two solutions, it would be good if Farmbot supported both. I have seen these techniques work well in other shape programming languages i.e. ESBs like BizTalk, Windows Workflow Foundation, Mulesoft and my favourite Chatfuel (best shape programming environment I have seen so far, as it is so easy\fast to use). Note Farmbot has done quite well with sequences given the small team you guys have.

Both solutions should share the same Farmbot interface/contract (see below).

1) Hosted API: user writes, tests and hosts an API that implements the Farmbot interface/contract. They then drag an “API” shape into a sequence and enter the API endpoint URI, security token, farmbot id etc and name value pair array of input arguments. Hint look at how Chatfuel does this https://docs.chatfuel.com/en/articles/735122-json-api.

Pros: ease of debugging as user should be able to attach to the process and step through when the API is called. JSON contract allows user to choose language / tech to implement API. Probably easiest for Farmbot to implement.

Cons: requires hosting environment, possible higher latency, suits more tech savvy users

2) Embedded code block: user writes some Javascript or Python code in an editor implementing the interface. They then drag the “Code” shape into a sequence, fill in the input arg name + values pair array as per the interface and cut and paste the code into the shape.

Pros: no hosting required, suits less tech savvy users, possibly lower latency

Cons: hard to debug. Unless the user is hosting the Farmbot WebApp and is able to somehow attach to the process, they will need to use log writes to debug the code. ESBs usually allow developers to step through embedded code blocks but that requires an IDE etc. Farmbot may need to cater for more than one language used in the embedded code block, suggest you choose python or js to start with.

This is a simple interface example just for explanation purposes, you could probably do better. Note I don’t have return arguments in this contract as they would require enhanced variable functionality in the sequence builder. Maybe it could be added later. I suggest a name value pair structure, like the input arguments below just to keep things generic.

The “farmbot” in the contract is just so an external API can load a Farmbot device to access and operate it via the current FB API interface. It’s not really needed for the embedded code block to work. There may be a better way to do this. Both shapes could hide these args from the user and the FB webApp could populate the values at run time.

{
  "farmbotContract": {
    "farmbot": [
      {
        "id": "123",
        "name": "Whitecaps Farmbot"
      }
    ],
    "args": [
      {
        "name": "Argument Name",
        "value": "Argument Value"
      }
    ]
  }
}
2 Likes
2

@whitecaps These are great ideas! I think both would be possible, although more research will be required.

For the API version: I could see this working. Adding WebHook support for certain triggers could also be useful.

For the embedded code block idea, this is actually something I had considered. Since FBOS already supports Lua today (via the ASSERT block), my idea was to add a special sequence block that had a Monaco editor and perhaps add a few extra commands to the existing Lua API (global variables that exist across sequence runs, ability to see sequence variables in current sequence, etc…). An alternative idea is to have an “advanced mode” for sequences where all the sequence blocks disappaer and there is only a Monaco editor available. Such a feature would target power users that are comfortable writing code by hand. It might be possible to add support for Javascript later, or possibly other languages that are well suited as embedded languages.

I will hold on to these suggestions for when we start work on such features- the feedback is appreciated!

2 Likes
3

Good call on using Lua it should be much simpler to implement :slight_smile:. Eventually it would be good if you could debug the sequences using the Lua editor. Might be a ways off though.

2 Likes