Move towards less dependencies on the Web api for basic called and more towards and offline mode for daily operations

[mvillion]

Hi

A number of the reliability issues come from having to go to the internet to get basic details such as where are my plants when in my mind this basic information should be available to be obtained from local databases.

local points = api({method = “GET”, url = “/api/points”})

There are a number of benefits in a less dependent architecture.

1. Less server load for FB inc therefore less operational cost.
2. A new market place being able to sell to ‘preppers’ for when the internet goes down.

I tend towards the latter of the two and I want to be able to code and operate my FB system off-line if I have to but really keep using it whilst the internet is still available.

My watering sequence ‘Water all’ failed to execute in the internet connection get disrupted. This is not ideal and reflects as direction of architecture that is dependent on the mothership.

[jsimmonds]

@mvillion

I tend towards the latter of the two and I want to be able to code and operate my FB system off-line if I have to but really keep using it whilst the internet is still available.

That solution is available. Just self-host the the Web API on your private network.

[mvillion]

LOL. That is not quite what I meant - But thanks…

That is still dependent on an external system, just less remote.

[roryaronson]

You are right that the vast majority of what FarmBot can do should be possible to do offline. This is true today (and has been since day 1) for sequences using any of the basic sequence commands and for core FarmBot tasks involving pretty much any of the other resources in the app such as events, regimens, plants, points, weeds, groups, tools, image processing, etc.

However, offline support isn’t currently as comprehensive when using the Lua environment. While many Lua functions are just aliases for basic sequence commands and do work offline, there is a good number of the helper functions that currently require the API including: api(), dispense(), water(), mount_tool(), dismount_tool() and more.

This issue has been exacerbated by the fact that we have published featured sequences (some of which are also included by default on new accounts) that use some of these online-only Lua functions.

The solution is to make fewer of these Lua helper functions rely on the API, which will require some work in FarmBot OS to expose the required data using a local method. In some cases, it is a single piece of key info that is needed, which might be fairly quick for us to implement.

For example, verify_tool() currently uses the API just to get the name of the currently mounted tool just to send a success message.

local mounted_tool = api({
      method = "get",
      url = "/api/tools/" .. mounted_tool_id
  })
  send_message("success", "The " .. mounted_tool.name .. " is mounted on the UTM")

If we can add a function to get the tool name locally, we can update verify_tool() and eliminate the need for a connection when it is called.

[mvillion]

Fantastic.
I am so glad there has been consideration of this. I am also pleased that it is a direction of travel you have considered. I think there is huge value in the web interface for the programming of the sequences and general goodness but then the ongoing execution should just be local which improves reliability (which as you know is my focus).

On that, my celebration of the fix with the washers for the water head mounting to the UTM was premature. It did fix it for a week, so I have a week or so of perfect running, but the UTM connection issue is back, so I will attempt other approaches to address that.

You will see that I uncovered a bug with the dismount_tool() routine that jsimmond completely dismantled. Nice work there. My frustration with what I was experiencing was misguided - all I knew was there was a dependency on the FB being online to execute a sequence, however there was an online component at play with the dirty worker routine doing a data quality check and resolving the incorrect parameter set by dismount_tool() which caused the need to insert a 5 second delay to make a sequence work.