# v1.5.4

Release date: 2026-04-25

`v1.5.4` is the edge deployment and long-horizon study release.

This release takes the Raspberry Pi and UNO Q story from a strong booth demo into a more complete edge research platform: one-command remote deployment, offline recovery bundles, Pi-local reproducible studies, and multi-day long-study workflows with resume and storage-safety support for real unattended runs.

## Highlights

### 1. One-command remote Raspberry Pi deployment

The SDK can now provision and start a remote Raspberry Pi from a workstation with a single command:

```bash
iints edge deploy \
  --host raspberrypi.local \
  --user pi \
  --local-output-dir iints_pi_demo \
  --remote-dir ~/iints_pi_demo \
  --board raspberry_pi \
  --scenario-profile expo_hot_start
```

Key additions:

- `iints edge deploy`
- `iints edge remote-status`
- `iints edge remote-reset`
- `iints edge remote-stop`
- SSH retry and timeout controls
- dry-run and verbose deploy modes

The deploy flow is now much more practical for real devices:

- the remote Pi generates its own edge project in-place
- service files and scripts match the remote filesystem instead of baking in local paths
- kiosk, autostart, and watchdog setup can be pushed in the same flow
- UNO Q bridge support can be included during deploy

This makes the edge workflow much less fragile for Maker Faire, classrooms, and lab benches.

### 2. Raspberry Pi Connect is now the recommended remote access story

The SDK docs and remote flow now align around a safer default:

- keep the live dashboard bound to `127.0.0.1`
- use Raspberry Pi Connect for remote screen and shell access
- avoid casually exposing the patient dashboard on the LAN

This gives the Pi a cleaner “remote booth” story without weakening the security posture of the live patient service.

### 3. Offline install bundles for unreliable networks

You can now build a transportable edge bundle for expo or field use:

```bash
iints edge offline-bundle --output iints_offline.tar.gz
```

The bundle includes:

- an offline `wheelhouse/`
- an install helper script
- an offline install guide
- a prepared edge project scaffold

This is especially useful when:

- venue Wi-Fi is unreliable
- a Pi needs to be recovered quickly from USB media
- the demo machine must be reinstallable without internet access

### 4. Pi-local reproducible studies

The edge runtime can now run reproducible multi-seed studies directly on a Raspberry Pi:

```bash
iints edge study \
  --algo algorithms/example_algorithm.py \
  --seeds 1,2,3,4,5 \
  --output-dir results/pi_study
```

Generated outputs include:

- protocol and matrix artifacts
- study summaries
- edge runtime metadata about the device and run context

This strengthens the scientific story for EUCYS and similar work: the edge hardware is no longer only a live demo target, but also a reproducible experimental endpoint.

### 5. New long-horizon edge study engine

The SDK now supports multi-day and multi-week edge studies from a single configuration file:

```bash
iints edge long-study \
  --config edge_long_study.yaml \
  --project-dir .
```

New commands:

- `iints edge long-study`
- `iints edge study-snapshot`
- `iints edge study-export`

The new long-study flow supports:

- weekday schedules with different daily profiles
- multiple algorithms and seeds
- export-friendly file-based study storage
- automatic study summaries and manifests
- study archives that can be moved to another machine for analysis

This makes the Pi much closer to a real unattended research rig instead of a short demo-only runtime.

### 6. Safer long runs on Raspberry Pi storage

Long studies now have a much better storage model for real Pi hardware.

The default generated `edge_long_study.yaml` now uses:

- USB SSD-ready output paths such as `/media/pi/usb_ssd/results/long_study`
- scratch-first execution in `/tmp/iints_edge_long_study`

That means:

- intermediate writes do not hammer the SD card directly
- completed day outputs are synced into the durable study directory
- the resulting study remains easy to export and inspect as normal files

For unattended edge studies, this is a major robustness improvement.

### 7. Resume support after reboot or interruption

Long studies can now continue cleanly after a restart:

```bash
iints edge long-study \
  --config edge_long_study.yaml \
  --project-dir . \
  --resume
```

The resume logic inspects `long_study_index.csv`, finds the last contiguous completed day, and resumes from the next one. This avoids wasting completed work after a reboot or power interruption.

### 8. New day profiles for more realistic weekly schedules

The live patient runtime now includes more day-scale profiles for long studies and booth demos:

- `school_day`
- `relaxed_day`

These complement existing profiles such as `sport_day` and `bad_carb_count`, making rolling weekly schedules more realistic and easier to describe in study configs.

### 9. Edge documentation is now much stronger

The edge documentation has been expanded with:

- a dedicated remote deploy guide
- clearer Raspberry Pi setup guidance
- updated command reference coverage
- improved Maker Faire notes for Pi and UNO Q paths

This release is noticeably easier to adopt if you are coming in fresh and trying to get from laptop to working Pi without reverse-engineering the repo.

## Validation

Before release, the updated SDK passed:

- `python3 -m pytest tests/ -q`
  - `342 passed, 4 skipped`
- `flake8 .`
- `mypy src/iints/`
- `mkdocs build --strict`
- `python3 -m build`

That validation included the new edge deploy, offline bundle, edge study, and long-study paths.

## Upgrade

Full workstation:

```bash
python -m pip install -U "iints-sdk-python35[full,mdmp]==1.5.4"
```

Edge / Raspberry Pi:

```bash
python -m pip install -U "iints-sdk-python35[edge,mdmp]==1.5.4"
```

## Practical takeaway

`v1.5.4` makes the edge SDK much more credible as both:

- a public-facing demo system for Raspberry Pi and UNO Q
- a serious long-horizon research platform that can run, preserve, resume, and export studies from the edge itself

That combination is what makes this release important: it improves reliability and presentation at the same time, without losing the scientific workflow.
