DeviceWriter.write() returns early with "Encryption on writes is not yet supported", and bluetti-write refuses -e. But the encrypted session DeviceReader already establishes carries write commands without modification: WriteableRegister is a DeviceRegister, so DeviceReader._async_send_command() encrypts it with the secure key and the response comes back through the existing notification/decrypt path like any read.
Proof on a real encrypted device (Handsfree 2, iot v2 — see PR #83): a ~60-line DeviceReader subclass that connects, waits for encryption.is_ready_for_commands, then sends build_write_command(field, value) through _async_send_command toggled ctrl_dc on→off with valid MODBUS echoes and matching read-back state both times.
If you're open to it I'd contribute this as a PR — either as encryption support inside DeviceWriter (needs the notification handler + handshake plumbing moved somewhere shared) or as the lighter write-through-reader path. Which shape would you prefer?
🤖 Generated with Claude Code
DeviceWriter.write()returns early with "Encryption on writes is not yet supported", andbluetti-writerefuses-e. But the encrypted sessionDeviceReaderalready establishes carries write commands without modification:WriteableRegisteris aDeviceRegister, soDeviceReader._async_send_command()encrypts it with the secure key and the response comes back through the existing notification/decrypt path like any read.Proof on a real encrypted device (Handsfree 2, iot v2 — see PR #83): a ~60-line
DeviceReadersubclass that connects, waits forencryption.is_ready_for_commands, then sendsbuild_write_command(field, value)through_async_send_commandtoggledctrl_dcon→off with valid MODBUS echoes and matching read-back state both times.If you're open to it I'd contribute this as a PR — either as encryption support inside
DeviceWriter(needs the notification handler + handshake plumbing moved somewhere shared) or as the lighter write-through-reader path. Which shape would you prefer?🤖 Generated with Claude Code