fix(api): sync statusbar state with flex stacker on startup and when modules are plugged in.

[vegano1]

Overview

The Flex now syncs the status bar state with the flex stacker led lights when a statusbar event is emitted; however, we need to sync statusbar state when the Flex starts and when a module is added. With this pull request, we now sync the status bar state when the robot server starts up and when a module is connected. This pull request goes in conjunction with this Opentrons/opentrons-modules#522 pull request, which fixes some fundamental issues with the UI task.

Test Plan and Hands on Testing

• Start the Flex robot with 4 stackers plugged in and make sure the status bar state is synced
• Power off the flex stackers while plugged into the Flex, push the e-stop, and the Flex statusbar will turn yellow. Power on the Flex Stackers, and their statusbar lights are set to yellow once initialized.
• Start a run and make sure the statusbar on the Flex and Flex Stackers turn green when running, blue when run is paused, yellow when in recovery.

Changelog

• Wrap get_tof_sensor_status in try catch to account TOF sensors init on the Flex Stackers
• Introduce GCacheFull ERR004 and add FS_TOF_INIT_TIMEOUT 5s timeout when getting tof sensor status
• Manually emit the last statusbar event when a module is plugged in and an instance is created.
• Added get_status_bar_enabled to check if the statusbar is enabled or not for emitting statusbar events.
• Add an initialization mechanism to the FlexStackerReader so we can monitor the TOF sensors as they initialize.
• Added _initialized_callback to the FlexStackerReader so we can sync the statusbar state once the Flex Stacker is initialized.
• In the FlexStackerReader, only poll the limit switch status, platform sensor, and motion parameters when initializing.

Review requests

• A problem I can see would be if we can't initialize the Tof sensors for whatever reason, we will be stuck always initializing. Should I add a fixed number of times to poll so we aren't stuck here?
• Anything I might be missing?

Risk assessment

Low, unreleased

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 25.43%. Comparing base (79cd268) to head (f43da3e).

Additional details and impacted files

@@           Coverage Diff           @@
##             edge   #18119   +/-   ##
=======================================
  Coverage   25.43%   25.43%           
=======================================
  Files        3017     3018    +1     
  Lines      234683   234684    +1     
  Branches    20162    20166    +4     
=======================================
+ Hits        59692    59693    +1     
  Misses     174975   174975           
  Partials       16       16           

Flag	Coverage Δ
protocol-designer	18.78% <ø> (ø)
step-generation	4.39% <ø> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[sfoster1]

Looks good on this side

[sfoster1]

so the cache just fills up? do we then get a bajillion responses once the sensor initializes? we should change something on the firmware side so this doesn't happen IMO - maybe a cheater in the sensor input queue handler that can ask some mutex what's happening

[ahiuchingau]

Makes sense!

Not in the scope of this PR, but this is making me wonder if we should try consolidate all of these info (limit switch, initialized, etc) in one single GetStatus message since we'll be polling so much so often... 🤔

[vegano1]

Makes sense!

Not in the scope of this PR, but this is making me wonder if we should try consolidate all of these info (limit switch, initialized, etc) in one single GetStatus message since we'll be polling so much so often... 🤔

I would not be opposed to that, although this is only polling while we initialize the stackers. Once they initialize we only poll the door state.

[sfoster1]

ty!