Lua Assertion read_pin always returns 1, making programmatic tool verification unusable

[mdingena]

I believe since upgrading to FBOS 13.0.1 (but uncertain if 100% correlated) my Assertion read_pin function always returns one, causing my "tool mount/unmount" sequences to fail and abort the parent sequence.

I had believed my UTM got water inside (I have a Genesis v1.2, so the UTM is two parts), but I took it apart and it wasn't the issue. Furthermore, manually reading the Tool Verification pin from the Sensors screen has always been proven to be 100% accurate when manually testing it and attaching or detaching a tool by hand.

Because manually reading the pin works everytime, I can only conclude that recently the read_pin function has become bugged.

Here is my implementation:

Also, please note that the Assertion IF TEST FAILS filter is empty and shows nothing when clicked. I'm not sure what was there when I created the sequence, and maybe this is related? The same goes for the Send Message TYPE and checkboxes. I'm certain those checkboxes had labels before, for sending messages to email, toast, etc.

[RickCarlino]

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.

[mdingena]

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".

[RickCarlino]

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.

[mdingena]

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.

[RickCarlino]

@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. ⚠️