Work/Hardware & home

HomeControl

HomeControl runs the devices around a house from one place, starting with the patio air conditioner and a backyard weather station.

Private buildmacOSHomeKit

HomeControl, signal path Signal path: weather in, patio unit out Weather station Station cloud REST, 2 keys weather_bridge HAP port 51827 Apple Home 4 services Wall board family tablet homekit_bridge home server Patio AC Tuya, local upload pull 60 s cache 30 s HAP over LAN refresh 60 s local push every 16 s HAP over LAN port 51826 tinytuya TCP 6668, v3.5 Rain: hourly rain over 0 in trips a HomeKit leak sensor. Temperature goes out in °C. Patio: state polled every 10 s; a write waits for the unit to confirm, then the tile updates. HomeKit services Temperature sensor tempf Humidity sensor humidity Leak sensor, Rain hourlyrainin > 0 Thermostat power, mode, target °F Fan speed DP 5: 25/50/75/100 % Louvers Down DP 113 = 3, then 0 after 2.0 s Up-Down Sweep DP 113 = 1 Side-to-Side Swing DP 114 HomeControl plate 1 of 1 not to scale Built on the Beach
The patio unit is driven over the local network with tinytuya; no cloud sits in the control path.

Drag to pan the drawing.

What it does

The patio air conditioner already works from it. It talks to the unit directly inside the house, with no trip out to the internet, and the unit shows up as one tile in Apple Home on your phone, beside the lights.

A weather station in the backyard feeds Apple Home with temperature, humidity, and a rain signal. The station also sends its readings to the family wall board. HomeControl has a sibling that runs a whole building, and the two share their common parts but stay apart on purpose.

Hard problem we solved

Two projects that needed the same device code

HomeControl has an older sibling, ShulClimate, which runs the air conditioning in a whole building. A house and a building want different apps, with different schedules and rules. But both have to talk to the same kind of mini-split over the local network, and both have to show up in Apple Home. Copying that code into a second project would mean fixing every bug twice.

So we pulled the common pieces into a separate private package, smarthome-core, and both projects import it. It holds the local Tuya control, which talks to the mini-split over the LAN with tinytuya on protocol 3.5 and never calls the cloud, and the HomeKit bridge scaffolding built on HAP-python. The patio unit's local key came out of the ShulClimate work, and HomeControl reuses that same control path and the same bridge instead of keeping its own copy.

The weather station is the one place the two paths could have tangled. It feeds the wall board by local push and Apple Home through its cloud API, so each reader has one owner, and there is no duplicate. The docs also name the next hard case early. A garage opener has no open API, and it will need a relay board or a HomeKit path.

HomeControl coreregistry, plannedsmarthome-coreTuya and HomeKit codeHomeKit bridgeHAP-pythonPatio mini-splitlocal Tuya, no cloudWeather stationcloud API clientIrrigation clientbuilt, deferredApple Hometiles and automations

Where it stands

Early. The patio air conditioner works and shows in Apple Home. The weather bridge is written and needs keys to run, and the device registry and the garage opener come next.

BatteryScope

A Mac menu bar app that catches whatever is draining your battery.

 Next in Hardware & home