Tuya ベースのデバイスをローカルで処理するための Home Assistant カスタム統合。
このカスタム統合は、ポーリングではなくプッシュ更新によってデバイスのステータスを更新するため、ステータスの更新は (手動操作の場合でも) 高速です。この統合では、デバイスの情報と local_key を取得するための Tuya IoT Cloud API もサポートされています。
注: Cloud API アカウントの設定は必須ではありません (LocalTuya は設定なしでも機能します) が、local_keys を簡単に取得 (およびデバイスの再ペアリング後の自動更新) するために、この設定を強くお勧めします。 Cloud API 呼び出しは、起動時と local_key の更新が必要な場合にのみ実行されます。
現在、次の Tuya デバイス タイプがサポートされています。
エネルギー監視 (電圧、電流、ワットなど) は、互換性のあるデバイスでサポートされています。
現在、Tuya プロトコル 3.1 から 3.4 がサポートされています。
このリポジトリの開発は、@NameLessJedi、@mileperhour、@TradeFace のコードとして始まりました。その後、コードは大幅にリファクタリングされ、Home Assistant 環境と適切に統合され、構成フローやその他の機能が追加されました。以下の「感謝」セクションを参照してください。
HACS を使用している場合、最も簡単な方法は、HACS を通じて LocalTuya をインストールすることです。
手動インストールの場合は、localtuya フォルダーとそのすべての内容を Home Assistant のcustom_components フォルダーにコピーします。このフォルダーは通常、 /configフォルダー内にあります。 Hass.io を実行している場合は、SAMBA を使用してフォルダーをコピーします。 Home Assistant Supervised を実行している場合、custom_components フォルダーは/usr/share/hassio/homeassistantにある可能性があります。場合によっては、 custom_componentsフォルダーを作成し、localtuya フォルダーとそのすべての内容をそのフォルダーにコピーする必要があります。
注: LocalTuya を使用するには、Tuya デバイスのキーと ID が必要です。最も簡単な方法は、統合で Cloud API アカウントを構成することです。これを行わない場合は、環境と所有するデバイスに応じて、local_keys を取得する方法がいくつかあります。情報の取得を開始するには、https://github.com/codetheweb/tuyapi/blob/master/docs/SETUP.md または https://pypi.org/project/tinytuya/ から始めるのが良いでしょう。
注 2: インターネットを備えたネットワーク上にこれらのデバイスを統合し、そのインターネット アクセスをブロックすることを計画している場合は、(ローカル DNS サーバー (例: 192.168.1.1) への) DNS リクエストもブロックする必要があります。送信インターネットのみをブロックすると、デバイスはゾンビ状態になります。 localkey を使用した接続は拒否または応答しません。したがって、まずアクティブなインターネット接続でデバイスを接続し、各デバイスのローカルキーを取得して、ブロックを実装する必要があります。
注: v4.0.0 以降、YAML ファイルを使用した構成はサポートされなくなりました。統合は、構成フローを使用してのみ構成できます。
統合の構成を開始するには、[設定] - [統合] ページで [+統合を追加] ボタンを押し、ドロップダウン メニューから [LocalTuya] を選択します。 Cloud API 設定ページが表示され、Tuya IoT Platform アカウントの認証情報の入力を求められます。
Tuya IoT Platform アカウントをセットアップし、そこでプロジェクトをセットアップするには、公式の Tuya 統合の手順を参照してください: https://www.home-assistant.io/integrations/tuya/ クライアント ID とシークレットを見つける場所は次のとおりです。このリンク (「認証キーの取得」段落) で説明されていますが、ユーザー ID はクラウド プロジェクト内の [Tuya アプリ アカウントをリンク] サブタブで確認できます。
注: 上記のリンクに記載されているように、すでにアカウントと IoT プロジェクトをお持ちの場合は、それが 2021 年 5 月 25 日以降に作成されたことを確認してください (Tuya 2.0 のクラウドに導入された変更のため)。それ以外の場合は、新しいプロジェクトを作成する必要があります。プロジェクトの作成日を確認する場所については、次のスクリーンショットを参照してください。
送信ボタンを押すと最初の設定が完了し、統合が追加されます。
注: Cloud API 認証情報の入力は必須ではありません。[Cloud API アカウントを構成しない] ボタンにチェックを入れることを選択できます。そうすれば、いずれにしても統合が追加されます。
統合をセットアップした後、[統合] ページの [構成] ボタンを押してデバイスを追加および構成できます。
設定メニューは以下のとおりです。
Tuya Cloud の資格情報と設定が変更された場合、または統合が v.3.xx バージョンから移行された場合に備えて、このメニューから [クラウド API アカウントの再構成] を選択して、Tuya Cloud の資格情報と設定を編集できます。
その後、Tuya デバイスの追加または編集に進むことができます。
[デバイスの追加または編集] を選択すると、検出されたデバイスのリストを含むドロップダウン メニューが表示されます (追加が選択されている場合は自動検出を使用し、編集が選択されている場合は既に構成されているデバイスのリストを使用します)。これらのいずれかを選択するか、「...」オプションを選択してすべてのパラメータを手動で入力します。
注: 次の手順を確実に実行するには、デバイス上の tuya アプリを閉じる必要があります。
エントリを 1 つ選択した場合は、デバイスのフレンドリ名とローカルキーを入力するだけで済みます。 Cloud API アカウントを構成している場合、これらの値は自動的に取得されます。それ以外の場合は、手動で入力する必要があります。
スキャン間隔の設定はオプションです。エネルギー/電力値がデフォルトで十分な頻度で更新されない場合にのみ必要です。 10 秒未満の値を指定すると、安定性の問題が発生する可能性があります。
「追加する手動 DPS」の設定はオプションです。エンティティが適切に初期化されるまでデバイスが DPS を正しくアドバタイズしない場合にのみ必要です。多くの場合、この設定は、最初にデバイスを Tuya アプリに接続/初期化し、次にアプリを閉じてから統合にデバイスを追加することで回避できます。注: このオプションを使用して追加された DPS は、セットアップ中に -1 の値を持ちます。
「RESET コマンドで送信する DPID」の設定はオプションです。これは、デバイスが電源を入れ直しても Tuya コマンドに応答しないが、(ゾンビ状態) には接続できる場合に使用されます。このシナリオは主に、デバイスがインターネットへのアクセスをブロックされている場合に発生します。 DPid はデバイスによって異なりますが、通常は「18、19、20」が使用されます。ここで間違ったエントリを追加すると、デバイスがゾンビ状態から抜け出せない可能性があります。通常、ここにはセンサーの DPID のみが入力されます。
「送信」を押すと、接続がテストされ、すべてが機能するかどうかが確認されます。
次に、エンティティを追加します。このステップは数回行われます。まず、ドロップダウン メニューからエンティティ タイプを選択して設定します。必要なエンティティをすべて定義したら、[エンティティを追加しない] チェックボックスをオンのままにしておきます。これで手順は完了です。
エンティティごとに、関連付けられた DP を選択する必要があります。 DP を選択するために必要なすべてのオプションには、簡単に識別できるように、デバイス上で見つかったすべての利用可能な DP が (現在のステータスとともに) 表示されるドロップダウン メニューが表示されます。
注: デバイスが機能するために、LocalTuya がエンティティに初期化値を送信する必要がある場合、これは (サポートされているエンティティで) 'パッシブ エンティティ' オプションを通じて構成できます。オプションで、送信する初期化値を指定できます。
各エンティティ タイプには、構成すべき異なるオプションがあります。 「スイッチ」エンティティの例を次に示します。
エンティティを構成したら、手順は完了です。ホーム アシスタントのエリアにデバイスを関連付けることができるようになりました
LocalTuya を v3.xx 以前からアップグレードすると、設定エントリは新しいセットアップに自動的に移行されます。 [統合] タブには、LocalTuya ボックス内でグループ化された複数の統合ではなく、1 つの LocalTuya 統合 (構成されたデバイスとエンティティの数を表示) が表示されることを除いて、すべてがアップグレード前と同じように機能するはずです。これは、古い構成が YAML ファイルを使用して実行された場合と構成フローを使用して実行された場合の両方で発生します。移行後は、Tuya IoT アカウントの資格情報を入力するだけで、クラウド API のサポートを有効にすることができます (また、local_key の取得と自動更新の恩恵を受けることができます)。構成メニューを参照してください。
YAML ファイルを使用して LocalTuya を構成した場合は、YAML ファイル内からその参照をすべて削除できます。それらは考慮されなくなり、混乱を招く可能性があるためです (保持する必要があるのはロガー構成部分のみです。もちろん、「デバッグ」を参照してください)。
エネルギー監視 (電圧、電流) は 2 つの異なる方法で取得できます。
sensor :
- platform : template
sensors :
tuya-sw01_voltage :
value_template : >-
{{ states.switch.sw01.attributes.voltage }}
unit_of_measurement : ' V '
tuya-sw01_current :
value_template : >-
{{ states.switch.sw01.attributes.current }}
unit_of_measurement : ' mA '
tuya-sw01_current_consumption :
value_template : >-
{{ states.switch.sw01.attributes.current_consumption }}
unit_of_measurement : ' W 'ヒーター、サーモスタット、エアコンなど、Tuya ベースの気候が多数あります。すべてがさまざまな方法で統合されているようで、共通の DP マッピングを見つけるのは困難です。以下は、現在機能していることが確認されている DP と製品のマッピングの表です。独自のマッピングのガイドとして使用し、可能であればリストに貢献してください。
| DP | モーズ BHT002 | Qlima WMS S + SC52 (AB;AF) | アヴァット |
|---|---|---|---|
| 1 | ID: オン/オフ {真、偽} | ID: オン/オフ {真、偽} | ID: オン/オフ {真、偽} |
| 2 | 目標温度 整数、スケーリング: 0.5 | 目標温度 整数、スケーリング 1 | 目標温度 整数、スケーリング 1 |
| 3 | 現在の温度 整数、スケーリング: 0.5 | 現在の温度 整数、スケーリング: 1 | 現在の温度 整数、スケーリング: 1 |
| 4 | モード {0、1} | モード {「暑い」、「風」、「湿った」、「寒い」、「自動」} | ? |
| 5 | エコモード ? | ファンモード {"強"、"強"、"中"、"弱"、"自動"} | ? |
| 15 | サポートされていません | サポート済み、不明 {真、偽} | ? |
| 19 | サポートされていません | 温度単位 {"c"、"f"} | ? |
| 23 | サポートされていません | サポート済み、不明 整数、例: 68 | ? |
| 24 | サポートされていません | サポート済み、不明 整数、例: 64 | ? |
| 101 | サポートされていません | 屋外温度 整数。スケーリング: 1 | ? |
| 102 | 外部センサーの温度 整数、スケーリング: 0.5 | サポート済み、不明 整数、例: 34 | ? |
| 104 | サポート済み、不明 {真、偽(?)} | サポートされていません | ? |
Moes BHT 002 Avatto サーモスタット
バグ レポートを作成するときは、デバッグ ログを直接含めると非常に役立ちます (そうでないと、ただ要求するだけになり、時間がかかります)。したがって、次のようにデバッグ ログを有効にして、問題に含めてください。
logger :
default : warning
logs :
custom_components.localtuya : debug
custom_components.localtuya.pytuya : debug次に、問題が発生しているデバイスを編集し、「このデバイスのデバッグを有効にする」ボタンにチェックを入れます。
電力だけでなくそれに基づいて、エネルギー (kWh) の (優れた正確な) センサー (カウンター) を作成します。アイデア: https://www.home-assistant.io/integrations/integration/ および https://www.home-assistant.io/integrations/utility_meter/ を使用します。
#15 に記載されているすべて
NameLessJedi https://github.com/NameLessJedi/localtuya-homeassistant および mileperhour https://github.com/mileperhour/localtuya-homeassistant が主なインスピレーション源であり、スイッチのコードは実質的に変更されていません。
TradeFace は、カバーとの通信用の正しいコード (特に、0x0a ではなくステータスの 0x0d コマンド、および受信される二重応答などの関連ニーズ) を提供する唯一の企業です: https://github. com/TradeFace/tuya/
sean6541、Tuya デバイス用の動作する (標準) Python ハンドラー用。
jasonacox、TinyTuya プロジェクト用。プロトコル 3.4 を使用してデバイスと通信するためのコードをインポートできます。
postlund には、アイデア、リファクタリングの 95% をコーディングし、このリポジトリの品質を (少なくとも私には) 想像できないレベルまで引き上げていただき、Home Assistant での動作について多くのことを教えていただきました。
