Bottom Line: Run the AOOSTAR Screen Tool in a Container—Do Not Try to apt Install It on the ZimaOS Host
The AOOSTAR WTR MAX display is controlled through a USB/serial interface, and the available Linux project is community reverse-engineered software. ZimaOS is an appliance-style OS, so generic Ubuntu instructions such as apt install build-essential are not the right host-level path.
Use the aoostar-rs Project as the Upstream Reference
The aoostar-rs screen control supports turning the display on/off, showing images and rendering sensor panels. The author explicitly warns that the protocol is reverse engineered and could theoretically crash or damage the display firmware, so use it at your own risk.
First Identify the Stable Serial Device Path
ls -l /dev/serial/by-id/
dmesg | grep -i -E 'ttyUSB|ttyACM'Prefer a /dev/serial/by-id/... path over assuming the display will always be /dev/ttyUSB0. Device numbers can change after reboots or other USB hardware is attached.
Pass Only the Required Device Into a Container
A Compose service can use a devices: mapping for the serial device, then run the aoostar-rs binary inside a normal Linux container. Start with direct device access instead of privileged: true. Docker documents device access in its Docker device mapping.
The Portainer requirements is useful if you prefer to manage the Compose stack visually.
Do Not Copy the Forum Dockerfile Literally
The community reply is directionally correct—containerize the Linux tool and pass the UART—but commands such as usermod -aG dialout $USER inside a build stage do not automatically grant the running container access to the host device. Validate the actual device permissions and container user at runtime.
Why This Is Better Than Modifying the ZimaOS Base System
A container keeps compiler packages and experimental screen software away from the appliance root filesystem. The ZimaOS package limits explains the platform boundary, and the ZimaOS app deployment provides the supported pattern.
