Pioreactor MQTT and streamlit

[sgbaird]

Pioreactor uses MQTT by default, and it's possible to swap out the broker quite easily. However it's not designed to have a completely separate orchestrator and device. So, the most straightforward way may be to write a small MQTT interface into a Python script that runs automatically (and this MQTT interface could be using the same broker, as long as it isn't interfering with the regular operational messages). See the pioreactor forum for my discussions with the main creator related to this.

From there, it can be set up as a yeast growth demo per pioreactor docs. It will require some careful thought about how this could be a long-term demo.

Perhaps growing the yeast in ethanol with tightly sealed containers could be a way to do this, since YPD broth would likely need to be changed out semi-regularly (though this could be a human-in-the-loop Prefect triggered task).

[sgbaird]

Here is the topic link on the pioreactor forum: https://forum.pioreactor.com/t/use-with-a-different-mqtt-broker/228.

[linx5o]

Here is the topic link on the pioreactor forum: https://forum.pioreactor.com/t/use-with-a-different-mqtt-broker/228.

We want to use a remote MQTT broker (HiveMQ) with Pioreactor for secure cloud-based access, but the default setup assumes a local broker, and TLS over websockets isn't supported, limiting the UI’s functionality.

Pioreactor introduced a solution that allows custom broker configurations and successful remote communication. However, the lack of TLS support for websockets means the user can only control Pioreactor programmatically. To fully resolve this, TLS for websockets needs improvement, and a custom API could offer better remote control options without relying on the UI.

[linx5o]

We aim to solve the issue by implementing a communication layer ontop of the existing infrastructure to allow for our web connectivity. We will likely communicate via the API, however we will lose the ability to use the web interface remotely.

[linx5o]

How should we manage experiments on the PioReactor? Should the Streamlit app be able to manage experiments (create, delete, assign pioreactor)? Only allow for Streamlit app to manage the current experiment (other changes would have to be made on the UI of Pio)?

Streamlit app design, what should be included, what needs to be shown, and how much functionality?

[sgbaird]

How should we manage experiments on the PioReactor? Should the Streamlit app be able to manage experiments (create, delete, assign pioreactor)? Only allow for Streamlit app to manage the current experiment (other changes would have to be made on the UI of Pio)?

I forgot about the concept of experiments within pioreactor. The highest priority is access to the low-level commands, and less so on more orchestration-like functionality. At least, I think we could start with low-level commands and see how things go for a bit.

I think long-term, being able to trigger each of these activities and the underlying parameters (within reason) would be a good stopping point. In the simpler cases, a simple "send RPM command, receive RPM data" or "send temperature command, receive temperature data" may be a good starting point.

Worth some thought at what level in the Pioreactor stack we want to "hijack" for our custom MQTT driver (e.g., automations, CLI, Python API)

Maybe it would be worth setting up the following two experimental workflows to help guide the architecture decisions:

1. Yeast growth (though just with a single pioreactor)
2. Making jello (assume that jello powder is already present in the vial, and OK that we can only reach ~40 C temperature, and can't refrigerate yet) - https://youtu.be/3lxP1ihNV0U (the video was very relaxing 😌)

Streamlit app design, what should be included, what needs to be shown, and how much functionality?

For now, assume the same credentials block as in the other AC hardware apps. The focus should still be on "send command, receive feedback" approach, with just a subset of the original React UI is fine. A lot of the commands are one-offs and a lot of the readings are continuous feeds (i.e., similar to the fan control demo). Based on the comments above, any ideas? There's potential for having multiple pages in streamlit, though I'm not sure if that's necessary here.

Additional Resources

• https://docs.pioreactor.com/user-guide/ngrok-remote-access
• https://docs.pioreactor.com/user-guide/tailscale-remote-access
• https://docs.pioreactor.com/user-guide/intro-python-scripting
• https://docs.pioreactor.com/user-guide/available-plugins (spectrometer, temperature expansion, co2 reading, pioreactor-relay-plugin (for pinch valves), and air bubbler being the more relevant ones)

[sgbaird]

@linx5o btw, upgrade kits came (in room with 3D printer)

[linx5o]

@linx5o btw, upgrade kits came (in room with 3D printer)

awesome, i will pick it up and install it

[sgbaird]

When you start writing some code for it, do you mind opening up a draft PR on the training lab repo? You have write access to anything other than the main branch, so you don't technically need to fork (though you're welcome to if that's more straightforward for you). I think this will make it easier to have tight feedback cycles.