GentooやIoTの覚え書きブログ (original) (raw)

今まで、一般的なACPIのガバナーによる電源管理を行っていました。
せっかくAMD Ryzen 5 4500Uを搭載しているので、最新の電源管理、AMD P-state (amd-pstate)での管理に移行させます。

AMD P-stateは、今までACPIの大雑把な周波数管理ではなく、百以上のステップかつ低負荷時はさらに低い周波数になるように周波数管理すると共に、CPUそのものが能動的に周波数変更出来るようになった管理手法のようです。
AMD ZEN2以降のプロセッサで利用可能のようで、4500UはちょうどZEN2です。
AMD P-stateはKernelは5.17以降で利用可能、さらに6.3以降ではEnergy Preference Performance mode (amd_pstate_epp)のモード(どうやらamd-pstate=activeと指定する)で動作することでさらに低負荷時の効率化、(現時点でGentooでStableではない)6.4以降ではGuided モードがサポートされ、最大と最小をユーザーが指定し、その範囲でCPUが能動的に周波数を細かく変化させることが可能になるそうです。

ありがたいことに、Gentoo公式に日本語で設定方法の解説があります。
wiki.gentoo.org

しかし、この解説はちょっと玄人むけで不十分なのところや、私の環境ではこの通りに動かなかったところがありましたので補足をば。

Kernelの設定はGentoo公式の通りに設定し、make && make installします。

しかし、私の環境ではdmesgにエラーが。

kernel: amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled

amd-pstateが使われているかどうか調べるには、/sys/devices/system/cpu/cpu0/cpufreq/scaling_driverをcatで出力したときに、amd-pstateまたはamd-pstat-eppが出力されれば成功、acpi-cpufreqが出力されれば、amd-pstateがエラーで使えずACPI制御にフォールバックされている、と言うことになります。

gentoo ~ acpi-cpufreq

Gentooの解説にはこんなことが書いてあります。

このドライバを使用するためには、"CPPC"、"ACPI CPPC"、または類似の BIOS 設定を enabled または auto に設定しなくてはなりません。

UEFI(BIOS)設定を見ます。AMI BIOSでは次の階層にありました。

Advanced > AMD CBS > NBIO > SMU > CPPC

デフォルトでAutoになっているのですが、これが大きな落とし穴。
解決策はGentooの親戚Arch Linuxのサイトにありました。

wiki.archlinux.jp

一部のマザーボードは、必要な設定をファームウェア内で有効化しない場合があり、その結果 the _CPC object is not present in SBIOS or ACPI disabled エラーが発生します。UEFI で Enable CPPC やこれと似たような設定を Auto から Enabled に変更してください。この設定が UEFI に存在しない場合は、ベンダーのウェブサイトでアップデートがないか調べてください。

そう、UEFI(BIOS)の設定でCPPCがAutoだとdmegsに"the _CPC object is not present in SBIOS or ACPI disabled"エラーが出るというのです。
これ私の環境ドンズバです。
CPPCをEnabledに変更します。(Enableにしたときに出てくる値はデフォルトのままMin 0 Max FFにしています。)

そして、Kernelコマンドラインに2つのコマンドを追加する必要があります。
一つはAMD ZEN2以降に必要な共通設定amd_pstate.shared_mem=1を、もうひとつはamd_pstate=activeを設定してあげる必要があります。

※amd_pstate=activeの他にamd-pstate=passiveとamd_pstate=guidedがありますが、amd-pstate=passiveはAMD ZEN3以降のサポート、amd_pstate=guidedはKernel 6.4以降のサポートだそうで、私の環境(AMD ZEN2 & Kernel 6.3)ではamd_pstate=activeしか使えないようです。

このKernelコマンドラインをどこに設定するか? が、解説には書かれていません。
Gentooの場合は、/etc/default/grubのファイルの中でGRUB_CMDLINE_LINUX_DEFAULT=の行に書き込み、/bootをマウント後、grub-mkconfigで/boot/grub/grub.cfgを書き換えて、再起動です。

私の環境の/etc/default/grubには、GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=force"が設定されていたので、この後ろに追記します。

GRUB_CMDLINE_LINUX_DEFAULT="pcie_aspm=force amd_pstate.shared_mem=1 amd_pstate=active"

追記したら、grub.cfgを書き換えて再起動です。

gentoo ~ gentoo ~ gentoo ~

これでp-stateが使えるようになりました。

gentoo ~ amd-pstate-epp

今回はおま環なお話。

iPadから照明をコントロールするため、Raspberry Pi Zero Wと4chリレーや、ESP easy化したSONOFFを壁の中に埋め込み、GPIOを使って壁のスイッチからも、iPadのHomeからも、AndroidやWebページ上のHomeAssistatからも操作できるようにしています。

gentoolinux.hatenablog.com

gentoolinux.hatenablog.com

gentoolinux.hatenablog.com

リビングの照明はRaspberry Pi Zero Wでコントロールしていますが、それらのデバイスを司り、Homeアプリに中継するHomebrigeというミドルウェアは、Gentoo Linuxサーバーに設定しています。
先日、何気なくGentoo Linuxにインストールされているソフトウェアをバージョンアップすべく、emerge -uDN @worldを実行したところ、いつになく呆気なく、500以上のパッケージがノーエラーでバージョンアップできました。
そこで、再起動をかけたところ、なんだかcron.hourlyが毎時間エラーレポートをメールで送信してきています。
cron.hourlyには、homebridgeのプロセスに異常があった場合、再起動するように仕掛けてます。(それくらい不安定だった。)
が、どうやらnode.jsがバージョンアップされたためにエラーが起きていたらしいのです。

homebridge porosess is not found. Starting homebridge

/usr/local/lib/node_modules/homebridge/lib/logger.js:9 const chalk_1 = __importDefault(require("chalk")); ^ Error [ERR_REQUIRE_ESM]: require() of ES Module /usr/local/lib/node_modules/homebridge/node_modules/chalk/source/index.js from /usr/local/lib/node_modules/homebridge/lib/logger.js not supported. Instead change the require of index.js in /usr/local/lib/node_modules/homebridge/lib/logger.js to a dynamic import() which is available in all CommonJS modules. at Object. (/usr/local/lib/node_modules/homebridge/lib/logger.js:9:33)

そこで、これらを解消しようと、まずnpmでhomebridgeをアップデートしようとしました。

gentoo / npm WARN npm npm does not support Node.js v20.11.0 npm WARN npm You should probably upgrade to a newer version of node as we npm WARN npm can't make any promises that npm will work with this version. npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 8. npm WARN npm You can find the latest version at https://nodejs.org/ npm ERR! cb.apply is not a function

npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2024-02-27T14_26_31_191Z-debug.log

意訳すると「このnpmはNode.js v20.11.0をサポートしてないよ。node.jsをアップデートしないとダメだよ。このnpmはnode.jsのバージョン4,6,7,8をサポートしてるよ。」
って、ここに入っているnode.jsはgentooでは最新のv20なんですけど・・・。

そして、自分の所業を遡ると、こんなことが書いてました。

gentoolinux.hatenablog.com

これを読むと、「useフラグにnpmをつけてnodejsをemergeすると、勝手にnpmも入ってくるよ」と。
ということは、今使っているnpmは何らかの理由で(理由は忘れた)、オーバーレイインストールしたか、無理矢理手動インストールしたかのどちらかです。

npmはどこにあるのか?

gentoo / 5.5.1 gentoo / /usr/local/bin/npm gentoo / lrwxrwxrwx 1 root root 38 11月 14 2017 npm -> ../lib/node_modules/npm/bin/npm-cli.js

実態であるnpm-cli.jsのバージョンが古いんですね。しかも、/usr/local/libにインストールしているということは、公式リポジトリ以外からインストールしているっていうことですね。
npmをUSEフラグに記述しているので、node.jsのアップデート時に、最新のnpmがどこかにインストールされているはずです。

gentoo / /var/tmp/portage/net-libs/nodejs-20.8.1/work/node-v20.8.1/deps/npm/bin/npm-cli.js /var/tmp/portage/net-libs/nodejs-20.8.1/work/node-v20.8.1/deps/npm/test/bin/npm-cli.js /var/tmp/portage/net-libs/nodejs-20.9.0/work/node-v20.9.0/deps/npm/bin/npm-cli.js /var/tmp/portage/net-libs/nodejs-20.9.0/work/node-v20.9.0/deps/npm/test/bin/npm-cli.js /usr/local/n/versions/node/8.9.1/lib/node_modules/npm/bin/npm-cli.js /usr/local/n/versions/node/9.0.0/lib/node_modules/npm/bin/npm-cli.js /usr/local/lib/node_modules/npm/bin/npm-cli.js /usr/lib64/node_modules/npm/bin/npm-cli.js

gentoo / 10.2.4

公式リポジトリ上のnpmは/usr/lib64/node_modules/npm/bin/npm-cli.jsにあるようです。
ということは、公式リポジトリからリンクされているnpm自体も、/usr/local/binではない場所にありそうです。

gentoo / /etc/npm /var/tmp/portage/net-libs/nodejs-20.8.1/work/node-v20.8.1/deps/corepack/shims/npm /var/tmp/portage/net-libs/nodejs-20.8.1/work/node-v20.8.1/deps/corepack/shims/nodewin/npm /var/tmp/portage/net-libs/nodejs-20.8.1/work/node-v20.8.1/deps/npm /var/tmp/portage/net-libs/nodejs-20.8.1/work/node-v20.8.1/deps/npm/bin/npm /var/tmp/portage/net-libs/nodejs-20.8.1/work/node-v20.8.1/tools/msvs/npm /var/tmp/portage/net-libs/nodejs-20.8.1/work/node-v20.8.1/tools/macos-installer/pkgbuild/npm /var/tmp/portage/net-libs/nodejs-20.9.0/work/node-v20.9.0/deps/corepack/shims/npm /var/tmp/portage/net-libs/nodejs-20.9.0/work/node-v20.9.0/deps/corepack/shims/nodewin/npm /var/tmp/portage/net-libs/nodejs-20.9.0/work/node-v20.9.0/deps/npm /var/tmp/portage/net-libs/nodejs-20.9.0/work/node-v20.9.0/deps/npm/bin/npm /var/tmp/portage/net-libs/nodejs-20.9.0/work/node-v20.9.0/tools/msvs/npm /var/tmp/portage/net-libs/nodejs-20.9.0/work/node-v20.9.0/tools/macos-installer/pkgbuild/npm /usr/local/n/versions/node/8.9.1/bin/npm /usr/local/n/versions/node/8.9.1/lib/node_modules/npm /usr/local/n/versions/node/8.9.1/lib/node_modules/npm/bin/npm /usr/local/n/versions/node/9.0.0/bin/npm /usr/local/n/versions/node/9.0.0/lib/node_modules/npm /usr/local/n/versions/node/9.0.0/lib/node_modules/npm/bin/npm /usr/local/bin/npm /usr/local/lib/node_modules/npm /usr/local/lib/node_modules/npm/bin/npm /usr/lib64/node_modules/npm /usr/lib64/node_modules/npm/bin/npm /usr/bin/npm /usr/share/bash-completion/completions/npm /root/.npm/registry.npmjs.org/npm /root/.npm/npm

gentoo / lrwxrwxrwx 1 root root 40 2月 25 03:27 /usr/bin/npm -> ../lib64/node_modules/npm/bin/npm-cli.js

gentoo / 10.2.4

何のことはない、/usr/local/bin/npmを削除して、今後は/usr/bin/npmを使えば良いだけのことでした。

これでhomebridgeを起動してもエラーが起きます。

[2024/2/27 22:53:10] TypeError: Invalid initialization vector at Cipheriv.createCipherBase (node:internal/crypto/cipher:121:19) at Cipheriv.createCipherWithIV (node:internal/crypto/cipher:140:3) at new Cipheriv (node:internal/crypto/cipher:243:3) at Object.createCipheriv (node:crypto:146:10) at Object.chacha20_poly1305_encryptAndSeal (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/util/hapCrypto.ts:90:25) at HAPServer._this._handlePairVerifyStepOne (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/HAPServer.ts:553:33) at HAPServer._this._handlePairVerify (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/HAPServer.ts:515:12) at IncomingMessage. (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/HAPServer.ts:280:24) at IncomingMessage.emit (node:events:518:28) at endReadableNT (node:internal/streams/readable:1696:12) [2024/2/27 22:53:10] Got SIGTERM, shutting down Homebridge...

まずは、関連モジュールをアップデートします。
アップデートにはnpm-check-updates(コマンドは頭文字を取ってncu)を使うと良いそうですので、npmでインストールし、ncu -uでアップデート情報をpackage.jsonに書き込み、npm installでpackage.jsonに書かれた情報から各パッケージをアップデートします。

gentoo / added 336 packages in 16s

67 packages are looking for funding run npm fund for details

gentoo / Upgrading /usr/local/lib/node_modules/homebridge/package.json [====================] 20/20 100%

@types/debug ^4.1.5 → ^4.1.12 @types/jest ^26.0.13 → ^29.5.12 @types/node 10.17.29 → 20.11.20 @types/semver ^7.3.3 → ^7.5.8 @typescript-eslint/eslint-plugin ^4.0.1 → ^7.1.0 @typescript-eslint/parser ^4.0.1 → ^7.1.0 chalk ^4.1.0 → ^5.3.0 commander 5.1.0 → 12.0.0 eslint ^7.8.1 → ^8.57.0 eslint-plugin-jest ^23.20.0 → ^27.9.0 hap-nodejs ^0.7.10 → ^0.11.1 jest ^26.4.2 → ^29.7.0 node-persist ^0.0.11 → ^4.0.1 rimraf ^3.0.2 → ^5.0.5 semver ^7.3.2 → ^7.6.0 source-map-support ^0.5.19 → ^0.5.21 ts-jest ^26.3.0 → ^29.1.2 ts-node ^9.0.0 → ^10.9.2 typescript ^4.0.2 → ^5.3.3

Run npm install to install new versions.

gentoo /

added 546 packages, removed 11 packages, changed 58 packages, and audited 609 packages in 36s

116 packages are looking for funding run npm fund for details

found 0 vulnerabilities

そして最後に、肝心のhomebridgeそのものもアップデートしましょう。

gentoo /

added 91 packages, removed 16 packages, and changed 14 packages in 2s

43 packages are looking for funding run npm fund for details

それでもエラーが出ます。

gentoo / Starting homebridge

/usr/local/lib/node_modules/homebridge/lib/logger.js:9 const chalk_1 = __importDefault(require("chalk")); ^ Error [ERR_REQUIRE_ESM]: require() of ES Module /usr/local/lib/node_modules/homebridge/node_modules/chalk/source/index.js from /usr/local/lib/node_modules/homebridge/lib/logger.js not supported. Instead change the require of index.js in /usr/local/lib/node_modules/homebridge/lib/logger.js to a dynamic import() which is available in all CommonJS modules. at Object. (/usr/local/lib/node_modules/homebridge/lib/logger.js:9:33)

よく読むと、そもそもhomebridge自体も/usr/local/binにあるもののようです。
最新のhomegridgeはどこなのか?

gentoo / /var/homebridge /usr/local/bin/homebridge /usr/local/lib/node_modules/homebridge-http-switch/test/homebridge /usr/local/lib/node_modules/homebridge /usr/local/lib/node_modules/homebridge/bin/homebridge /usr/lib64/node_modules/homebridge /usr/lib64/node_modules/homebridge/bin/homebridge /usr/bin/homebridge /root/.npm/registry.npmjs.org/homebridge

やはり、/usr/bin/homebridgeがありましたね。

/etc/local.d/homebridge.startの内容を変更します。

name="homebridge" pid_file="/var/run/$name.pid" stdout_log="/var/log/$name.log" stderr_log="/var/log/$name.err"

echo "Starting $name"

/usr/bin/homebridge -U /var/homebridge & echo !>"! > "!>"pid_file"

あと、node.js自体も、/usr/local/bin/nodeにシンボリックリンクあるので、/usr/local/bin/npmや/usr/local/bin/homebridgeと一緒に消しておきます。
(これらはシンボリックリンクなので、消しても実体は残っています。)

これで無事にhomebridgeが起動・復活しました。

家じゅうにWiimを設置するほど、Wiimにハマりましたが、これに飽き足らずクルマにも設置しようと思い立ちました。
しかし、Wiim MiniのDACはPCM5121という、スペック的にもワンランク低いものが積まれており、せっかくのビットパーフェクトをスポイルしていると思います。
そこで、Wiim Miniの光出力から別体のDACを通したいと思い、物色したところ、車載するのに相応しい仕様のDACが見つかりました。
FX-AUDIO-『FX-05J』です。

nfjapan.com

なぜこれが車載に相応しいかというと、電源スイッチがないところ。
見えないところに隠すので、イグニッションオン＝通電で起動して欲しいのです。
DACチップもESS社のES9018K2Mという、過去に音が良いとされた9018Sのモバイル向けチップ。
ちょっと前のハイエンドポータブルヘッドホンアンプ、通称ポタアンなどのDACとして採用されることが多かった、音質には定評のあるチップです。
しかし、アマゾンの評価の一部に、「手持ちのアンプの方が音が良い」というような気になる記述が。
そこで、購入後にオペアンプとカップリングコンデンサを載せ替えることにします。

まず、購入後の素の状態のFX-05Jを聞いてみます。
オペアンプはTL062CNという、低消費電力であるものの、音質的には標準というかイマイチなものが入っています。

ぱっと聞いた感じ、それほど悪くないので、そのまま車載しても良いのでは? と、思いましたが、しばらく聞いてみると、高音の解像感や透明感が足りず、音が平面的で広がりも少ない感じです。
試しに、いつも使っているAK4499EXの音に戻して同じ楽曲を聴いてみると、全然違いました。高音の透明感があり、ハイハットなどの金属音が澄んでますし、全音域で解像感が高く、低音もバシッと輪郭がはっきりしています。大きく違った！
これは、ES9018K2Mの本領が発揮されていないな?と、感じました。

で、オペアンプとカップリングコンデンサ探しです。
このサイトを参考にさせていただきました。

spkoba1.web.fc2.com

TL062はJ-FET入力で2回路という仕様。
この仕様を満たすオペアンプを搭載する必要があります。

一番手に挙げたのは、やはりオペアンプの王様、JRCのMUSES01。
仕様通りなのですが、問題はその価格。なんと3,000円以上!
本体が3,980円なのに、本体と同価格のオペアンプはやり過ぎだな、と、思うわけです。
そこで、MUSES01のワンランク廉価版のNJM8901にしたかったのですが、DIPタイプのパッケージが見つかりません。
仕方なく、表面実装型のSOP8のNJM8901Eと変換基板を購入することにしました。

eleshop.jp

そして、カップリングコンデンサは、車に積むことを考えて105℃品をチョイス。
KAシリーズの33μFのものにしました。

eleshop.jp

まずは、NJM8901Eを変換基板にはんだ付けします。
チップを変換基板にセロテープで仮止めし、動かないようにします。
●の窪みがあるところが1番ピンです。
細いピンになんとかハンダを載せ、テスターでショートしていないか確認します。
変換基板にDIP足をはんだ付けして完成です。

さっそくFX-05JのTL062と載せ換えます。
FX-05Jは1.5のヘックスレンチ(六角レンチ)で側面から開けます。
RCAピンがある方を開けた方が良いでしょう。

側面の4つのボルトを外すと、側面が取れ、そこから基板ごと引き出すことができます。
引き出すと、TL062が見えます。

これを引き抜いて、NJM8901Eを刺します。

まず、カップリングコンデンサを載せ換える前に、NJM8901Eだけ載せ換えた時の音質チェックをやってみます。
すると、どうでしょう。
あからさまに音質が変わりました!
高音は解像感高く、澄んだ音になり、ハイハットなどの金属音に雑味が一切なくなりました。
低音もバスドラムなどの音の輪郭がはっきりしています。
チャンネルセパレーションが良くなったのか、左右の広がりも広く感じられます。
数百円のオペアンプひとつでこんなに変わるものかと思いました。
ES9018K2Mのポテンシャルをしっかりと引き出せたんじゃないかと思います。

さて、次はカップリングコンデンサの載せ換えです。
もともとはルビコン製の10μFが載っています。

Rの文字がルビコンを表しているのでしょうか?

16V、10μF、85℃という表示が見えます。
これを33μFの105℃品、ニチコンKAに変更します。
いきなり変更後の写真ですが、背の高さが電源用の他のコンデンサと同じ高さで、ギリギリだったようです。

完成後の試聴です。
オペアンプ載せ換えの音質インパクトが高すぎて、あまり大きく変わった印象がなく、むしろルビコンのままのほうがよかったんじゃないか? と、思わせるほど、カップリングコンデンサを載せ換える意味は薄かったように感じます。
とはいえ、もう後戻りはできないので、このままでいきます。

メーカーはUSB電源で駆動することを考えてTL062を採用したのだと思いますが、数百円の部品の違いでここまで音が変わるのですから、最初から別のオペアンプを載せてくれればなぁ・・・。と、思ってしまうのでした。
とはいえ、少しの出費で大きく音質向上を果たせたので、大満足の改造でした。

あ、念の為、改造は自己責任で。
保証が受けられなくなりますよ！

先日、Wiimの再生情報をHome Assistantに表示させるようにましたが、個別のWiimを認識させるためにはIPアドレスを指定する必要がありました。

gentoolinux.hatenablog.com

WiimにはIPアドレスを指定する方法がなく、DHCPのみなので、RTX810側のDHCP設定で固定IPアドレスを配布しなければなりません。
RTXでは「DHCP予約アドレス」というそうです。

www.rtpro.yamaha.co.jp

これを読むと、MACアドレスと紐付けすれば良いのね、と、思っちゃうところですが、クライアントがIDを報告するタイプだと、MACアドレスで指定できません。
WiimはIDを報告するタイプです。(というか、最近のデバイスはほぼIDを報告するようです。)
IDを調べるには、RTXでDHCPのステイタスを表示されるとわかります。

DHCP Scope number: 1 Network address: 192.168.0.0 Leased address: 192.168.0.xxx (type) Client ID: (01) f4 81 00 00 00 00 00 Remaining lease: 2days 22hours 55min. 21secs. (中略) Leased address: 192.168.0.yyy (type) Client ID: (ff) 6c 24 41 c8 00 01 00 01 2c 10 27 00 00 00 00 00 00 01 Host Name: WiiM Pro-BC02 Remaining lease: 2days 14hours 7min. 24secs.

WiimはHost Nameを報告してくれるので、大変見つけやすいです。
このClient IDをどう指定するのか? がわかりにくいのです。
この(ff)も含めて指定する必要があるのですが、カッコが不要、というのがなかなかわかりにくいのです。
3台のWiimのDHCPを固定するには、次のようなConfigになります。

dhcp scope bind 1 192.168.0.xxx ff 6c 24 41 c8 00 01 00 01 2c 10 27 00 00 00 00 00 00 01 dhcp scope bind 1 192.168.0.yyy ff 32 1e 30 24 00 01 00 01 c7 92 bc 00 00 00 00 00 00 02 dhcp scope bind 1 192.168.0.zzz ff 35 06 15 8e 00 01 00 01 c7 92 bc 00 00 00 00 00 00 03

show status dhcpでは(ff)で始まっていたのに、dhcp scope bindで指定する際はffで始めなければなりません。

また、上記ではbindの後ろはスコープIDを指定します。上記では1を指定していますが、DHCPのスコープ(リースするIPアドレスの範囲)を指定した時に付与したスコープ番号を指定する必要があります。
(スコープ範囲を複数設けることはあまりないと思うので、大抵はひとつかと思います)
スコープIDを誤ってもエラー等は一切出てこないので、気をつけてください。

拙宅にはWiim Proが1台、Wiim miniが2台あります。
これをHome Assistantのフロントエンドに表示させたい。
ついでにビット深度とサンプル周波数も表示させたい。

まずは、Githubにあるwiim-customをダウンロードします。

github.com

これを、コンフィグのあるディレクトリにインストールします。
ウチだと
/home/homeassistant/.homeassistantの下です。
この下にcustom_components/というディレクトリを作ることで、公式以外のインテグレーションをインストールできます。
最終的に、/home/homeassistant/.homeassistant/custom_components/wiim_customという下にpyやjsonなんかがあるような形になります。
chownやchmodで実行権限を付与しておきます。

で、configuration.yamlに3台のWiimの設定を書きます。

media_player: - platform: wiim_custom host: 192.168.0.xxx name: My room Wiim Pro uuid: 'FF98F09Cxxxxxxxxxxxxxxxxxxx'

- platform: wiim_custom
  host: 192.168.0.yyyy
  name: Bedroom Wiim mini
  uuid: 'FF970016xxxxxxxxxxxxxxxxxxx'

- platform: wiim_custom
  host: 192.168.0.zzz
  name: Living Wiim mini
  uuid: 'FF970016xxxxxxxxxxxxxxxxxxx'

インテグレーションを読み込ませるために、HomeAssistantのデーモンを再起動します。
そうすると、自動的にWiimのエンティティが出来上がります。
ダッシュボードにメディアコントロールのカードを追加すると再生情報が表示されます。

開発ツールからwiimのエンティティを眺めていると、属性にビット深度、サンプルレート、ビットレートがあります。これはなんとか表示したい!
過去のアップデートで、エンティティカードに属性を表示させることができるようになったそうです。

www.home-assistant.io

垂直スタックのカードを使って、メディアコントロールの下に属性のエンティティを表示させましょう。
3台のWiimすべてに属性を表示させます。
いきなり答えですが、こうなります。
なぜかビット深度だけ、数字だけが表示されるので、suffix: bitを付けています。

type: vertical-stack cards:

こんな感じで表示されます。(1台だけ再生しています。)

DLNAサーバーのGerberaはこれらの属性情報をよこさないらしく、表示されません。

寝室の照明を消そうとHome AssistantのAndroidアプリを立ち上げても、ウントもスントも言わなくなりました。
試しにブラウザからアクセスしても、上記のとおり・・・。
Home Assistantが起動していないのかしら？ と思いps -ef | grep homeaを実行すると、やはり起動しておらず。
Home Assitantを起動してみるも、そもそもpythonが見つからない模様。
pythonのアップデートによって、シンボリックリンクが切れたようです。
今までのpythonは3.9

gentoo /home/homeassistant/bin $ ls -al 合計 208 drwxr-xr-x 3 homeassistant homeassistant 4096 9月 1 2021 . drwxr-xr-x 8 homeassistant homeassistant 4096 11月 11 03:58 .. (中略) lrwxrwxrwx 1 homeassistant homeassistant 7 12月 4 2017 python -> python3 lrwxrwxrwx 1 homeassistant homeassistant 38 9月 1 2021 python3 -> /usr/lib/python-exec/python3.9/python3 lrwxrwxrwx 1 homeassistant homeassistant 7 9月 1 2021 python3.9 -> python3

pythonのアップデートは、昔の記事に書いてました。

gentoolinux.hatenablog.com

シンボリックリンクが置き換えられました。

gentoo /home/homeassistant/bin $ ls -al 合計 209 drwxr-xr-x 3 homeassistant homeassistant 4096 9月 1 2021 . drwxr-xr-x 8 homeassistant homeassistant 4096 11月 11 03:58 .. (中略) lrwxrwxrwx 1 homeassistant homeassistant 7 12月 4 2017 python -> python3 lrwxrwxrwx 1 homeassistant homeassistant 39 12月 9 11:22 python3 -> /usr/lib/python-exec/python3.11/python3 lrwxrwxrwx 1 homeassistant homeassistant 7 12月 9 11:22 python3.11 -> python3 lrwxrwxrwx 1 homeassistant homeassistant 7 9月 1 2021 python3.9 -> python3

これでめでたくHome Assistantを起動できる!!
と思ったものの、やはりウントもスントも言わない。
これはHome Assistantそのものをバージョンアップするしかない。と思ったら、いろいろハマりました。

gentoo /home/homeassistant/.homeassistant 2023-12-09 12:10:12.817 ERROR (MainThread) [homeassistant.components.switch] Error while setting up command_line platform for switch Traceback (most recent call last): File "/home/homeassistant/lib/python3.11/site-packages/homeassistant/helpers/entity_platform.py", line 361, in _async_setup_platform await asyncio.shield(task) File "/home/homeassistant/lib/python3.11/site-packages/homeassistant/components/command_line/switch.py", line 42, in async_setup_platform entities: dict[str, Any] = {slugify(discovery_info[CONF_NAME]): discovery_info} ~~~~~~~~~~~~~~^^^^^^^^^^^ TypeError: 'NoneType' object is not subscriptable

どうやらコンフィグが古くて動かない模様。
しかし、いつかやらなければならないコンフィグの改修。重い腰を上げました。

まず、拙宅のリビング照明はRaspberry Pi Zero WにWebIOPiをインストールし、GPIOにリレーを3つ繋いでおります。
gentoolinux.hatenablog.com
gentoolinux.hatenablog.com

それと、寝室にESP-Easy化したSONOFFを導入しています。
gentoolinux.hatenablog.com

これらは、最初にswitch:というインテグレーターセクションの中に、platform:command_lineと定義して記載していました。
gentoolinux.hatenablog.com

curlコマンドを使い、WebIOPiやESP-EasyのWebを叩きに行く、ということです。
value_template: で、スイッチがオンの時の値を定義します。

しかし、2023.12.1バージョンでは、エンティティ毎に定義するようで、まず先頭にswitchではないようです。
おそらく様々なswitchを定義できるようにしたのでしょう。
新旧で見ていきます。

旧

switch:

旧書式ではswitch:の下に、platformでどういったプロトコルで処理するかを定義し、switches:で複数のスイッチを定義しました。
switches:の下には、任意にエンティティ名を付与しましたが、これは特にHome Assistantで使われることもなく、friendly_nameでが使われました。
そして、switch:インテグレーションが廃止され、command_line:が先頭に来ることになりました。
さらに、switches:も廃止。
friendly_name: もname:に変わりました。
そうしてできた新書式がコチラ

command_line: - switch: command_on: "/usr/bin/curl -X POST http://192.168.0.xxx:8000/GPIO/26/value/0" command_off: "/usr/bin/curl -X POST http://192.168.0.xxx:8000/GPIO/26/value/1" command_state: "/usr/bin/curl -X GET http://192.168.0.xxx:8000/GPIO/26/value" value_template: '{{ value == "0" }}' name: Living SnowBall

- switch:
   command_on: "/usr/bin/curl -X POST  http://192.168.0.xxx:8000/GPIO/6/value/0"
   command_off: "/usr/bin/curl -X POST  http://192.168.0.xxx:8000/GPIO/6/value/1"
   command_state: "/usr/bin/curl -X GET  http://192.168.0.xxx:8000/GPIO/6/value"
   value_template: '{{ value == "0" }}'
   name: Living PH5 Plus

- switch:
   command_on: "/usr/bin/curl -X POST  http://192.168.0.xxx:8000/GPIO/19/value/0"
   command_off: "/usr/bin/curl -X POST  http://192.168.0.xxx:8000/GPIO/19/value/1"
   command_state: "/usr/bin/curl -X GET  http://192.168.0.xxx:8000/GPIO/19/value"
   value_template: '{{ value == "0" }}'
   name: Living Spot and Bracket

- switch:
   command_on: "/usr/bin/curl -X GET http://192.168.0.yyy/control?cmd=event,PowerOn"
   command_off: "/usr/bin/curl -X GET http://192.168.0.yyy/control?cmd=event,PowerOff"
   command_state: "/usr/bin/curl -X GET http://192.168.0.yyy/control?cmd=status,gpio,12"
   value_template: '{{ value_json.state == 1 }}'
   name: Bedroom Light

これでめでたく各々の照明をコントロールできるようになります。
エンティティ名が変更になったようで、ダッシュボードにエンティティを再登録する必要があります。

続いて、センサーです。
ESP-Easyに温湿度センサーを繋ぎ、jsonで値を返しています。
gentoolinux.hatenablog.com

書式は間違ってなさそうですが、コネクションタイムアウトします。

2023-12-09 16:08:51.036 WARNING (MainThread) [homeassistant.components.sensor] Platform rest not ready yet: All connection attempts failed; Retrying in background in 30 seconds 2023-12-09 16:09:21.052 ERROR (MainThread) [homeassistant.components.rest.data] Error fetching data: http://192.168.0.zzz/json?tasknr=1 failed with All connection attempts failed

ブラウザから見るとちゃんとjsonを返します。
そこで考えられるのが、Home Assistantが同一URLを2つ同時にリクエストし、ESP-Easyが処理落ちしているのではないかということ。
旧書式はこうでした。

sensor:

ごくまれに、温度か湿度のどちらかだけ表示されることがあり、変だな?と、思っていたので、ここが怪しいです。
RestAPIを使い、1つのリソースで2つ以上の値を取得するには、senser:ではなく、rest:インテグレーターで開始し、resourceを一つだけ書く、という風にすればよいようです。
新書式はこうなります。

rest: resource: http://192.168.0.zzz/json?tasknr=1 sensor: - name: Living Temp value_template: "{{value_json.temperature}}" device_class: temperature unit_of_measurement: "°C" - name: Living Hum value_template: "{{value_json.humidity}}" device_class: humidity unit_of_measurement: "%"

だいぶスッキリしましたね。

あと、フロントエンドで「国が設定されていない」と、設定画面に誘導されるのですが、設定画面では「設定がconfiguration.yamlに保存されているため、エディタが無効になっています。」と表示され、一切の編集や保存ができません。
これはconfiguration.yamlの先頭にいろいろと定義を入れているからだそうです。
どんどんコメントアウトします。

旧書式

homeassistant:

name: Sample_home

latitude: 42.0000 longitude: 141.0000

elevation: 20

unit_system: metric

time_zone: Asia/Tokyo

customize: !include customize.yaml

新書式

homeassistant:

その代わり、Home Assistantの名称なども、イチから設定しなおしになります。
ブラウザからフロントエンドにアクセスして設定するだけなので簡単です。

さ、これでHome Assistantをデーモンとして起動しよう!
と、思ったら、起動しない。
デーモンではなく、通常のプロセスとしては起動するのです。
どうやら、--daemon や --pid-fileなどのオプションが廃止されたようです。
拙宅ではHome AssistantをGentooで動かしています。なので、Gentooのお作法に則って/etc/local.d/homeassistant.startに起動処理を、/etc/local.d/homeassistant.stopに停止処理を記載しています。
単なるバックグラウンド起動は&を付ければよいのですが、pid番号をファイルに記載しておかなければ、停止時にpidがわかりません。
そこで、start-stop-daemonから起動してもらうことにしました。

旧/etc/local.d/homeassistant.start

sudo -u homeassistant -H /home/homeassistant/bin/hass --pid-file /home/homeassistant/hass.pid --log-file /var/log/home-assistant.log 2>&1 echo "Homeassistant Started"

新/etc/local.d/homeassistant.start

USER=homeassistant DAEMON=/home/homeassistant/bin/hass PIDFILE=/home/homeassistant/hass.pid start-stop-daemon --start --quiet --chuid USER−−userUSER --user USER−−userUSER --background --pidfile PIDFILE−−make−pidfile−−execPIDFILE --make-pidfile --exec PIDFILE−−make−pidfile−−execDAEMON

echo "Homeassistant Started"

本当は、リターンコードを判断してif文で起動失敗時にはその旨メッセージを出す必要があるのでしょうが、面倒なのでヤメます。

これでめでたくHome Assistantで照明のスイッチをパチパチできます。

あと、特に不便は感じてませんが、フロントエンドから各スイッチやセンサーのエンティティを編集しようとしても、読み取り専用となっており、「このエンティティ ('switch.bedroom_light') にはユニークなIDがないため、UIから設定を管理構成できません。詳しくは、ドキュメント を参照してください。」と出てきます。ユニークなIDですか・・・。

先日、RTX1200を弟宅に設置したと書きました。

gentoolinux.hatenablog.com

いつかDS-LiteのAFTRアドレスが変更になって、「なんかネット繋がらなくなったぞ！」と、言われたときの保守用に、札幌ー帯広間をNGN網内でのIPSec接続をしています。
札幌のRTX810と帯広のRTX1200のIPv6アドレスを、「OPEN IPv6 ダイナミック DNS for フレッツ・光ネクスト」を使ってDNS登録し、接続相手先をFQDN指定して、IPv6アドレスが変更されても接続できるようにしています。

しかし、念には念を入れて、IPv4でL2TP/IPsecでも接続できるようにします。
が、またもここでもハマりました。

まず、RTX1200ではDHCPスコープを192.168.1.20-192.168.1.100/24に設定しており、フィルタールーティングを使い、

ip route default gateway tunnel 1 gateway pp 1 filter 200200
ip filter 200200 pass 192.168.1.101-192.168.1.102 * * * *

として、192.168.1.101と102はPPPoEへ、それ以外(DHCPクライアント等)はDS-Liteを設定したtunnel1へ、ルーティングするようにしました。
L2TP/IPsecで接続してきた端末には192.168.1.101を付与し、PPPoEで通信させる、という意図です。

L2TP/IPsecの設定はYAMAHAサイトの設定(アドレス不定)の通りにします。

network.yamaha.com

もちろん、IPアドレスが変わっても良いように、netvolante-dnsの設定をpp1に入れておきます。

Windows10マシンから自宅のRTX810にアクセスするVPN設定を複製し、帯広のRTX1200にアクセスできるように、接続先アドレス、ユーザー名、事前共有キーを書き換えます。
RTX1200をsyslog debug onにして、札幌からアクセスしてみると、接続できずにタイムアウトします。
RTX810に接続できたログと比較すると、IKEのSA交換で失敗し、次のようなログが吐かれていました。

[IKE] [8] retransmission timeout

これを元にして調べると、なんと、ごちゃんねるに解決策が!!
「DS-LiteとPPPoEで接続し、PPPoE側でL2TP/IPsecが接続できずに困っている」って、まるで俺か⁉︎
どうやら、RTX1200がSAキーを返そうとしているが、Windows側が応答していないとのことで、その理由は、Windows→RTX1200はPPPoEを経由しているのに対し、RTX1200→WindowsはDS-Liteを経由しているから、ということのようです。
IPv4グローバルアドレスが与えられてFirewallがない丸裸のWindowsだったら応答していたでしょうが、札幌側のWindowsはRTX810のNATの内側にいるので、RTX810にはじかれてWindows側に届いていないのです。
そこで、フィルタールーティングの対象IPアドレスにRTX1200のアドレス192.168.1.1も含めるようにします。
具体的には、

ip route default gateway tunnel 1 gateway pp 1 filter 200200
ip filter 200200 pass 192.168.1.1,192.168.1.101-192.168.1.102 * * * *

YAMAHAのルーターの良いところはIPアドレスを「,」で区切ったり「-」で範囲指定するなど、複数のIPアドレスを一度に指定できるところですね。
RTX1200をPPPoE経由でインターネットに出れるように設定したところ、L2TP/IPsecで接続できるようになりました。
もちろん、Mac OSからもL2TP/IPsecできています。

まさかごちゃんねるに助けられるとは・・・。