Network

Overview

Network rack with an old switch in the middle of two patch panels

The network consists of a cable modem feeding an OpenWrt router/AP, which in turn uplinks to the mezzanine Ubiquiti managed switch. From there, connections run to two loft patch panels: one Blue, one Grey. Each network drop in the space has a corresponding Blue and Grey jack; only some are wired through to the switch, and only some are currently used. The main table has a small managed switch.

Blue and Grey cables are functionally identical. The colours reflect physical routing rather than logical separation.

Static Devices

Most fixed equipment uses static DHCP leases on the OpenWrt router. If you add a static IP address, give it a static DHCP lease on the openwrt router, even if the device doesn't use dhcp. These are the main devices:

Device	IP Address
OpenWrt loft router	192.168.0.1
Home Assistant	192.168.0.2
OpenWrt table AP	192.168.0.3
Lazzor	192.168.0.4
OpenWrt lobby AP	192.168.0.6

Patch Panel Map

Cabling map: Grey (left, top) ↔ Blue (right, bottom)

Grey device / location	Switch port	Label	Switch port	Blue device / location
Lobby black cable (unterminated)	1	1 Laser Loft	2	Lobby AP
Lazzor	3	2 Laser Room	4	Laser room computer
(unused)	5	3 Craft Shelf Arch	6	(unused)
(unused)	7	4 Craft Shelf Top	8	Payphone
(unused)	9	5 Cubesville	10	Denon AVR
Game of Life cube	11	6 Main Room Beam Front	12	Main table Ethernet (phone, switch)
(unused)	13	7 Main Room Beam Back	14	Main Room AP
(unused)	15	8 Tool Town L (breaker panel)	16	Sherline computer
(unused)		9 Tool Town R (shopbot)		(unused)
(unused)		10 Mezzanine R (unterminated)		(unused)
(unused)		11 Mezzanine L (unterminated)		(unused)
(unused)		12 Main Room Couches (unterminated)		(unused)
Unconnected Grey ↔ Blue runs: 13–24

Router

Port	Connected device
WAN	Spectrum modem
LAN 1	(unused)
LAN 2	Mezzanine switch (uplink)

Mezzanine Switch

The ports on the left are for the patch panel.

The SFP ports on the right are:

17 Home Assistant (purple) 18 Uplink (yellow)

The switch is managed through the Ubiquiti app in Home Assistant

ToDo

• OpenWRT setup
• Ubiquiti setup

Dynamic DNS

NYC Resistor has dynamic IPv6 DNS for selected hosts under:

*.dyn.nycresistor.com

The public IPv6 prefix assigned by Spectrum changes every few weeks. Hosts on the Resistor LAN have stable IPv6 host IDs, so when the /64 changes we update the network prefix of all published AAAA records while preserving the lower 64 bits.

The low 64 bits of each AAAA record are persistent. Most of these correspond to hostid entries configured in OpenWrt.

The initial AAAA record in deSEC must therefore contain the correct host ID. Future updates only replace the /64 prefix.

For example:

espressomachine.dyn.nycresistor.com
    2603:7000:1234:5678::cafe

The hostid is cafe

If the ISP changes our prefix from:

2603:7000:1234:5678::/64

to:

2603:7000:90ab:cdef::/64

the DNS record becomes:

2603:7000:90ab:cdef::cafe

Adding a host

1. Give the device a stable IPv6 host ID in OpenWrt.
2. Create its AAAA record in the dyn.nycresistor.com deSEC zone with the correct host ID.
3. Add its FQDN to /config/ddns-hosts.txt.
4. Run the Resistor DDNS automation manually from Home Assistant.
5. Check that the resulting AAAA record contains the current Resistor /64 and the expected host ID.

DNS provider

dyn.nycresistor.com is delegated separately from the main nycresistor.com DNS zone and is hosted by deSEC. This means the dynamic-DNS credentials cannot modify unrelated Resistor DNS records.

The credentials are in the usual place.

Home Assistant general setup

Home Assistant updates the prefix at deSEC through the "Resistor DDNS" automation. It runs on boot, on prefix change and weekly.

Hosts which should be published are listed one per line in /config/ddns-hosts.txt. Blank lines and lines beginning with # are ignored. Changing this file does not require restarting or reloading Home Assistant.

Do not add arbitrary LAN devices here just because they have a stable IPv6 address. This list is for things which should actually have a public DNS name.

Update process detail

Home Assistant has sensor.resistor_ipv6_prefix, a command-line sensor which looks directly at interface end0:

ip -6 -o a s dev end0|awk '$4~/^[23]/{split($4,a,":");print a[1]":"a[2]":"a[3]":"a[4]"::/64";exit}'

Home Assistant then has a shell_command.update_resistor_ddns command.

It:

1. reads /config/ddns-hosts.txt;
2. removes comments and blank lines and joins the names with commas;
3. sends one batched request to deSEC;
4. passes sensor.resistor_ipv6_prefix as the new IPv6 /64;
5. tells deSEC to preserve IPv4 records (currently none).

The deSEC API token is stored in Home Assistant's secrets.yaml, not in an automation.

The command uses roughly:

hosts="$(grep -Ev "^[[:space:]]*(#|$)" /config/ddns-hosts.txt | paste -sd, -)"

curl -fsS \
  -H "Authorization: Token verySecret" \
  --get \
  --data-urlencode "hostname=$hosts" \
  --data-urlencode "myipv4=preserve" \
  --data-urlencode "myipv6=$prefix" \
  https://update.dedyn.io/

Batching all hosts like this matters: an earlier setup updated records individually and ran into deSEC rate limiting.

The Resistor DDNS Home Assistant automation runs when:

• sensor.resistor_ipv6_prefix changes;
• Home Assistant starts, after a short delay;
• once a week as a sanity/reconciliation update.

When Spectrum gives us a new IPv6 prefix switch it causes:

OpenWrt receives new IPv6 prefix
        ↓
HAOS receives address in new /64
        ↓
sensor.resistor_ipv6_prefix changes
        ↓
Resistor DDNS automation runs
        ↓
one batched deSEC request
        ↓
all published AAAA records get the new /64

The periodic update is only a fallback in case a prefix-change event was missed.

ESP32 near elevator door

(TODO new page dedicated to space access controls)

Currently, there's a m5stack ATOM-Lite (very small) ESP32 board hanging above the elevator door/intercom/laser loft stairs area. This serves:

• Elevator door sensor inside(?) maglock housing (it is a reed switch)
• Keypad in elevator shaftway (a direct wired 4x3 key matrix on the end of a cat5 cable)

ATOM-Lite publishes these into HA, where the sensor states are used in various automations related to locks. I think it publishes the elevator door sensor state over Bluetooth (why?) and publishes codes entered into the keypad over MQTT. See the config in ESPHome though.

Wiring (rat nest) "diagram":

[Pictures are worth 1000 words, but only if you can upload them. --Ed]

jumpers:

• ATOM-Lite GND <=> WAGO <=> white twisted pair a terminal <=> elevator door sensor (reed switch)
• ATOM-Lite GPIO21 <=> white twisted pair other terminal <=> elevator door sensor (reed switch)
• ATOM-Lite GPIO 23 <=> grey jacket cat5, green-white <=> keypad terminal 5 (col 3) [2]
• ATOM-Lite GPIO 19 <=> grey jacket cat5, green <=> keypad terminal 6 (col 2)
• ATOM-Lite GPIO 22 <=> grey jacket cat5, brown-white <=> keypad terminal 7 (col 1)

breadboard:

• ATOM-Lite 3v3 <=> 1 kΩ pull-ups to each of GPIO 25,32,26,33 [1]
• ATOM-Lite GPIO 25 <=> pull-up & grey jacket cat5, blue-white <=> keypad terminal 1 (row 1) [2]
• ATOM-Lite GPIO 32 <=> pull-up & grey jacket cat5, blue <=> keypad terminal 2 (row 2)
• ATOM-Lite GPIO 26 <=> pull-up & grey jacket cat5, orange-white <=> keypad terminal 3 (row 3)
• ATOM-Lite GPIO 33 <=> pull-up & grey jacket cat5, orange <=> keypad terminal 4 (row 4)

[1] Without these strong external pull-ups, the ~2meter twisted pairs run to the keypad is too noisy for the matrix scanning to work. Ask me how I know. 3.3 kΩ is better than the 45 kΩ (?) on-chip pull-ups but still not enough.

[2] here, 4 rows and 3 cols of the physical keypad layout; the ESPHome config calls the physical columns "rows" (pins configured as strobed outputs) and calls the physical rows "columns" (pins configured as inputs)

"Shelly" near elevator door

Switches 12v power to the elevator door maglock...