search

AccelerationConsortium / ac-training-lab

Codebase for controlling and managing the Acceleration Consortium (AC) Training Lab.
https://ac-training-lab.readthedocs.io/
MIT License
7 stars 1 forks source link

Pioreactor MQTT and streamlit #51

Open sgbaird opened 1 week ago

sgbaird commented 1 week ago

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 commented 2 days ago

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

linx5o commented 2 days ago

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 commented 2 days ago

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.