Add optional Somfy RTS receiver support (CC1101): track physical remote presses

[orren5]

Add optional Somfy RTS receiver support: track physical remote presses

Summary

Pi-Somfy currently only sends RTS commands. This PR adds an optional receiver path: a cheap CC1101 module wired to the Pi decodes real Somfy RTS frames from any existing physical remote, so pressing one — not just issuing a command through Pi-Somfy itself — keeps the app's tracked shutter position, MQTT state, and Home Assistant in sync.

Fully opt-in and backwards compatible: leave RXGPIO unset in operateShutters.conf and nothing about existing behavior changes.

What's included

1. Receiver core (receiver.py, new) — CC1101 driver, RTS frame decoder, and press-tracker. SPI is bit-banged on ordinary GPIOs (no config.txt changes or reboot needed). A TX-pause gate drops edges while Pi-Somfy is transmitting, and a self-echo filter ignores Pi-Somfy's own frames, so the receiver coexists safely with the existing TX path on the same pigpiod daemon.
2. Shutter integration — physical presses flow through the same _simulateUp/_simulateDown/_simulateStop state machine as software-issued commands (new recordExternalCommand), so position tracking, MQTT, and Home Assistant treat them identically to an app-issued command.
3. Movement-state callback — opening/closing/stopped events now fire for every trigger source, not just app-issued ones. Wired into MQTT (mqtt.py), the web UI's "Manual Operation" panel (live state + a new live-interpolated getDisplayPosition()), and the Home Assistant custom component (cover.py's is_opening/is_closing are now server-authoritative instead of only reflecting HA-issued commands).
4. Physical Remotes pairing UI — a new web UI section lists recently-heard unpaired remotes and lets you assign one to one or more shutters (backed by a new [PhysicalRemotes] config section), with unassign support — no manual config editing required.
5. "My" (intermediate) position — fixed a real bug where pressing a remote's STOP/MY button shortly after a partial move settled could be misclassified as "interrupt an ongoing move" instead of "already stopped, go to the stored My position" (root cause: comparing elapsed time against the shutter's full travel duration instead of checking actual movement state). Also added a UI for the previously conf-file-only intermediate-position value, directly in the existing Configure wizard, with a warning shown when it's unset.
6. Home Assistant add-on — new rx_gpio_pin/spi_sck/spi_mosi/spi_miso/spi_csn options; Dockerfile/run.sh/patch_pigpiod.py updates for pigpiod container quirks uncovered along the way (see below).
7. README — new "Receiver (optional)" subsection with wiring table, config keys, and pairing steps.

Notable bugs found & fixed along the way

• pigpiod's -l -m startup flags disable the pi.callback() edge-notification mechanism the receiver depends on — root cause of an initial "receiver looks completely dead" investigation.
• The HA add-on container needed /dev/vcio access plus a pigpiod DMA/mailbox patch (patch_pigpiod.py) to run inside Supervisor's sandbox.
• A full/uninterrupted move that ran out its timer naturally never fired the stopped movement event, leaving the UI stuck showing "Opening…"/"Closing…" forever.
• RawConfigParser doesn't drop removed options on re-read — the new config.RemoveValue() needed an explicit remove_option() call, not just a file rewrite.
• The MY-button misclassification in point 5 above.

Screenshots

Config changes (all additive, no migration needed)

• operateShutters.conf: new optional RXGPIO/RXSpiSCK/RXSpiMOSI/RXSpiMISO/RXSpiCSN, new [PhysicalRemotes] and [ShutterPositions] sections (auto-created on first write if missing, so upgrading an existing install in place is safe).
• HA add-on config.yaml: new optional rx_gpio_pin/spi_sck/spi_mosi/spi_miso/spi_csn.

Testing

• 78 unit tests (new/extended test_receiver.py, test_config.py, test_webserver.py), all passing; skip cleanly on a machine without pigpio/Flask/etc. installed rather than failing collection.
• Hardware-validated end-to-end on a real Pi 4 + CC1101 + real Somfy RTS remotes: frame decoding, physical-remote-triggered moves, movement-state reporting, My-position pairing, and the Physical Remotes UI all confirmed working live.
• cover.py (Home Assistant custom component) changes are verified via py_compile only — needs the homeassistant package to unit test — recommend a manual HA smoke-test before merge.

Deferred / explicitly out of scope

• A Configure-wizard deep-link straight into the Physical Remotes section during initial shutter setup.
• Prompting for the My position during remote pairing itself (it's a manual Configure-wizard step for now).
• HA event entities per physical remote (using any RTS remote as an automation trigger), long-press/tilt support, Somfy sun/wind sensor (Soliris/Eolis) support.

[MichaelB2018]

I love this idea—, his is a really neat addition, and I think it could make Pi-Somfy much more useful for people who still use their physical remotes.

A few things I'd love to see before merging is a bit more detail in the README around the hardware setup. Specifically:

• Which CC1101 module should people buy? If this is the recommended one, maybe link it directly: https://www.amazon.com/dp/B0D2TMTV5Z?th=1
• How exactly do you wire it up? (A wiring diagram or photo would be even better.)
• Step-by-step setup instructions for someone starting from scratch.
• Does this replace any of the soldering that's currently required for Pi-Somfy, or is it an additional module alongside the existing transmitter hardware? I think that's a question many users (including me!) will have.

This feature looks so clean that I'm honestly considering upgrading my own setup. 🙂 Having a more beginner-friendly hardware guide would make it much easier for others to adopt as well.

Great work on this!