Different apps. One home.

I wanted to stop switching apps for every device. Heating and cooling in the same room belonged to separate apartment and Samsung systems.

A new installation could use Matter-compatible products. I instead reused the installed equipment, NAS and communication adapters to limit replacement costs. I have not measured a specific saving.

Apple Home now controls lights, heating, ventilation and Samsung cooling, with entrance video and working unit and shared-entrance controls. Four rooms have combined heating and cooling tiles.

The NAS runs Homebridge. Separate USB-RS485 adapters handle general controls and shared-entrance control. Video uses a pair of passive baluns, BNC connectors and an AHD2NET encoder.

EXTDEV1 carries lighting, heating and ventilation to the NAS. The kitchen monitor’s SUB2 control pair uses a separate adapter, while its video pair reaches the NAS through baluns, an encoder and LAN. Samsung AC connects through the SmartThings cloud API.

To adapt this setup, first identify the wallpad and terminals, whether a kitchen monitor is present, and whether the AC exposes a usable API. Similar connectors can carry different signals.

I first listened to the existing bus without transmitting. Then I changed one thing at a time, such as a light or heating setpoint, comparing idle and action traffic to distinguish room identifiers, commands and state.

I repeated actions and their opposites, refining the analysis code with an AI agent. Reproducing a command included checking the physical device and its returning state.

In my installation, EXTDEV1 uses blue 1B to B− and white 1A to A+, at 9600bps, 8N1. I kept the existing bus and added a parallel branch, leaving GND unconnected in this setup. Actual terminal and adapter photos accompany the diagram.

My AC is a SmartThings model without Matter support. I connected the SmartThings developer API to Homebridge on the NAS, using OAuth authentication and token refresh, REST state queries and device commands.

I added combined-climate code that sends cooling requests to SmartThings and heating requests to the wallpad RS485 service. One room tile offers both modes, with a sequence that switches the opposite system off first.

This path depends on the internet and SmartThings cloud. Adding a local AI model does not make the AC connection itself offline.

The general-device bus did not provide shared-entrance release. I noticed that the kitchen monitor already receives calls and opens the entrance, then branched its existing SUB2 control pair into a second USB-RS485 adapter on the NAS.

This separate circuit runs at 3840bps, 8E1. The software tracks call state and checks it both when the app requests release and just before transmission, sending only permitted release requests.

Video and door control are separate signals in the SUB2 cable. The public diagram shows the structure without inventing unverified colors or pin numbers. Entrance-access commands and credentials are not published.

I branched the kitchen monitor’s analog video pair and carried it through passive baluns over a twisted pair. Baluns adapt the BNC/cable span; the AHD2NET encoder makes the network stream.

This setup uses CVBS NTSC input and H.265 over HTTP fMP4 output. The NAS proxy handles encoder authentication and signal state, and FFmpeg converts the stream to H.264 for Homebridge. I checked the working output instead of assuming a format from the product name.

I linked the transition to active video with an Apple Home doorbell event. Door-release permission is determined separately from SUB2 call packets, not from video detection. I also handled the source disappearing after a call. The software briefly retains the recent call video for a late viewer and can repeat its last frame. This is distinct from a live post-call view. Waiting views and bounded retries handle missing video.

Homebridge receives Apple Home requests. The general RS485 service handles lighting, heating and ventilation; a separate SUB2 broker handles calls and entrance release. The SmartThings plugin and camera proxy each handle their own paths.

Command queues, port locks and USB identification coordinate access to the serial interfaces. Heating-state responses provide power and current and target temperatures for five zones. Reconnection and state reception keep the home display updated.

Stale HomeKit state can make the app disagree with the physical device. I distinguish successful transmission, returned state and physical operation, checking logs and state rather than blindly repeating unacknowledged commands.

I built a path from the Qingping CGDN1 Bluetooth sensor through a Raspberry Pi to the NAS and HomeKit. Collecting indoor CO₂, temperature, humidity and air-quality readings is separate from using them to control ventilation. Ventilation rules remain in observation mode; sensor-driven autonomous control is the next integration step.

Next, I want a local AI model to turn multi-condition requests into executable rules: lights when dark, cooling and ventilation when I park in summer, 28°C while sleeping, and cooling off when outdoor temperature falls below 28°C. That requires parking, light, sleep and outdoor inputs plus a rule execution layer.

Other goals are to consider outdoor pollution alongside indoor CO₂ and reduce unnecessary lighting and climate control in empty rooms. I plan to tune comfort first and measure energy use. Compound natural-language control and energy savings are not presented as completed results.

This case describes my IMAZU wallpad, Samsung SmartThings AC, NAS and Raspberry Pi setup, using hardware photos, actual Apple Home screens and retained software. Generated wiring diagrams explain the connections; other equipment still needs its own pin and polarity checks. Compound natural-language automation and energy savings are future implementation and measurement goals.