dpt-rp1-py: driving a Sony DPT-RP1 without the Digital Paper App

Electronic paper that talks to a script instead of an app

dpt-rp1-py is a Python script, more precisely a library plus a command line utility, to manage electronic paper devices made by Sony, which is the Digital Paper, the DPT-RP1 and the DPT-CP1, or by Fujitsu, the Quaderno, without the Digital Paper App. The README says it should also work for Sony's other digital paper readers.

The problem it solves is narrow and real. These readers ship with a vendor desktop application that handles pairing, transfers and synchronisation, and that application is the only supported way to get documents onto the device. If you want to script that workflow, if you want to run on a platform the app does not support, or if you simply want to see what the device protocol actually does, you need an alternative.

The alternative here talks to the reader directly. The README notes the tools have been tested on Windows, Linux and macOS, and the term reader or device is used throughout to mean your Digital Paper device.

The audience that follows from this is people who already own one of these devices and want more than the app gives: researchers moving papers onto a reader for reading, archivists handling scanned documents, and developers who want to integrate a transfer into a script. It is also a reasonable reading of the protocol itself, since the implementation is MIT licensed and the transport details are described in the documentation.

The package is on PyPI as dpt-rp1-py, the licence is MIT, and Python 3.9 or newer is required.

One pip install brings three console scripts

Installation is a single command:

python -m pip install dpt-rp1-py

Installing the package also installs dptrp1, dptmount, and the Linux USB helper dptusb. To install from source you clone the repository and run python -m pip install . from its root directory, and dptmount additionally needs the system FUSE library.

Those three entry points are defined in pyproject.toml and they do different jobs. dptrp1 is the remote control for the device, the main command line utility, and it is what the rest of this article is about. dptmount is the filesystem mount, which is where the FUSE dependency comes from, and fusepy is in the dependency list to make that work. dptusb is the Linux USB helper, a separate binary that exists because talking to the device over USB on Linux needs its own plumbing.

The package metadata is tidy. The project name is dpt-rp1-py, the description is Python package to manage a Sony DPT-RP1, the packages are listed explicitly as dptrp1 and dptrp1.cli, and the development status classifier is Development Status :: 3 - Alpha.

The dependency list explains the design. pycryptodome and pbkdf2 handle the cryptography of the registration exchange, requests and urllib3 do the HTTP, pyyaml and anytree handle configuration and the document tree, zeroconf is there for network discovery, fusepy for the mount, and tqdm for progress bars on transfers. The dev extras add pytest, responses, build and twine, which is the standard set for a package that tests HTTP interactions without a device.

Registration produces a client id and a private key

The DPT-RP1 uses SSL encryption to talk to the computer, and that requires the device to be registered with the computer first. The result of registering is two pieces of information, the client ID and the private key.

If you have used Sony's Digital Paper App on the same computer, the utility will automatically try to use the existing credentials. If you do not have the app, you use the register command.

The registration flow reads a code from the device display, and the example transcript shows the whole exchange:

$ dptrp1 register
Discovering Digital Paper for 30 seconds…
Found Digital Paper with serial number 500XXXX
Cleaning up...
<Response [204]>
Requesting PIN...
Encoding nonce...
Please enter the PIN shown on the DPT-RP1:

Discovery runs for thirty seconds, the device is found by serial number, the tool requests a PIN, encodes a nonce and then asks you to type in the PIN that is displayed on the reader. You only need to do this once.

The nonce encoding is the point where the cryptography matters, and it is why pycryptodome and pbkdf2 are dependencies rather than optional extras. The PIN is a short human-typed secret and the exchange needs to derive something that proves you are in front of the device without sending the PIN itself in a form that would be reusable.

The credentials end up in files on the command side, since the help output for the main utility lists --client-id as a file containing the device's client id and --key as a file containing the device's private key. So registration produces two files that you can back up, move to another machine, or delete to force a fresh pairing.

Discovery windows, the address flag, and the USB caveat on Linux

The command line utility requires a connection to the reader via WiFi, Bluetooth or USB, and each of those has a wrinkle that the documentation spells out.

The first is auto discovery. The --serial option takes a device serial number for auto discovery, and the help text warns that auto discovery only works for some minutes after the Digital Paper's Wi-Fi setting is switched on. That is a limitation of the device's own advertisement rather than of the tool, and it means the discovery window has to be caught while the device is awake and on the network. The --addr option takes a hostname or IP address of the device and disables auto discovery entirely, which is the reliable route for a script.

The second is USB. The USB connection works on Windows and macOS but may not work on a Linux machine, which is why dptusb exists as a separate Linux helper, and it is a warning rather than a promise.

The third is WiFi configuration, and it is a genuine hardware constraint. If you want to use a WiFi connection, the reader and the computer must be on the same WiFi network. Some versions of the DPT-RP1 do not allow you to connect to a WiFi network from the device itself, and in that case you have to use Bluetooth or USB first to configure the network with the wifi-add command, or update the firmware with update-firmware.

The wifi-add command takes a path to a WiFi configuration file, and the README points at a sample configuration where you put your network name in the ssid field and your password into the passwd field, leaving the other fields alone. The repository ships three of those samples, wifi_2.5G.json, wifi_5G.json and wifi_del_2.5G.json.

Uploading, downloading, and the Document/ path that is mislabelled

The everyday commands are short. Uploading a document takes a local path, and if you give only that, the file is uploaded to Document/:

$ dptrp1 upload ~/Desktop/scan.pdf
$ dptrp1 display-document Document/scan.pdf 2

The second of those opens the second page of a document on the reader, which is the kind of thing you can do from a script to page through a document on the device.

The path handling has a trap that the README explains at length. The root path for the DPT-RP1 is always Document/, which is misleadingly displayed as System Storage on the device. So to download a document called file.pdf from a folder called Articles, the correct command is dptrp1 download Document/Articles/file.pdf.

The other commands are equally short. dptrp1 list-documents prints the documents on the device with their paths under Document/. dptrp1 help <command> gives the usage for a specific command, and dptrp1 with no arguments lists the implemented commands. The README names the most important ones for everyday use as register, help, upload, download and sync.

There are also global flags that matter for scripting. The --yes flag answers confirmation prompts automatically for non-interactive runs, and --quiet suppresses informative messages. So a scheduled job is dptrp1 --yes --quiet upload, and the device never blocks on a question nobody is there to answer.

Tests that need no reader, and the gap they cannot close

The test suite is written so that it runs without hardware, and the README is explicit about what that does and does not buy you.

The tests exercise cryptographic helpers, registration messages, authentication, document traversal and downloads, CLI help, and mDNS parsing. HTTP responses are simulated, so no reader, credentials, USB access or FUSE mount is needed. The POSIX USB tests are skipped on Windows.

The gap is stated in the next sentence, and it is the sentence to read twice. Real pairing, synchronisation and filesystem mounts still need validation against a physical device.

So the suite proves the protocol logic and the request shapes are right, and it cannot prove that the device accepts them. The registration flow, the nonce exchange and the mount are exactly the parts that can only be confirmed with the hardware in your hand, which is why a simulated registration test is evidence about the code and not about the reader.

The continuous integration setup is thorough. CI runs the tests on Python 3.9 to 3.14 on Linux and Python 3.12 on Windows and macOS. It also builds an sdist and a wheel, validates their metadata, and runs the suite against the installed wheel outside the checkout, which catches packaging errors that a test run from the source tree never would. Publishing waits for those checks and uses the existing PYPI_API_TOKEN repository secret.

For development, the README gives a virtual environment recipe that installs the editable package with its development tools:

python -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[dev]'
python -m pytest

And the release check is two commands, building the distributions and then validating them with twine check --strict.

Version 0.1.x, an alpha label, and a project with a slow release line

The project is small and the numbers say so. The version in pyproject.toml is 0.1.21, the development status classifier is Alpha, and the newest tagged release is v0.1.20 from 2026-10-06, so the working tree is one patch ahead of the last tag. The last push to the repository was on 2026-10-08.

The release history before that shows a slow line: v0.1.18 on 2025-10-14 and v0.1.19 on 2025-11-14, then a nine month gap to v0.1.20. A project that publishes a handful of patch releases a year, with long quiet stretches in between, is telling you something about its maintenance model. It is a maintained tool for a niche device, not a fast moving project, and the absence of a homepage means the README and the issue tracker are the whole of the published documentation.

The MIT licence is the simplest possible case for reuse, and the project has no other legal encumbrance listed beyond the standard file. The authors listed in the metadata number eleven, which fits a project of this kind: a core maintainer with a device and a set of contributors who each own one of the supported readers.

The honest summary is that this is a well structured, well tested, narrowly scoped tool that does one job properly. The parts of the job that hardware makes impossible to automate are still manual, the version line is young, and the most likely support question is about a specific reader model and a specific firmware version, which is the kind of question the issue tracker is for.

Editorial conclusion

dpt-rp1-py suits the owner of a Sony or Fujitsu electronic paper device who wants to move documents on and off it from a script, or who works on Linux where the Digital Paper App is not an option, since the package registers the reader, transfers files and mounts the filesystem without it. It does not suit a workflow that needs a polished desktop application, because this is a command line tool and a library, and it does not suit anyone who wants a device feature the utility has not implemented, since the command list is fixed and self documented through dptrp1 help. Check three things before you rely on it: that your transport works, since USB is documented as possibly not working on Linux, that you can accept the alpha status and the version 0.1.x line, and that the FUSE mount has the system library available if you intend to use it. The last push to the repository was on 2026-10-08 and the newest tagged release is v0.1.20 from 2026-10-06.

Frequently asked questions

Official sources

1. Issues
2. janten/dpt-rp1-py on GitHub
3. License: MIT
4. README
5. Releases