Lua Assertion read_pin always returns 1, making programmatic tool verification unusable about farmbot_os HOT 5 OPEN

@mdingena It is possible, but it is not documented and I have not done a lot of testing on it. The reason this function exists at all is complicated and historic. I am going to show you how, but please do not file bug reports when the API changes without notice. This is an undocumented feature and the reason we have not added it to the docs is that the API is kind of ugly and I would prefer to ship a long-term solution.

ANALOG = 1
DIGITAL = 0
pos = get_position()
pin = 13

return new_sensor_reading({
    mode = DIGITAL,
    pin = pin,
    value = read_pin(pin),
    x = pos.x,
    y = pos.y,
    z = pos.z
})

⚠️ Again, for anyone that discovers this thread via search, DO NOT FILE BUG REPORTS. This API will change without notice and we will not provide migration support when it eventually breaks. Breaking changes are guaranteed. ⚠️

from farmbot_os.

Thanks for the bug report @mdingena and particularly for the screenshots (they help us understand the problem better). Gabriel has started work on the UI fixes, which will be deployed shortly. I will investigate the read_pin matter.

from farmbot_os.

I've done some troubleshooting. I've got both a Read Sensor command and an Assertion command in the tool verification sequence. I do this because I want a sensor data point and also want to make a programmatic decision based on the value.

I had a hunch that reading the pin twice in rapid succession was causing issues. I've added a Wait command (2000 ms) but the Assertion still goes to "failure" when the tool is actually attached. I found that manually reading the tool verification pin after this sequence incorrectly goes to "failure", the reading is incorrect also, and it requires me to detach the tool by hand and read the pin manually so that it correctly reads the tool is not there before it will correctly read attached and detached states.

Then I removed the manual Read Sensor command from the sequence altogether. And lo and behold, it will now consistently read the tool verification pin correctly.

It seems that:

1. Using Read Sensor and Assertion with read_pin in the same sequence can be incompatible in some scenarios.
2. After incorrectly reading the pin, it becomes "stuck" in that mode until you modify the situation so that what it's stuck on is what it's going to read. I.e. when it thinks the tool is not attached, you need to detach the tool and re-read the pin for it to become "unstuck" on "not attached".

from farmbot_os.

Thanks for the update @mdingena. That's very helpful for isolating a root cause and glad you were able to find a workaround in the interim.

from farmbot_os.

Is it possible to add a "sensor data point" via Lua? Then I can read the pin once, and then save it both as a data point and return it for the Assertion success/fail triggers.

If fixing the bug is too hard to address in the short-term, an interim solution could be that you detect if both a Read Sensor and Assertion block containing read_pin are present in the same sequence, and prevent the sequence from saving, or something.

from farmbot_os.