LEDVANCE SMART+ Zigbee接続スマート電球レビュー

Sympapaです。

我が家で使用しているスマート電球はZigbee接続の”Philips Hue”製とWi-Fi接続の"Yeelight"製です。
基本的には「綺麗」に光ってZigbee接続である”Philips Hue”をメインに使用していますがお高いですよね。
"Yeelight"は1500円くらいで安売りしている時にフルカラー電球を2個購入し使用していますが、暖色の白色が綺麗に光ってくれないのと、2ヶ月に一度くらいWi-Fi接続が切断して主電源を入れ直さないと再接続しないことがありちょっとイマイチだと思っています。
今回、Amazonで400円弱で投げ売りされているZigbee接続のスマート電球を見つけました。
安すぎて色々と疑惑はありますが、まぁ安物買いの銭失いになってもスタバを1回ガマンすればいいだけの価格です(笑)
そんなワケでそのレビューを書きたいと思います。

■購入したスマート電球

今回購入したのは、LEDVANCE SMART+のZigbee接続スマート電球で「調光調色」タイプと「RGB」タイプの2種類です。前者が383円、後者が359円でしたが「RGB」（フルカラー)のが安いっていう謎(^^;
「RGB」は「調光調色」を兼ねる気もしますが、白色専用の方が白が綺麗なのではないかという疑問があったりもします。
「暖色の白色が綺麗に光るものが欲しい」ので「RGB」と「調光調色」の両方を買って比較することにしました。
箱に書かれたモデル名は「RGB」が"Classic E26 Multi color"、「調光調色」が"Classic E26 Dimmerble"でした。
1年前には「RGB」が4000円～5000円、「調光調色」が2500円前後で販売されていたようなのでディスコンか単に全然売れないことによる不良在庫の処分だと思いますが、日本でマイナーなZigbee接続なので全然売れずに激しい金額で投げ売りされているのではないかと思います。

LEDVANCEって聞いたことないなと思い調べてみると、ドイツのOsramが照明事業を中華企業に売却し独立したブランドみたいですが今もドイツが拠点のようです。今もOsramが販売する照明はLEDVANCE製であってもOsramブランドで販売されているようで、海外のスマートホーム界隈のフォーラムでOsramの名は聞いたことがあります。

■そもそも接続できるのか

私は現在、Home AssistantでZigbbeデバイスを使用する手段として"Zigbee2MQTT"をメインで使用しているので、これに接続して操作できるのかを確認してみました。そしてついでにHome Assistantの純正インテグレーションである"ZHA (Zigbee Home Automation)"でも接続して操作できるのかを確認してみました。
なのでこの部分については"Home Assistant"ユーザーとか"Zigbee2MQTT"ユーザーにしか役に立たない情報となります。
Home Assistantの環境はバージョン: core-2022.7.5、インストール種別: Home Assistant OS、サーバ: Raspberry PI 4B、Zigbeeコーディネータ: Sonoff Zigbbe 3.0 usb dongle plus で、Zigbee2MQTTはバージョン1.26.0-1です。

一応、Zigbeeを内臓した特定のAmazon Echoデバイスと接続可能であるとか、Hue Bridgeと接続可能であるとかいうレビューをチラホラ見かけましたが、Hue Bridgeでは調光調色は出来るけど「消灯」出来ないというレビューもあったりするのでHueとの互換性はないのかもしれません。
いずれにしてもZigbee接続なので、最低限Zigbeeハブ的なものが必要になります。

◆「RGB」モデルの接続結果
"Zigbee2MQTT"では「RGB」モデルの方はZigbee MODELは"CLA60 RGBW JP"、モデル詳細は"SMART+ lamp E26 RGBW"として"Zigbee2MQTT"に認識されました。
しかし"Zigbee2MQTT[安定版]"では「非対応」モデルとなり動作しませんでした。
ですが「Zigbee2MQTT CLA60 RGBW JP」でググったところ、既に"Zigbee2MQTT"の開発者さんへ対応依頼をされている方(おそらく日本人)がおられ、既に[Dev branch]では対応済みのようです。
github.com
そこで、予備のRaspberry PI 4にインストールしている検証用"Home Assistant"に"Zigbee2MQTT Edgeバージョン(Dev.バージョン)"の最新版をインストールして確認したところ正常に動作しました。
おそらく次回の更新で"Zigbee2MQTT[安定版]"も対応すると思われます。
※後日追記: 22年8月2日に来た Ver.1.27.0-1へのアップデートにより"Zigbee2MQTT[安定版]"も「RGB」モデルをサポートしました。

Home Assistantの”ZHA(Zigbee Home Automation"では問題なく接続でき操作出来ました。

◆「調光調色」モデルの接続結果
"Zigbee2MQTT"ではZigbee MODELは"CLA60 TW Value"、モデル詳細は"Classic E26 tunable white 9w 800 lumen"として認識されました。
「調光調色」モデルの方は"Zigbee2MQTT[安定版]"でサポートされており問題なく動作しました。海外モデルと同一で過去からサポートされていたのかもしれません。
Home Assistantの”ZHA(Zigbee Home Automation"でも問題なく接続でき操作出来ました。

尚、「RGB」モデル、「調光調色」モデルともにルーター(リピーター)として認識されました。「調光調色」モデルでは実際にルーターとして人感センサーを接続できることを確認済みです。

※追記: TuyaのZigbeeゲートウェイにもSmart Lifeアプリを使って接続できることを確認しました。

■「RGB」タイプで出来ることと感想

仕様では60W相当800lmで標準的なスマート電球の明るさを持っており、色温度は2700K-6500K RGBWで1600万色以上となっています。
"Home Assistant"から「カラー」と「色温度」と「照度」が調整出来ます。
そもそも個人的に「カラー」は「警告」程度にしか使用していないし他のカラーの電球は"Yeelight"しか所有しておらず「カラー」への拘りも無いので評価が難しいのですが、基本的に発色が良いものの照度と色によっては発色にムラが出ます。でも実際に灯具に取り付けて使う分には気にならないかもしれません。
白色電球としても色温度が350mired以下の範囲であれば概ね使えそうですが「調光調色」タイプの方が良さそうで餅は餅屋という感じがしました。

また、元電源をOFFからONにした時の「色温度」を設定し記憶する（消灯前の状態を記憶する設定も可能）機能が"Zigbee2MQTT”から使えますが、設定できるのは白色ベースでの「色温度」のみで「色」の指定はできません。消灯前の状態を記憶する設定にしておけば、元電源ON時に消灯前の「色」で点灯します。
点灯状態は設定できず元電源ON時は「点灯」で固定、照度も設定できず元電源ON時には消灯前の照度になるようです。

あと、Zigbee2MQTT上ではエフェクトが使えることになっていますが機能しませんでした。(「調光調色」タイプも同じ)
音楽などに合わせて色をチカチカさせて遊びたい場合は環境を整えるのが難しそうなので向かないのではないかと思います。

■「調光調色」タイプで出来ること

仕様では60W相当800lmで標準的なスマート電球の明るさを持っており、色温度は2700K-6500Kとなっています。
もちろんHome Assistantから「照度」と「色温度」の調整が可能です。
"Philips Hue"の調光調色タイプである”White Ambiance E26(LTA002)”と比較してみました。
・最大照度: 仕様上は同じ800lmです。最大照度ではやや"LEDVANCE"の方が明るく感じます。
・最低照度: "LEDVANCE"を最低照度の1%にした時と"Philips Hue"で15%程度の照度に設定した時の照度が同程度だと思います。なので深夜にがっつり暗くして除夜灯的使い方もしたいという場合は"Philips Hue"に分があります。
・色温度: "Philips Hue"の色温度の範囲は2200K-6500Kとなっており、"LEDVANCE"の方が暖色側の色温度調整範囲が狭くなっています。しかし最低色温度で十分な暖色でありこの点は気になりません。

暖色にした時も綺麗に光りますし、総じて最低照度でもがっつり暗くならない点以外に弱点らしい弱点は無いのではないかと思いました。

また、元電源をOFFからONにした時の「色温度」を設定し記憶する（消灯前の状態を記憶する設定も可能）機能が使えますが、点灯状態は設定できず元電源ON時は「点灯」、照度も設定できず元電源ON時には消灯前の照度になるようです。

■接続環境がある人には安く買えたらかなりおススメ

特に「調光調色」タイプのLEDVANCEのスマート電球は"Philips Hue"と比較しても最低照度でがっつり暗くならない点以外には弱点らしい弱点が無いので、接続できる環境があって1500円以下で買えればおススメできる、500円以下なら超お買い得だと思います。
私は"Philips Hue"派でしたが、現在LEDVANCEの「調光調色」は383円で買えるということで「調光調色」タイプは追加で5個注文しました。現在注文数上限が6個に制限されているので追加は5個で打ち止めですが本当は15個くらい欲しかった(笑)
ただ個体差は確認できていないので、ダウンライトなどで複数個同時に点灯させる場合に気になる個体差が無いかについては確認が必要かなと思います。
※後日追記
数量制限は一定期間空くと緩和されるというか再度発注可能になるようで、予定どおり(?)「調光調色」は15個、「RGB」は6個購入しました。21個買っても10,000円いかないコスパはヤバしです。

それでは。

Home Assistant: ESP Home+ESP32でPCの電源ON/OFFをIoT化する(2)

Sympapaです。

前回、ESP Home+ESP32を使ってデスクトップPCの電源ON/OFFをIoT化しましたが、ブレッドボードを使ったお試し回路だったので本番回路を仕上げていきたいと思います。
sympapa.hatenablog.com

ですが、その前にESP Homeの設定を見直しします。

■ESP Home(とHome Asssitant)の設定見直し

前回組んだ回路は下図のとおりで、PCの電源状態の取得をマザーボードの電源表示用LED端子から取ることにしたんですが、配線後に「スリープ中LEDは点滅する」＝「ESP32上のbinary_sensorが絶えずON/OFFを繰り返す」ということに気づきました。

これに対して前回はHome Assistant側でフィルタをかけて強引に対処していましたが、それだとスリープ中はESP32からHome Assistantへ絶えずON/OFFのステータス変化が送信されるのでWi-Fiの負荷やHome Assistantの負荷的にどうなんだろうか？という懸念が残りました。
配線し直して違う箇所から電源状態の取得をすることも考えましたが、ESP32側でフィルタ処理を完結させることによって、スリープ中にESP32からHome Assistantへの通信が発生するのを抑制することにしました。
ESP Homeで"binary_sensor"に"-delayed_on: 4000ms"のフィルタを追加し、GPIO33から4秒以上連続して入力があった時に「PCがONになった」と判定にするようにします。
スリープ中はGPIOからの入力はON/OFFを繰り返しますが、最初にOFFになった時点でbinary_sensorは"OFF"になり、GPIO33から4秒以上の入力があるまでは"ON"にならないのでESP32の中でON/OFF判定の処理が完結します。ESP32が忙しいままなのは変わらないですけど(汗
うまくやれば「スリープ」なのか「電源OFF」なのかを判別することも出来ますが、今回はその必要が無いのでやめておきます。
ちなみに"switch"の方はあくまでも「PCの電源スイッチを短絡させる」ためのスイッチであり「PCの電源ON/OFF」のスイッチではありません。300msのモーメンタリスイッチとしています。
そんなわけでESP Homeの設定は以下のようにしました。

switch:
  - platform: gpio
    pin: 32
    id: pc_switch_esp32
    name: "PC_switch_ESP32"
    icon: "mdi:gate"
    on_turn_on:
    - delay: 300ms
    - switch.turn_off: pc_switch_esp32

binary_sensor:
  - platform: gpio
    pin:
      number: 33
      mode: INPUT_PULLUP
      inverted: true
    filters:
      - delayed_on: 4000ms
    name: 'PC_power_status_esp32'

合わせてHome Assistant側の設定も見直します。
ここは前回と同じですがHome Assistant上で「PCのON/OFF」用の仮想スイッチを作ります。
このスイッチをGoogle Homeに連携させることで「OK! Google!」での操作も実現しています。

configuration.yaml

input_boolean:
  pc_power:
    name: pc_power
switch:
  - platform: template
    switches:
      pc_power:
        value_template: "{{ states('input_boolean.pc_power') }}"
        turn_on:
          - service: input_boolean.turn_on
            entity_id: input_boolean.pc_power
          - service: script.pc_power_on
        turn_off:
          - service: input_boolean.turn_off
            entity_id: input_boolean.pc_power
          - service: script.pc_power_off

次に上で作ったHome Assistant上のスイッチがON/OFFされたら、実際のPCの電源ステータスをチェックした上でPCの電源スイッチ端子を短絡させるスイッチをONにするスクリプトです。

alias: PC_power_on
sequence:
  - condition: state
    entity_id: binary_sensor.pc_power_status_esp32
    state: 'off'
    for:
      hours: 0
      minutes: 0
      seconds: 0
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.pc_switch_esp32
  - wait_for_trigger:
      - platform: state
        entity_id:
          - binary_sensor.pc_power_status_esp32
        from: 'on'
        to: 'off'
    timeout: '20'
mode: single

alias: PC_power_off
sequence:
  - condition: state
    entity_id: binary_sensor.pc_power_status_esp32
    state: 'on'
    for:
      hours: 0
      minutes: 0
      seconds: 0
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.pc_switch_esp32
  - wait_for_trigger:
      - platform: state
        entity_id:
          - binary_sensor.pc_power_status_esp32
        from: 'on'
        to: 'off'
    timeout: '20'
mode: single

次にPCの物理スイッチやPC上の操作で電源を操作した場合など、外部からPCの電源操作をした場合にそれをHome Assistant上のスイッチへ反映させるオートメーションです。

alias: PC_power_on
description: ''
trigger:
  - platform: state
    entity_id:
      - binary_sensor.pc_power_status_esp32
    from: 'off'
    to: 'on'
    for:
      hours: 0
      minutes: 0
      seconds: 0
condition:
  - condition: state
    entity_id: input_boolean.pc_power
    state: 'off'
  - condition: state
    entity_id: binary_sensor.pc_power_status_esp32
    state: 'on'
action:
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.pc_power
mode: single

alias: PC_power_off
description: ''
trigger:
  - platform: state
    entity_id:
      - binary_sensor.pc_power_status_esp32
    from: 'on'
    to: 'off'
    for:
      hours: 0
      minutes: 0
      seconds: 0
condition:
  - condition: state
    entity_id: input_boolean.pc_power
    state: 'on'
  - condition: state
    entity_id: binary_sensor.pc_power_status_esp32
    state: 'off'
action:
  - service: switch.turn_off
    data: {}
    target:
      entity_id: switch.pc_power
mode: single

■回路の作製

前回はブレッドボード上で作ったお試し回路だったので、ユニバーサル基板を使った本番回路を作製します。
といっても、ユニバーサル基板を使った回路の作製は初めてです(汗
ハンダ付けうまくいくかな。。。

回路は前回ブレッドボード上で作製したとおりです。

用意したユニバーサル基板は"サンハヤトICB-86”です。
ESP32、抵抗×4本、ダイオード×4本、フォトカプラ×2個を載せなくてはいけないので、大きめのを選びました。
そして、"ICB-86"はつながったパターンがあって、うまく使えばパターン間を自力で繋がなくてはいけない箇所が減りそうなのでコレにしました。今回使用したESP32は"ICB-86"の繋がっているパターン上にうまく載るので、ESP32からの配線がしやすいメリットもあるはず。

Amazon | サンハヤト 小型ユニバーサル基板 ICB-86 | 基板 | 産業・研究開発用品 通販

ESP32は直付けしようかと思いましたが、下駄をかませた方がESP32の下のスペースで回路を作ったりできるのでピンソケットを付けました。
ちなみにハンダ付けが汚すぎて裏側はお見せできません(笑)

基板を100均のケースに入れて両面テープで固定しました。
ESP32の電源はPCのスタンバイ電源(5V)から取ろうかと思いましたが、直付けはヤバいかもしれないということと、どのみちPCのケース内に取り付けたとしてもWi-Fiの接続が厳しかったらPCケースの外へ出さなくてはいけないので、とりあえず外部からUSBで供給することにしました。

結果的にはPCケース内に設置してWi-Fiの電波強度は-80dbくらいですが問題なく動作しているので、もう暫く様子をみて問題なさそうであれば、ESP32の電源はPC内部から取りたいと思います。

■まとめ

PCの消費電力は結構大きいのですが、暫くだけ作業から離れるつもりでオフにせずに離席しそのまま長時間作業に戻らないってこともあるので、遠隔操作出来るのは良いと思います。
ユニバーサル基板を使った回路作製には初めてトライしましたが、作業が終わる頃にようやくハンダ付けのコツを掴みました(汗
精進したいと思います。

それでは。

Home Assistant: ESP Home+ESP32でPCの電源ON/OFFをIoT化する(1)

Sympapaです。

今までデスクトップPCの電源のIoT化はSwitchbotボットに担当して貰っていました。物理的にスイッチなどを押してくれるアレです。
Switchbotボットを使ってIoT化するのはステータスも判らないし個人的には全くスマートだと思えませんが、他の手段ではどうにもならない時に最後の砦的な存在ではあります。それに動きがシュールでいいんですよね(笑)

しかし物理的にちょっと邪魔であるのと、Bluetoothを介したHome Assistantからの操作が安定しない(SwitchbotアプリやSwitchbotハブ経由では問題ない）のと、そもそもPCのスイッチ周りは仕組みが単純なのでSwitchbotボットじゃなくても制御できるよねって思ってたりしました。
PCなのでそもそもWake on LANを使えばいいんじゃないかという話もあるかと思いますが、私のデスクトップPCはどう設定してもWi-Fi接続ではWake on LANによる起動が出来ないんです。

そんなワケで、PCの電源ボタン担当をSwitchbotボットからESP32に変えてしまおうというのが今回のお話です。

■構想

PCケースの電源スイッチはマザーボードにある2つのピンに繋がっていて、この2つのピンを短絡させるとマザーボードが電源をオンにしてくれるという仕組みです。なのでマザーボードには電源OFFの時にもスタンバイ用の電源が供給されており、その電圧は5Vで電源ボタンのピンの電圧も5Vだそうです。
デフォルトでは普通に押すとON or スリープ、ONの時に長押しするとシャットダウンという風になっていると思いますが、動作はOS側の設定によります。
ESP Home + ESP32を使ってこのピンの短絡を制御し、Home AssistantからPCをオンオフできるようにします。

また、PCの電源はトグルスイッチなので、PCの電源状態も取得しそれをチェックした上で電源のトグルスイッチを操作させるのかを判断する処理が必要です。なので合わせて電源状態取得も出来るようにします。

■回路を考える

基本的には以前考えたHA端子(JEM-A端子)を制御する回路の抵抗だけ変えればいけるんじゃないかと思います。
なので今回もフォトカプラはTLP785を使います。
sympapa.hatenablog.com

電源スイッチの方はPCケースのスイッチと並列に入力を割り込ませればいいでしょう。
PC側の電源ボタンの2ピン間の電圧は5Vのようです。
とりあえずフォトカプラを壊さないように、フォトカプラの推奨コレクタ電流が1～10mAを超えない抵抗からスタートして様子を見ることにします。
5V/10mA=500Ωにします。

電源ON/OFFの状態はどこから取得しようかな？
ひとつ目の候補は電源ランプのLEDから、ふたつめの候補は内部USBコネクタから。
電源ランプのLEDに割り込ませるとLEDが暗くなるかもしれないし、USB2.0の内部コネクタは空きがありません。
しかしマザーボードの取説をまじまじと眺めていたら電源LEDの端子が2系統あることが判明したので、ここから取ることにします。
しかし、後でPCの電源LEDはスリープ時に点滅することに気づき、ここから取ることにしたことを後悔しました(笑)

TLP785の推奨順電流は標準:16mA 最大:25mAってことですが、10mAで全く問題なく動作するので10mAで計算します。
RIN = (VCC-VF)/IF = (5V-1.3V)/10mA = 370 Ω
※電源LED出力の電圧を5Vで計算しましたが実測は3Vでした。まぁ動いたのでこのままにしてますが。

ESP32側は制御側が300Ω、モニタ側が1000Ωとしています。
まとめたのが下図。

■ESP Homeの設定

Home AssistantからESP32を制御するのにはESP Homeアドオンを使います。
esphome.io

ESP Homeの設定は以下の.yamlのとおりです。
遠隔操作を考えるとPCがONの状態からいきなりシャットダウン落としたくはないので、常にスリープモードに入るようPCの電源スイッチ端子を短絡させるためのスイッチは300msのモメンタリスイッチに設定します。
今のところ300msで確実にスリープ、スリープからの復帰が出来ています。

電源状態の取得側の方ですが、PC電源のLED端子から取ることにしたのでPCの電源がONの場合は常時ONとなりますが、スリープ中は間欠でON/OFFを繰り返す(LEDが点滅するので)ことになってしまい、ダイレクトに電源がONかOFFかのステータスを取得することが出来ません。
ここの処理は後でやりたいと思います。

switch:
  - platform: gpio
    pin: 32
    id: pc_switch_esp32
    name: "PC_switch_ESP32"
    icon: "mdi:gate"
    on_turn_on:
    - delay: 300ms
    - switch.turn_off: pc_switch_esp32

binary_sensor:
  - platform: gpio
    pin:
      number: 33
      mode: INPUT_PULLUP
      inverted: true
    name: 'PC_power_status_esp32'

■Home Assistantの設定

Home Assistant上でPC用のスイッチを作ります。
Google Homeからも操作したいので、このスイッチをGoogle Homeと同期させます。

configuration.yaml

input_boolean:
  pc_power:
    name: pc_power
switch:
  - platform: template
    switches:
      pc_power:
        value_template: "{{ states('input_boolean.pc_power') }}"
        turn_on:
          - service: input_boolean.turn_on
            entity_id: input_boolean.pc_power
          - service: script.pc_power_on
        turn_off:
          - service: input_boolean.turn_off
            entity_id: input_boolean.pc_power
          - service: script.pc_power_off

次に上で作ったHome Assistant上のスイッチがON/OFFされたら、実際のPCの電源ステータスをチェックしPCの電源スイッチ端子を短絡させるスイッチをONにするスクリプトを作ります。
電源状態をPC電源のLED端子から取得することにしたので、PCがスリープ中はbinary_sensor.pc_power_status_esp32がON/OFFを繰り返すため、これが連続で4秒以上ONになっていない場合はPCの電源がOFF又はスリープであると判定するようにしました。
そして、Home Assistant上のスイッチがONになった時に既にPCの電源がONであった場合はPCの電源スイッチ端子を短絡させず、Home Assistant上のスイッチがOFFになった時に既にPCの電源がスリープ又はOFFであった場合もPCの電源スイッチ端子を短絡させないようにしています。

alias: PC_power_on
sequence:
  - condition: not
    conditions:
      - condition: state
        entity_id: binary_sensor.pc_power_status_esp32
        state: 'on'
        for:
          hours: 0
          minutes: 0
          seconds: 4
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.pc_switch_esp32
  - service: automation.turn_on
    data: {}
    target:
      entity_id: automation.pc_power_off
mode: single

alias: PC_power_off
sequence:
  - condition: state
    entity_id: binary_sensor.pc_power_status_esp32
    state: 'on'
    for:
      hours: 0
      minutes: 0
      seconds: 4
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.pc_switch_esp32
  - service: automation.turn_off
    data:
      stop_actions: false
    target:
      entity_id: automation.pc_power_off
  - wait_for_trigger:
      - platform: state
        entity_id:
          - binary_sensor.pc_power_status_esp32
        from: 'on'
        to: 'off'
    timeout: '20'
mode: single

次にPCの物理スイッチやPC上の操作で電源を操作した場合にHome Assistant上のスイッチをON/OFFするオートメーションを作ります。
ONにするオートメーションのトリガーは「binary_sensor.pc_power_status_esp32が4秒以上連続でONになった時」としています。
問題はOFFにするオートメーションで、PCの電源がスリープの場合はbinary_sensor.pc_power_status_esp32がON/OFFを繰り返すので、これがOFFになったことをトリガーにすると処理が頻繁に発動してしまいます。
ちょっと悩みましたが、電源OFFの処理をひととり終えたらこのオートメーションを無効化し、PCの電源がオンになったら無効化したオートメーションを有効化する処理を上のスクリプトに加えることで対処しました。
(しかしこの処理をしてもスリープ中はESP32からHome Assistantへ絶えずステータスの変化が送信されWi-Fiへの負荷がかかりそうなので、次回見直しします。）

alias: PC_power_on
description: ''
trigger:
  - platform: state
    entity_id:
      - binary_sensor.pc_power_status_esp32
    from: 'off'
    to: 'on'
    for:
      hours: 0
      minutes: 0
      seconds: 4
condition:
  - condition: state
    entity_id: input_boolean.pc_power
    state: 'off'
action:
  - service: switch.turn_on
    data: {}
    target:
      entity_id: switch.pc_power
mode: single

alias: PC_power_off
description: ''
trigger:
  - platform: state
    entity_id:
      - binary_sensor.pc_power_status_esp32
    from: 'on'
    to: 'off'
    for:
      hours: 0
      minutes: 0
      seconds: 0
condition:
  - condition: state
    entity_id: input_boolean.pc_power
    state: 'on'
  - condition: not
    conditions:
      - condition: state
        entity_id: binary_sensor.pc_power_status_esp32
        state: 'on'
        for:
          hours: 0
          minutes: 0
          seconds: 4
action:
  - service: switch.turn_off
    data: {}
    target:
      entity_id: switch.pc_power
mode: single

■テストする

とりあえずテストなのでブレッドボード上で回路を作製しました。
「OK Google!PCをつけて」で起動、「OK Google!PCを消して」でスリープに出来るし、Home Assistant上のスイッチでもPCのスイッチでも操作出来ます。

■まとめ

これでPCの電源をHome AssistantやGoogle Homeからオンオフできるようになりました。
次は回路部品をユニバーサル基板にハンダ付けして完成させたいと思います。
PCのケースにESP32を入れてしまうとWi-Fi接続に支障はないやろか？
ESP32の電源はどこから取ろうかな？

それでは。つづく。

Home Assistant: ESP Homeで超音波距離センサーHC-SR04を試す

Sympapaです。

秋月電子でESP32を追加発注した際に、送料がかかるので他にもまとめてってことでなんとなく300円の超音波距離センサーをポチってしまいました(汗
特に使い道を考えていなかったのですが、まぁどんなもんなのか試していきたいと思います。

■超音波距離センサーHC-SR04

今回は秋月電子で購入しました。1個300円。
純正品かどうかは怪しいですがAmazonでも5個で1,000円くらいで買えたりします。
仰々しい超音波送信部と受信部？が、とても仕事をしてくれそうな雰囲気です(笑)

■ESP Homeの超音波距離センサー対応

ESP Homeは私のような初心者がESP32を動かすにはもってこいのプラットフォームです。他を知らないのでたぶんですが(笑)
ESP Homeでは設定を簡単な.yamlで書けば、後はGUI上で書き込みの操作をするだけでコンパイルから書き込みまでやってくれます。
初めて接続するESP32の個体の場合はUSB接続してWi-Fi設定の書き込みが必要ですが、その後はESP Homeを使っている限りはWi-Fiで書き込みも出来るお手軽さも魅力だと思います。
とにかく私でも迷わずに導入から使用まで出来ているので、簡単な部類であることは間違いありません(笑)
Home Assistant Cloudを運営しているNabucasaが開発しているだけあって、Home AssistantにはESP Homeアドオンが存在しHome Assistantとの連携もさくっと簡単に出来てしまうのがHome Assistant使い的なESP Homeの長所だと思います。
esphome.io

ESP Homeは超音波センサーもサポートしており、今回購入した超音波距離センサーHC-SR04もサポートしています。
esphome.io

ただし、上記のページに載っている# Example configuration entryはとても曲者です(汗
例をコピペして動かそうとしたところ以下のように怒られました。ボードによってpin nameが違うんですね。

Cannot resolve pin name 'D1' for board esp32dev.
trigger_pin: D1
Cannot resolve pin name 'D2' for board esp32dev.
echo_pin: D2

そんなわけで解決策を探していきましょう。

■解決策

いきなりですが解決策はここで見つかりました。
community.home-assistant.io

抵抗を入れろとかコンデンサーを入れろとか書かれていますが、私の環境ではtrigger_pin:をGPIO4、echo_pin:をGPIO5とするだけでちゃんと動いているように見えます。
ESP Homeの設定(.yaml)は以下のとおりです。

sensor:
  - platform: ultrasonic
    trigger_pin: GPIO4
    echo_pin: GPIO5
    name: "Ultrasonic Sensor"
    update_interval: 5s
    pulse_time: 10us
    timeout: 20m

■使ってみる

距離はそこまで正確ではなさそうですが、ざっくり距離をトリガーにしてオートメーションを発動させるには十分だと思います。

正面でなければ検出はしませんが、何より人感センサーと違ってモノでも検出できるし、人の場合もじっとしていても検出できるメリットがあります。
今回の例では更新間隔を5秒に設定してあるので即応性の必要な用途には使えませんが1秒間隔とかにすると処理に負荷がかかるのかな？
まぁ5秒間隔でも、トイレや机の前など定位置に人が座る場所から居なくなったとか、定位置にあるはずのモノがあるのか無いのかとか、カーポートに車が停まっているかどうかとか、そういうのを検出できそうです。
個人的には「ベッドに人が寝ているか」とか「物干し竿に洗濯ものが干してあるか」みたいのを検出できたらいいなと思うのですが、超音波が反射しづらい柔らかいものは正確に検出するのが難しいみたいですね。また試してみたいと思います。

このセンサーに限ったことではありませんが、ESP32に5Vの電源供給をしないといけないのでボタン電池で動くZigbee接続の人感センサーやドア開閉センサーの使い勝手には到底及びません。
あとHC-SR04用のブラケットは一応売っているんですがそれを使っても剥き出し部が多いので、見た目を美しくしようとすると3Dプリンターが無いと難しいのが難点ですかね。

■まとめ

なんだかんだで300円でこれはなかなか使えそうです。
まぁESP32の費用も足すと1300円～1800円くらいになるのでそれを考えると、XiaomiやAqaraがZigbbe接続でボタン電池駆動の超音波距離センサーを出してくれたらありがたいですが。。。そもそも超音波って時点で電池食いなのかもしれませんけど。
とりまデスクに設置して、長時間デスクの前に座っていなかったら自動的にPCをスリープさせるとかやってみようかな。
それでは。

スマートホーム: 屋外や風呂で使う人感センサーとドア開閉センサーの防水化

Sympapaです。

スマートホーム化を進めていく上で課題のひとつとなるのがセンサー類の防水化ではないでしょうか？
屋外や風呂に人感センサーやドア開閉センサーを取り付けたいケースは結構あるでしょう。
探せば防水のセンサーも見つけられますが、水中にドブ漬けするわけでは無いし、普段1,000~2,000円のセンサーを使用している私達(達？(笑))からすると高価すぎます。

私は非防水の人感センサーをDIYで防水化し、軒の下ではありますが設置して約9月経ちましたが全く問題ありません。
ドア開閉センサーもDIYで防水化し風呂の窓に設置して掃除の際は水をぶっかけていますが、こちらも約9ヶ月経って全く問題ありません。
そんなワケでその方法などを記事にしてみたいと思います。
が、やってみようという方はお約束の自己責任でお願いします(笑)

■人感センサーの防水化

人感センサーを屋外で使う場合、防水化以前に課題があります。
どんな要因で起きるのかは良くわかりませんが、センサーによっては室内では5m程度の距離の人感を良好に検出してくれるものであっても日中の屋外では極端に検出できる距離が短くなったり、日中の屋外で検出が良好なものは夜間に家の前をクルマが通ると誤検出することがあります。

我が家では屋内では4種類の人感センサーを使用しています。
sympapa.hatenablog.com

その内、Aqura Motion sensor (RTCGQ11LM)とSonoff Motion sensor (SNZB-03)を屋外で試しました。
Aqura Motion sensor (RTCGQ11LM)の方は屋内では感度良好ですが明るい日中の屋外だと至近距離まで近づかないと人感を検出しませんでした。
レンズの問題かなぁ。。。
Sonoff Motion sensor (SNZB-03)の方は、センサーの正面が家の前へ向くように取り付けたところ、夜間に家の前をクルマが通った時にも誤検出しました。しかし、軒下に下向きで取り付けると誤検出せずいい感じに人感を検出してくれたので、屋外用人感センサーとしてはSonoff Motion sensor (SNZB-03)を軒下に下向きに取り付ける前提で使用しています。
itead.cc

さて、本題の防水化ですが、まずレンズの周りにはシリコーンコーキングを施しています。仕上がりの汚さは気にしないでください(笑)

コーキングガンで使うような大きいコーキング剤を買っても使いきれないので、私はコニシのバスボンドを愛用しています。
www.bond.co.jp

そして、筐体の側面と背面はブチルテープでグルグル巻きです。

ブチルテープの本来の用途は電線接続部などの防水のようで、いわゆる粘着剤は塗布されていませんが、2倍～3倍くらいに伸ばして巻き付けると張力で被着体に密着し、巻き付けたブチルテープ同士も一体化するという優れモノです。
愛用しているのは日東電工のNo.15で、以前からクルマの配線を弄ったりした時にも使っています。
www.nitto.com

人感センサーの場合はレンズ部分を剥き出しにしなくてはいけないので、そこから筐体とブチルテープの間に侵入する水はさすがに完全に止水出来ないかもしれませんが軒下で使う程度なら全然大丈夫そうです。約9月経過し切腹してみましたが水の侵入の痕跡は全くありませんでした。
ブチルテープは2倍～3倍(倍率はテキトー)に伸ばしながら巻かないと性能を発揮できないので注意が必要です。

■ドア開閉センサーの防水化

我が家で使用しているドア開閉センサーは全てAqara Door and Window Sensor(MCCGQ11LM)です。
www.aqara.com

風呂の窓のクレセント錠が施錠されているかをモニターするために、このドア開閉センサーを防水化して風呂の窓に取り付けています。
こちらは開口部が必要無いので、ブチルテープで完全にグルグル巻きしています。
ブチルテープ同士は一体化するし開口部が無いので、こちらは人感センサーよりも高い防水効果が得られているのではないでしょうか？
風呂の掃除の時にも気にせず水をぶっかけていますが、約9ヶ月経過し切腹して確認したところ水が浸入した痕跡は微塵もありませんでした。

但し、あまり分厚く巻くとちょっとドア開閉センサーの感度が鈍くなったり電波の飛びが悪くなる気がしているので、巻きすぎない方が良いかもしれません。

■まとめ

そんなワケで今回はスマートホームに欠かせない人感センサーとドア開閉センサーの防水化について書いてみました。
それでは。

Home Assistant: ESP32+MH-Z19CでCO2モニター構築(2) [キャリブレーション編]

Sympapaです。

1週間ほど前に二酸化炭素センサー:MH-Z19CとESP32を組み合わせ、Home AssistantのESP Homeアドオンを使ってHome Assistantで使える二酸化炭素モニターを構築しました。
sympapa.hatenablog.com

前回はMH-Z19Cを2個購入してリビングと自分の部屋の二酸化炭素濃度をモニターし始めたんですが、なかなか気に入ったのでもう1個MH-Z19Cを追加購入しました。前回は2個が同等の値を示していたので「キャリブレーションしなくていいか」と思ったのですが、今回追加で購入したMH-Z19Cは前の2個より1.8倍くらい高い値を示しています。そして部屋にずっと誰もいない状態でも550ppmくらいまでしか下がりません。
別のESP32に繋いでも同じなのでセンサー個体の問題と判断し「やっぱりキャリブレーションが必要か」ということになりました。ロットは同じみたいなんですけどねぇ。。。

そんなワケでキャリブレーションしていきます。

■MH-Z19Cのキャリブレーションの仕様

キャリブレーション方法をググると、前バージョンであるMH-Z19Bの情報が多く出てきます。
MH-Z19BのCO2濃度測定レンジは0ppm-5000ppmでしたがMH-Z19CのCO2濃度測定レンジは400ppm-5000ppmとなっていて測定レンジが異なるようです。なのでMH-Z19Cでは400ppm=Zero pointということになっています。
MH-Z19BのDATA SHEETではZero pointは400ppm以下の環境でキャリブレーションを実施し、Span pointは1000-2000ppmの環境でキャリブレーションするということになっていましたが、MH-Z19CのDATA SHEETからはSpan pointのキャリブレーションの記述は消えています。

https://www.winsen-sensor.com/d/files/infrared-gas-sensor/mh-z19b-co2-ver1_0.pdf

https://www.winsen-sensor.com/d/files/infrared-gas-sensor/mh-z19c-pins-type-co2-manual-ver1_0.pdf

「1ポイントのキャリブレーションで大丈夫なんかいな？」と思いつつ、実際のところ一般人には安定して1000-2000ppmの環境を作ることなど出来ないので、どのみちZero pointキャリブレーションしか出来ないとは思います。

そしてMH-Z19にはバージョンに関わらずオートキャリブレーション機能があってこれを有効にしておくと、「24Hr中の一番低い値」を400ppmということにして24Hrに1回キャリブレーションするそうです。私はこの機能はOFFにして使用していますが、人が居なくなると数時間すれば二酸化炭素濃度は400ppmくらいまで下がるようなので、仕事で出かける平日であればオートキャリブレーションでZero pointキャリブレーションしても良さそうですね。ただ、休日に一日中家に居る日があったりすると、その日のキャリブレーションはおかしなことになりそうです。
手動でZero pointをキャリブレーションする場合は、以下の方法があります。

【方法1】
1) 400ppm以下の場所で20分動作させる。
2) HDピンとGNDを7秒間短絡させる。するとこの時を400ppmとしてキャリブレーションされる。

【方法2】
1)400ppm以下の場所で20分動作させる。
2)Calibrate Zero Point (ZERO)コマンドを呼び出す。

自分の息(二酸化炭素)の影響を与えずに7秒間ピンを短絡させるのは、長いケーブルでも繋がない限り結構至難の業のように思います。
ESP HomeではZero pointキャリブレーションのコマンド呼び出しにも対応しているので、今回はこれを使いたいと思います。
esphome.io

■ESP Homeの設定

ESP Homeでは service: mhz19_calibrate_zero　として、Zero pointキャリブレーションがサービスとして提供されています。
このサービスをAPIでHome Assistantから呼び出せるように設定します。
この例ですと、Home Assistant側に"ESPHome: (ESP32の名前)_mhz19_calibrate_zero”というサービスが現れ、それを実行することでZero pointキャリブレーションが発動します。
ESP Home簡単すぎる素敵。

# Enable Home Assistant API
api:
  services:
    - service: mhz19_calibrate_zero
      then:
        - mhz19.calibrate_zero: MH_Z19_ESP32
        
# MH-Z19B CO2 Sensor
uart:
  rx_pin: 16
  tx_pin: 17
  baud_rate: 9600

sensor:
  - platform: mhz19
    id: MH_Z19_ESP32
    co2:
      name: "MH-Z19_ESP32_CO2_Value"
    temperature:
      name: "MH-Z19_ESP32_Temperature"
    update_interval: 60s
    automatic_baseline_calibration: false

■いざキャリブレーション

400ppm以下の環境を用意しろとのことなので、窓の外に設置しキャリブレーションすることにしました。

我が家はド田舎なのでこれで十分に400ppm以下のはずです(笑)
今回購入したものと前回購入した2個のMH-Z19Cを全部キャリブレーションします。
キャリブレーション前に400ppm以下の環境で20分間動作させろとのことなんですが、今回購入分はやはり外に向けて作動させても550ppm程度までしか下がりませんでした。
20分程度動作させた後でHome Assistantからサービス”ESPHome: (ESP32の名前)_mhz19_calibrate_zero”を呼び出しキャリブレーションします。

■結果は。。。

Zero pointはちゃんと400ppmになったしキャリブレーション前よりはマシですが、今回購入したもの(一番上)はそれでもまだ30%ほど高い値を示しています。。。

とか思ってあーだこーだ弄ったり放置したりまた弄ったりしている内(その間10時間くらい）に何故かそこそこいい感じになってました(笑)
まぁそれでも3台で100～200ppmのレンジがありますけどね。

もしかしてエージング要るの!??
ドリフトした感があるので今回購入したMH-Z19Cを再度Zeroキャリブレーションしてみましたが、キャリブレーション前と同じくらいの値が出ています。

結局、今回購入したMH-Z19Cの値が最初の内はキャリブレーションしても高かった原因は判らないままです。
ESP32へ給電する電源を変更したりもしたのでそのあたりの影響？なんてことも思いました。でも使用するESP32を入れ替えても同じだったし、そもそも電源の問題で一見ちゃんと動いているのに値だけおかしくなるとかあったりあるのかな？
ちょっと様子見ですね。

それでは。

Home Assistant: ECHONETLite2mqttの更新

Sympapaです。

Home AssistantからECHONETLite対応家電を操作するのにEchonet2mqttを使用させていただいています。
github.com
（Home Assistantのカスタムインテグレーションであるこちらも使用させていただいてますが一長一短なので現状は両方使用させていただいています。）
Echonet2mqttはHome AssistantのアドオンやカスタムコンポーネントではないのですがECHONETLiteをMQTTに変換してくれるもので、MQTT経由でHome AssistantとECHONETLiteを繋いでくれます。

便利に使わせていただいているのですが、シャープのエアコンの場合はエアコンが測定した室温を取得出来ない問題がありました。
しかし1ヶ月ほど前にこの問題に対処できる（？）更新がされていたようです。

私はHome Assistantを動かしているのとは別のRaspberry PI 4のDocker上でEchonet2mqttを動かしているのですが、Dockerの仕組みをさっぱり理解しておらず、Dockerでインストールしたものを更新するのは初めて。。。(汗)
更新方法をメモるだけの記事になりそうですが、どうやって更新されたEchonet2mqttをインストールするのかもよーわからんので、備忘録を兼ねて書いておきます。

■古いバージョンの後始末

上書きインストールする方法があるのかもしれませんがさっぱりDockerのことが解っていないので、まず古いバージョンを消すことにしました。

1. 古いバージョンのEchonet2mqttを停止する
1-1. 稼働中のDockerコンテナのID確認

docker ps

1-2. 稼働中のコンテナを停止する

docker stop コンテナID

2.コンテナを削除する
気が付いたら停止したEchonet2mqttのコンテナがかなりたくさんありました。
停止中のコンテナを一括削除するコマンドで削除します。

docker container prune

3.イメージを削除する
3-1. イメージIDを確認する

docker images

3-2. イメージを消す

docker rmi イメージID

4.ディレクトリを削除する
ここまででgit cloneしたら”fatal: destination path 'echonetlite2mqtt' already exists and is not an empty directory."だと怒られました。
なので古いバージョンのechonetlite2mqttで使用していたディレクトリを下記のコマンドで削除します。
（ひょっとしたら先にコンテナやイメージを消してなくてもディレクトリ削除でいける？）

rm -rvf echonetlite2mqtt

■インストールする

古いバージョンは消去したので普通にインストールします。

1. git cloneする

git clone https://github.com/banban525/echonetlite2mqtt.git

2. echonetlite2mqttディレクトリへ移動する。

cd echonetlite2mqtt

3. ビルドする

docker build ./ -t echonetlite2mqtt

■実行する

MQTTブローカーにパスワード認証が設定されていない場合は下のコマンドで起動します。

docker run -d --net=host -e MQTT_BROKER="mqtt://192.xxx.xx.xx:1883" echonetlite2mqtt 

MQTTブローカーにパスワード認証が設定されている場合は下記のとおり起動します。
1)どこかにconfig.jsonファイルを作る。

{
  "port": 1883,
  "username": "your-username",
  "password": "your-password"
}

2)下のコマンドで起動する。

docker run -d --net=host -v /xxxxx/config.json:/app/config/config.json -e MQTT_OPTION_FILE=/app/config/config.json -e MQTT_BROKER="mqtt://your.mqtt.brocker" echonetlite2mqtt

Home Assistant側の設定はこちらの記事に書いてます。
sympapa.hatenablog.com

■更新後どうなった？

更新後もシャープのエアコンでは自動的に室温を取得してくれません。

と思いきや、Echonetlite2mqttのWeb画面にアクセスすると各項目に"Reload Value"のボタンが追加されていました。
室温の項目の"Reload Value"を押せば室温が取得出来ます。
そして、MQTTトピックを送信して"Reload Value"を要求する機能が追加されてました。
たとえば室温であれば下記のMQTTトピックを送信することで室温が更新されます。

echonetlite2mqtt/elapi/v1/devices/fe00-your-device-id-00000000000000/properties/roomTemperature/request

Home Assistantのオートメーションで15秒毎に室温の"Reload Value"をリクエストするするようにしました。
15秒毎ではありますが実質的にはこれで自動的に室温を取得できるようになりました。

alias: Echonetlite2mqtt_auto_reload
description: ''
trigger:
  - platform: time_pattern
    seconds: /15
condition: []
action:
  - service: mqtt.publish
    data:
      topic: >-
        echonetlite2mqtt/elapi/v1/devices/fe00-your-device-id-00000000000000/properties/roomTemperature/request
mode: single

■まとめ

特にまとめることはありませんが、これでHome AssistantとEchonet Liteの連携はほぼカンペキになったように思います(^^
それでは。