Brivis

A Homey app for Brivis ducted gas heating and evaporative cooling, controlled over the LAN via the Brivis Touch Wi-Fi controller module. The same hardware was previously sold as the Rinnai Touch Wi-Fi module and speaks the same protocol.

The app is named for the vendor and its single driver for the device, per the App Store guidelines on naming.

There is no public SDK. The protocol layer is adapted from homebridge-rinnai-touch-plugin (MIT). See lib/rinnai/NOTICE.md for attribution and the list of local changes.

Devices

Touch Wi-Fi Zone, one device per zone controller, modelled on the physical wall controllers, which are peers. Each exposes its own target and measured temperature plus the unit-wide controls (operating mode, circulation fan, fan speed, and the pump on evaporative systems). Changing a unit-wide control on one zone propagates to the others, exactly as it does between the wall controllers. Pairing discovers the module by UDP broadcast and lists the installed zones.

Four read-only statuses report what the system and wall controller are doing. Homey reflects them but never writes them, even where the protocol would allow it:

Status	Meaning
Actively heating/cooling	Whether the zone is calling for heat/cool now, as opposed to being switched on
Control mode	Following the schedule, or a manual setpoint
Schedule override	None, Advance or Operation, so an Advance pressed at a wall controller is visible
Schedule period	Wake, Leave, Return, Pre-sleep or Sleep. Heat/cool only; unknown in evap mode

"Actively heating/cooling" prefers the per-zone field on multi-setpoint hardware and falls back to the unit-wide flag otherwise, because the per-zone path does not exist on single-setpoint systems. In evaporative mode neither field tracks the cooler, so a zone counts as active while the cooler's fan or pump is actually running (including pre-wet and Manual fan-only) and, on multi-setpoint systems, the zone is switched on.

Evaporative mode

The cooler has no target temperature, so the setpoint is removed while the unit is in evaporative mode, and the controls follow the Networker's own two ways of running it:

Cooler control	You set	The Networker sets
Manual	fan speed, pump	nothing
Auto	comfort level, 1 (warmest) to 16 (coolest)	fan, fan speed, pump

Every control stays on screen in both. One that does not apply reads as unknown or shows what the unit is doing, and changing it is refused, so Homey puts it back: the comfort level in Manual, and the fan, fan speed and pump in Auto. In Auto the fan and pump show whether they are actually running. Switch between Auto and Manual to take them over. The module does not report the fan speed it picks in Auto, so it reads as unknown. A Pre-wetting status covers the few minutes in which the pump wets the pads before the fan comes on, whether the cooler started it in Auto or you turned the pump on in Manual. In Manual the fan control keeps showing what you set, though the fan waits for pre-wet to finish. Cooler control is shown in place of the control mode status, which reads the same field in the unit but means following a schedule in heating/cooling.

On/off is mode-aware

In evaporative mode on a multi-setpoint system each zone has its own cooler, so the toggle switches that zone alone. Everywhere else it switches the whole system, and the sibling zones follow. The label tracks this, reading "Zone Power" or "System Power" accordingly.

In heating/cooling, on/off and the circulation fan are two views of one tri-state field in the unit, so they behave as a pair:

On/off	Fan	Unit
on	off	heating/cooling
on	on	fan only
off	any	off

Turning the fan on therefore switches the unit from heating to fan-only, and turning it off returns it to heating rather than shutting it down. Evaporative mode has genuinely independent controls and behaves as expected.

Keeping in sync

The module accepts one TCP client at a time and only streams status while connected, so all zone devices share a single connection owned by app.ts. It closes 1.5s after the request queue drains, which leaves the module free roughly 80% of the time. Holding it longer is what makes the official phone app report the unit as busy.

app.ts polls every 15s to catch changes made at a wall controller or in the phone app, logging a one-line snapshot of the full state on each poll.

Two failure modes are handled deliberately:

• While the system is off, the module stops reporting the per-zone operation blocks ({mode}.Z{zone}O) that hold the target temperature, control mode and schedule override. Setpoints still apply, but cannot be echoed back until the system is on, so those commands are sent once and logged as unconfirmed instead of being retried or failed.
• After three consecutive failed polls (~45s) the devices are marked unavailable rather than serving stale values, recovering on the next successful poll. A command the module never acknowledges (three attempts) fails the capability, so Homey reverts rather than showing a setpoint the unit never took.

Flow cards

Card	Trigger	Condition	Action
Actively heating/cooling	changed	is / is not	n/a, read-only
Fan speed			set to 1 to 16
Cooler control		is / is not	set to Auto or Manual
Comfort level			set to 1 to 16, in Auto only

On/off, the operating mode (Homey's thermostat mode: heat, cool, evaporative or off) and the temperatures are standard Homey capabilities, so Homey provides their cards automatically. The three schedule and control-mode statuses have no cards yet.

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗