configs.gg23.audio: routing matrix in Home Assistant instead of one room select
audio-matrix (./matrix.py) watches PipeWire (pw-dump --monitor) and
publishes per source and room an MQTT discovery switch
switch.audio_route_<source>_<room> (attributes source, speaker, kind),
grouped as one HA device per source. Sources are AirPlay (shairport's
"Shairport Sync" stream), LAN (roc-lan) and every connected Bluetooth
phone (bluez_input.*, keyed by MAC, named by its alias); a phone's switches
are removed when it disconnects. The daemon links the source node directly
to roc-<room> with pw-link and re-applies the links whenever nodes come
back (phone reconnects, PipeWire restarts).
The routes are kept per source key in /var/lib/audio-matrix/routes.json, so
a reconnecting phone gets its previous routing. A source never seen before
plays on all rooms: a freshly paired phone should just make sound.
The hub null sink, the "Audio room" select, its buttons, the audio-room
service and command are gone. WirePlumber must not link the sources itself
any more: node.autoconnect = false for bluez_input.* (monitor.bluez.rules
run after name-node.lua sets it true) and roc-lan (source.props), and
PIPEWIRE_AUTOCONNECT=false for shairport-sync, whose pipewire backend
always connects with PW_STREAM_FLAG_AUTOCONNECT. Groups without the null
sink are driven by the phone's node or PipeWire's Dummy-Driver.
The old discovery configs stay retained on mosquitto; clear them once on
acheron:
for t in homeassistant/select/audio_room/config \
homeassistant/button/audio_room_{shodan,icarus,both,off}/config \
gg23/audio-room/set gg23/audio-room/state; do
mosquitto_pub -h localhost -u gg23 -P gg23-mqtt -r -n -t "$t"
done
configs.services.ntfy: add ntfy.lassul.us as UnifiedPush distributor
ntfy.sh's free tier counts every UnifiedPush message against the
subscriber: 250 messages/day shared by all UnifiedPush apps on the phone.
Once used up it answers 429, phonetpm can no longer wake the phone and
every SSH login and deploy fails. Run our own ntfy on neoprism instead,
anonymous like ntfy.sh so app servers publish without accounts.
Rate limits: ntfy 2.29 defaults stay, except for an exemption.
- visitor-message-daily-limit is 0 (unlimited), only the request limiter
applies.
- visitor-subscriber-rate-limiting is off (ntfy.sh turns it on), so
publishes to up* topics are charged to the publisher, not to the phone.
The phone only spends requests on its subscription connections (30
allowed, the app uses one per server).
- The request limit is 60 burst, then one per 5s, per publisher IP.
Synapse on neoprism sends every Matrix push of the phone from one
address; encrypted and bridged rooms notify per message, so bridge
catch-up can exceed that. visitor-request-limit-exempt-hosts exempts
neoprism's own addresses. phonetpm daemons publish one wake per
connection and stay far below the limit.
- behind-proxy: ntfy takes the right-most X-Forwarded-For address, the
one nginx appends, so visitors are not all 127.0.0.1 and a client
cannot spoof its address.
The module enables attachments by default (attachment-cache-dir), set it
empty to keep them off. nginx settings follow ntfy's example config
(buffering off, 3m timeouts against the 45s keepalive, websockets).
No backup: the state dir (/var/lib/private/ntfy-sh) holds the message
cache (12h, disposable) and an auth db without users.
configs.riot: leave ve-riot unmanaged by networkd
Since d9ed167 networkd installed the route to the container itself.
networkd adds it as soon as ve-riot gets carrier, before the container
start script runs `ip route add 10.233.1.2 dev ve-riot`, so the script
fails with "RTNETLINK answers: File exists" and container@riot ends up
in a restart loop. Before the reboot riot had never restarted since
d9ed167, so nobody noticed.
The script's route and address come from nixpkgs' nixos-containers
module and can't be turned off without patching nixpkgs (localAddress
also sets the container side), so the networkd route has to go. Now
ve-riot is Unmanaged=yes instead, and the start script owns its
address and route. Checked against systemd 261:
- An unmanaged link gets no configuration from networkd, so nothing is
in place before the script's `ip route add` and it succeeds on every
start.
- networkd only drops foreign routes for the link it is configuring
(link_drop_unmanaged_config, CONFIGURING state). When link_drop_routes
marks foreign routes it skips routes on other interfaces, "Otherwise,
routes assigned to unmanaged interfaces will be dropped". So a networkd
restart or reload no longer touches the script's route. That was the
bug d9ed167 fixed.
KeepConfiguration=static could not keep the script's route anyway: it
only protects foreign routes with protocol static, and `ip route add`
uses protocol boot. LinkLocalAddressing=no and KeepConfiguration=static
mean nothing on an unmanaged link, so they are gone, along with the
commented-out IPForward/IPMasquerade lines. Forwarding and NAT stay in
nftables and the sysctl. No other .network file on neoprism matches
ve-riot (99-ethernet-default-dhcp needs Kind=!*), but Unmanaged=yes
also keeps a later catch-all file from taking over ve-riot.