New week new release This update has some bug fixes, and extends the new
/pioreactor/<name>
UI page to include more data about specific Pioreactor.
24.6.10
We recommend having version 24.5.1 or later installed before updating to this version.
24.6.10 release zip download link
Enhancements
- we changed the “auto” algorithm for picking a good ir_led_intensity. We now try to maximize the intensity, up to some constraints around saturating ADCs, LED longevity, and signal. In general, we expect a higher IR intensity, but this will help with noise and detecting lower signals.
- More improvements on the Pioreactor-specific page: added charts and a logs table.
- Added a “retry failed tests” to the UI’s self-test dialog.
pio run self_test
has a new flag--retry-failed
to only retry tests that failed in the previous run (if any).- better clean up when a worker is removed from a cluster.
- reduce the mosquitto logs to reduce writes to disk and speed up connections.
- Use lexicographical ordering for all displays of workers in the UI
- This only applies to new installed images, and not updates. Updated to the latest RPI image, 2024-03-15, → linux kernel update to 6.6. Recent versions of linux have improved support for usb wifi devices.
- This only applies to new installed images, and not updates. leader-only images will install worker Python libraries.
- This only applies to new installed images, and not updates. all experiment data will be deleted when the experiment is deleted.
- performance improvements
Breaking changes
- Changed the web backend API endpoints for time-series, logs, shutdown, reboot, and plugins to be more RESTful. See docs for updated rules in the docs.
Bug fixes
- fix performing an “undo” when editing the config.ini and experiment profiles.
- fix Pioreactor v1.1 bug when change target temperature mid cycle causing the inferred temperature to change significantly.
- if a worker disconnected from the network, messages are queued in memory until the network reconnects. This has two problems. The first is that there is a finite amount of memory, and we don’t want to OOM. The second is that when the worker(s) reconnect, there is a flurry of messages. For some jobs that use messages as events, this can cause multiple triggers in quick succession. We’ve added some logic that helps avoid these situations:
- we max the queue of unsent messages to 100 (arbitrary)
- in important jobs, like temperature automations, it will only respond to “recent” messages and not old messages.