Simple lua read location function fails, resulting in :badarg

For some reason I’m constantly unable to fetch a location from a plant. Don’t know what I’m doing wrong.

I face the error :badarg

None working scenario:

Plant data:

Running the sequenze…

I noticed when I specify it with custom coordinates, I get a result.
OK scenario:

Also selecting a map point does work.

My code:

-- Get the value of the variable named "Location 1"
location = variable("Location 1")

-- Print the location variable's X, Y, and Z coordinates as a toast notification
toast("The location variable is set to: (" .. location.x .. ", " .. location.y .. ", " .. location.z .. ")")

Your help would be appreciated!

Hi @farmS1m

Looks to me like bug(s) lurking somewhere.

@roryaronson I can reproduce this on FBOS version 15.4.9-rc0
Will try to locate the cause.


Haven’t got very far yet but here is IEx console

1 Like

Hi @roryaronson I think this one is best fixed by the person who authored the code.
I’ve lost enthusiasm to continue chasing this issue down.

Can you reproduce this one ?

I am unable to reproduce the issue, but we’ll keep looking. My only two thoughts right now are:

  1. Perhaps the FarmBot has not synced the plant or there is some other state missing. I think this is unlikely but perhaps a reboot would fix the issue.

  2. There maybe could be something at play with an international keyboard? For example "..." vs “…”? But it looks like the code was copy/pasted from the developer docs, and I’ve tried copy/pasting both from this thread and the developer docs and it worked for me.

@farmS1m can you confirm if you copy/pasted your code from the developer docs? Can you try rebooting your FarmBot? Does this affect all plants in your account or just this one?

Can you try copy pasting the code below into your Lua block and share the result when run on that Zucchini plant? This will output the data of the plant to the logs as shown in the screenshot below.

function table_to_string(tbl, indent)
    if not indent then indent = 0 end
    local toprint = string.rep(" ", indent) .. "{\n"
    indent = indent + 2 
    for k, v in pairs(tbl) do
        toprint = toprint .. string.rep(" ", indent)
        if (type(k) == "number") then
            toprint = toprint .. "[" .. k .. "] = "
        elseif (type(k) == "string") then
            toprint = toprint .. k ..  " = "
        if (type(v) == "number") then
            toprint = toprint .. v .. ",\n"
        elseif (type(v) == "string") then
            toprint = toprint .. "\"" .. v .. "\",\n"
        elseif (type(v) == "table") then
            toprint = toprint .. table_to_string(v, indent + 2) .. ",\n"
            toprint = toprint .. "\"" .. tostring(v) .. "\",\n"
    toprint = toprint .. string.rep(" ", indent - 2) .. "}"
    return toprint

local table = variable("Location 1")
local tableString = table_to_string(table)
toast("```\n" .. tableString .. "\n```")

Today I learned you could also just use inspect() to get the plant object into the logs :sweat_smile: (albeit a little less prettily)

local plant = variable("Location 1")

Hi @roryaronson , @farmS1m I’m fired up again to chase this one :slight_smile:

Same [info] :badarg failure on my machine.

I’ve “instrumented” farmbot_os/lib/os/lua.ex at qa/tools · FarmBot/farmbot_os · GitHub
and I think there’s something unpalatable to :luerl in the vm argument.
I’ll keep looking. Edit: I’m running 15.4.9-rc1 now.
Edit: Seems related to the aliasing of variable and variables function identifiers ?
Edit: Maybe not the aliasing, but, more like any point with pointer_type: “Plant” . . . hmmm

I think I figured out something new related to this issue. I noticed when the plant has no STARTED date assigned then the error doesn’t occur! :slight_smile: Also your shared debug code snippets do only work when removed.

As soon as I switch it to planted, which assigns a date, the issue is back.

The other status like harvested, etc. do work in case I switch from planned directly to other status.
So I think the bug is somehow related to the STARTED variable.

Hope this helps you to track down the bug furthermore :mag:

Many thanks for your work @roryaronson and @jsimmonds !

Reboot has no impact on this issue.

1 Like

Okay great, I am able to reproduce the issue now! It does seem to be related to the STARTED field :thinking:

1 Like

The Great Bug Sleuth has started :smiley:

Some observations

  • Seems likely Data (user’s Point collection) and/or Configuration (settings) - related
  • Odd that not many owners are reporting this to the Forum . . . ?

@farmS1m what is your device and what version of FBOS is it currently running ?

These are my specs:

Version: v15.4.8
Model: Genesis v1.7
Firmware: v6.6.25 Farmduino (Genesis v1.7)

I have found that with many of my issues too. I think that many people are not using the system to its fullest capability (I could be very wrong here).
I know for myself FB is currently an expensive but accurate hose and even there, the reliability and repeatability issues cause me constant headaches. UTM issue, locking up control panel etc confused IF statement etc, race conditions etc.

At the moment, I manually planted the seeds, using FB to tell me where to plant it as I had seeding issues (coming off the needle as it goes into the ground), and the weeding is a little crazy as I cannot trust it to make the right decisions, so many of the advanced features such as curves and detailed plant management I just have not touched. I wonder if other people have the same experience.

Does it matter that this field is not in the Point Asset db (local or remote) ?
Edit: I guess not. The bug seems to be in the Web App code (generating incorrect parameter for the RPC)

We’ve got a fix for this one in FBOS v15.4.9-rc2 which we’ll probably get pushed to a stable release in the next 24 hours. Something with Lua did not like the type of the started_at field. Converting it to a string has fixed the issue.

FarmBot OS v15.4.9 is now released. Please let us know if this resolves the issue for you @farmS1m!

I can confirm the issue is resolved! :star_struck: Thanks once more, and looking forward to start programming some nice lua sequences.