旧型デバイスもスマートホームに？ 月額パッド・Samsung・LGをHomeKitで一元化

デバイスを使うたびにアプリを切り替えるのが不便でした。同じ部屋の暖房はアパート用壁面パネルに、冷房はSamsung SmartThingsにあるため、1つの空間を2つのシステムで別々に扱う必要がありました。

最初からMatter製品で構成する方法もあります。私はすでに設置された壁面パネル・冷暖房・玄関デバイスをすべて交換する代わりに、既存のNASと通信アダプターを活用しました。交換範囲を縮小してコスト負担を軽減するアプローチであり、具体的な節約額を測定したものではありません。

現在Apple Homeでは照明・暖房・換気とSamsung冷房、玄関映像を使用しています。世帯玄関のLG Smart Lockと共用玄関の制御も正常に動作します。同じ部屋の冷房と暖房は1つのタイルにまとめて4つの部屋で使用しています。

中心となるのはHomebridgeを実行するNASです。一般デバイス制御と共用玄関制御にはUSB-RS485アダプターをそれぞれ使用し、映像にはパッシブバルーン1組、BNC接続部品、AHD2NETエンコーダーを追加しました。異なる信号を無理に1本の回線に統合していません。

照明・暖房・換気は壁面パネル中央のEXTDEV1からNASへ、共用玄関制御はキッチンモニターSUB2制御線から別個のアダプターへ接続します。SUB2の映像はバルーンとエンコーダーを経てLANに入ります。Samsungエアコンは配線ではなくSmartThingsクラウドAPIで接続します。

構成するにはまず壁面パネルのモデルと端子、キッチンモーターの有無、エアコンのAPI接続可否を確認する必要があります。同じ形状のコネクターでも回線の役割や通信設定は異なる場合があります。

既存デバイスが通信している間、受信のみを行いパケットを収集しました。その後照明を1つ点灯させるか暖房の設定温度を変更するなど、一度に1つの条件のみを変更しました。平常時のトラフィックと操作直後のトラフィックを比較し、部屋番号・コマンド・状態を区別しました。

同じ操作と逆の操作を繰り返して値の意味を確認し、AIエージェントと分析コードを補強しました。解釈したコマンドを再送信する際は、実際のデバイスの反応と戻ってくる状態を一緒に確認しました。

私の壁面パネルの一般デバイス回線はEXTDEV1の1B青線をB−、1A白線をA+に接続し9600bps・8N1で通信します。既存配線を維持したまま並列分岐しており、この構成ではGNDを接続していません。実際の端子とアダプターの写真を一緒に掲載しました。

使用していたエアコンはMatterをサポートしないSmartThings製品です。Samsung SmartThings開発者APIを用いてNASのHomebridgeに接続しました。OAuthでアカウントを認証しトークンを更新し、REST APIで状態を取得して制御コマンドを送信します。

冷房リクエストはSmartThingsへ、暖房リクエストは壁面パネルRS485へ伝える統合コードを追加しました。Apple Homeで同じ部屋の冷房・暖房を1つのメニューから選択でき、モード切替時に逆のデバイスを先にオフにするよう切替順序を適用しました。

この経路はインターネットとSmartThingsクラウドを利用します。ローカルAIを追加しても、このエアコンの接続が自動的にオフライン方式になるわけではありません。

照明・暖房回線だけでは共用玄関を開けることができませんでした。キッチンモニターも玄関呼び出しを受けドアを開ける点に注目し、そのデバイスで既に入力されているSUB2信号を活用しました。既存接続から必要な2線を分岐させ2つ目のUSB-RS485アダプターでNASに接続しました。

この回線は一般デバイスバスと分離し3840bps・8E1で扱います。プログラムは呼び出し状態を追跡し、アプリから開放を要求した時と実際の送信直前に条件を再確認します。許可されたドア開閉リクエストのみを送信するようにしました。

SUB2ケーブルの映像線とドア制御線は役割が異なります。公開配線図では構造を示しますが、未確認の線色やピン番号を勝手に記載していません。玄関アクセス用の具体的なコマンドと認証情報も公開していません。

キッチンモニターへの映像線を分岐させパッシブバルーンと電話線ツイストペアで接続しました。バルーンはBNCとツイストペア区間を接続する部品であり、ネットワーク映像への変換役割はAHD2NETエンコーダーが担います。

この構成の入力はCVBS NTSC、実際の出力はH.265方式のHTTP fMP4です。NASのプロキシがエンコーダー認証と信号状態を処理し、FFmpegがH.264に変換してHomebridgeカメラへ伝達します。部品の名称のみを見てストリーム形式を推測せず実際の出力を確認しました。

呼び出しで映像信号が有効化される瞬間を検出しApple Homeのドアベル通知と接続しました。ドア開閉の許可可否はこの映像検出ではなく別個のSUB2呼び出しパケットで判断します。呼び出し終了時に元映像が切断される状況も処理しました。最近の呼び出し映像を短く保存し、遅れて開けても確認できるようにし、最後のフレームを繰り返す処理を入れました。これは呼び出し終了後のリアルタイム映像とは区別されます。映像を受信できない場合は待機画面と制限付き再試行で対応します。

HomebridgeはApple Homeのリクエストを受ける窓口です。一般RS485プログラムは照明・暖房・換気通信を担い、別個のSUB2ブローカーは呼び出しと共用玄関開放を担います。Samsung冷房プラグインとカメラプロキシも各々の経路を担当します。

複数のリクエストがUSBポートを同時に占有しないようキューとポートロック、USB識別を入れました。暖房の全体状態応答では5つのゾーンの電源・現在温度・設定温度を読み取ります。接続が切断されれば再接続し状態を取得してホーム画面を更新します。

HomeKit制御状態が長くなると画面に表示される状態と実際のデバイスが異なる場合があります。そのためコマンド送信成功、状態応答、実機動作を分けて確認します。応答を受け取れなかったコマンドを無条件に繰り返すのではなくログと実際の状態をまず確認します。

Qingping CGDN1のBluetoothセンサー値をラズベリーパイで受けNASへ伝達しHomeKitに表示する経路を作成しました。室内CO₂・温湿度・空気質を読み取るものとその値で換気を自動制御することは別個です。現在の換気ルールは観察モードであり、センサーベース自律制御は次の接続段階です。

次はローカルAIが複数の条件を含む自然文を実行規則に整理するように拡張したいです。例えば暗くなればリビング照明を点灯し、夏に駐車すれば冷房と換気を開始し、睡眠中は28度を維持し外気が28度以下になれば冷房をオフにする方式です。駐車・明るさ・睡眠・外気入力と規則実行部を接続する必要があります。

外部黄砂・微細粒子状物質と室内CO₂を同時に判断して換気し、空室の冷暖房と照明を削減することも目標です。室内温湿度と快適度を考慮して微調整した上でエネルギー使用量で効果を確認しようとしています。複合自然文制御とエネルギー削減効果をすでに達成した成果として提示するものではありません。