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!

[orren5]

• This PR adds support for the CC1101 as a receiver only. The previous transmitter setup is still required. (I'm currently working on a version that will replace the transmitter with a CC1101 as well.)
• I bought this CC1101 module: https://he.aliexpress.com/item/1005005933919297.html?spm=a2g0o.order_list.order_list_main.34.56681802VxAOQy&gatewayAdapt=glo2isr
• I'll update the README to make those points clearer.
• By the way, I'm currently using this version, and it's working great. 🙂

[MichaelB2018]

This looks great! Thanks again for all the work you have put into this.

I will take a closer look through the code later today or tomorrow, and if everything checks out, I will get it merged.

I am especially excited to see this come together. It will be great for the sender to use the same hardware once this is successfully merged. Thanks again!

[orren5]

The README was updated, and some wiring diagrams were added.

[MichaelB2018]

I noticed one small issue with the graphical display. The expansion animation for the Physical Remote accordion is not completely smooth. The top part of the section seems to expand correctly, but the bottom part appears suddenly and feels tacked on rather than expanding naturally with the rest. Everything else seems fine as far as I was able to test.

[orren5]

I noticed one small issue with the graphical display. The expansion animation for the Physical Remote accordion is not completely smooth. The top part of the section seems to expand correctly, but the bottom part appears suddenly and feels tacked on rather than expanding naturally with the rest. Everything else seems fine as far as I was able to test.

The bottom part is "Recently Heard (Unpaired)"? Can you share recording or screenshots? On my side it looks good.
Physical Remotes section is build from 2 parts, upper is the already paired remotes, and the bottom is the unpaired remotes that were identified.

Screenshare.-.2026-08-01.11_41_05.AM.mp4

[MichaelB2018]

Thanks. You won’t see it in your screenshot because you have so many paired remotes that the unpaired-remotes section extends below the visible viewport.

Basically, the paired-remotes section expands properly. However, once it finishes expanding, the unpaired remotes are added instantly below it, without a smooth animation extending the section to include them.

See the attached recording. You may have to slow down the video a bit.

Recording.2026-08-01.131528.mp4