Raspberry Pi buster 更新でトラブル
自宅の Raspberry-Pi を buster に更新してみた。
定番の /etc/apt/sources.list の stretch を buster に書き換えて、
$ sudo aptitude update ; sudo aptitude safe-upgrade 大量にインストール... $ sudo reboot
しかし、起動時に eth0 も認識せずに、emergency mode になってしまった。
root パスワードでログインし、手作業で eth0 を認識させて…。
原因としては、raspi-copies-and-fills が原因のようなので、削除。
$ sudo aptitude purge raspi-copies-and-fills
二酸化炭素レベル測定で換気判定
コロナ対策で、空気中の二酸化炭素レベルを測定して換気を行う事例をテレビでやっていたので、I2C接続のセンサーをAmazonでポチって、ちょいプログラム作成。(取り付け時のメモ) センサー値が安定するまで時間がかかるというものなので、daemon化させる必要もあって、ちょっと面倒だったけどうまく動くようになった。
考察
センサーのeCO2が400ppm以下は判定できないので、こんなグラフが取れるようになった。ファンヒーターをつけるとグラフが上がっていく。1000ppm以上だと換気推奨レベル。とはいえ、朝の冷え切った部屋が温まるまでは、換気もできんけど。
グラフ中の8:00-12:00は、daemon化させていたプログラムのバグ直しまでの影響だけど、このセンサーはeCO2の値は、2000ppm が上限みたいだな。ソースコード確認したら、eCO2>2000 , TVOC>1200 は異常値扱いしていた。販売元のページには、測定レンジもう少し広い値だったので、プログラムの方を修正。
グラフの立ち上がりは、ファンヒーターが原因だけど、夜中の3:30にグラフが立ち上がってるのが原因不明だなぁ…。
一番ありそうな仮説。猫が「コレ何?」と、センサー周りでクンカ・クンカでもしたのかなぁ….Raspberry-Pi+センサー、テレビの台に置いてあるからなぁ…
温度湿度センサーをBME280に切り替え
自室の温度測定には、USBRH というセンサーとそれに伴うソフトを使っていたけど、使っていたライブラリの都合で、Raspberry-pi のバージョンを最新にできずにいたけど、今回 同じようにI2Cの温度・湿度・気圧のセンサー BME280 を購入し温度測定のプログラムを切り替えた。
ということで、そろそろ Raspberry-Pi のOS更新もやろうかな。
bind9でfilter-aaaaがpluginになる
自宅サーバを使っていて、raspberry-pi の更新をかけていたら、IPv6アドレスにつながらないトラブル発生。
我が家では、上流が IPv4-only だけど、自宅内の機器間のに IPv6 も使えるようにしている。このため、DNS の設定では、bind9 に、filter-aaaa-on-v4 の設定を加え、IPv4 の機器からの問い合わせには、IPv4 のみを返答することで、対応していた。
しかし、改めて “nslookup www.google.com 192.168.xx.xx” を実行したら、IPv4からの問い合わせの癖に、しっかり IPv6 が返ってきている。
調べてみると、bind9 (9.14)から filter-aaaa 機能は plugin になるみたい。んで、自宅サーバは 9.11→9.16 により filter-aaaa がoffになったのが原因…と思ったけど、syslog をみると “–enable-filter-aaaa”付きでcompileされてるし、”option ‘filter-aaaa-on-v4’ is obsolete and should be removed” と表示されてるから、現状では、まだ使えているはず。
ひとまず IPv6 オフ
ラズバイは、ひとまず下記の設定で、IPv6 をオフにしておく。
$ sudo /etc/sysctl.conf ((下記を追加)) net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 $ sudo sysctl -p
これは、IPv6 が戻ったら、元に戻そう。
bind9 に plugin の filter-aaaa 設定
plugin になったら、下記のような設定をするようだけど、うまくいかないので近日中に要対応。
$ sudo vi /etc/bind/named.conf.options plugin query "/usr/lib/x86_64-linux-gnu/named/filter-aaaa.so" { filter-aaaa-on-v4 yes ; filter-aaaa-on-v6 yes ; filter-aaaa { any ; } } ;
UbuntuなMacbookair(2011)、WiFi動かず
以前に愛用していたMacbook Air(2011)だけど、性能不足からUbuntuを入れていたけど、ちょい Terminal として使おうと起動させたら、Ubuntuは立ち上がるけど、WiFiがつながらない。色々再起動もかけたけど、やっぱり起動せず。限界かなぁ…
どうも、アップデートでインストール時に入っていた WiFi のドライバが消えたみたい。macbookair の WiFi ドライバは、別途入れる必要があるみたいだな。
$ sudo aptitude install firmware-b43-installer bcmwl-kernel-source
ということで、無事 WiFi が復活。まだまだ、使い倒そう。
homebridge-gsh と cec-client
homebridge-gshで、google-homeからHomeKit(homebridge)を制御
自宅で homebridge-config-ui-x で、家電制御の設定が楽になり、homebridge-gsh にて、Google Home から Apple の HomeKit の制御を呼び出せるようにしてみた。今までは赤外線リモコンベースなので、テレビのON/OFFがトグル動作で怪しかったが、HomeKit 経由だと、TVにつなげた HDMI 接続のRaspberry-Pi から HDMI 接続の他の機器に、ON/OFF を明示的に制御ができるようになる。
cec-client で 電源ON/OFF ができなくなった
無事、homebridge-gsh が動き出したのに、CATVSTB の電源が ON/OFF できない。入力切替は正しく動いているのに…
cec-client の動作状況を表示させながらうごかすと、定番の 「echo “on 1” | cec-client -s」で動かない。メッセージを見ると、対象機器がうまく選べないのが原因みたい。
CEC では、物理機器番号と論理機器番号で管理されていて、物理機器番号が決まらないのに on はできない…といったのが原因みたい。cec-client のバージョンがあがり、その辺がいいかげんなコマンドが送れないようになったようだ。
しかたがないので、CEC-O-MATIC のページにて、他の方法を試すと、以下のコマンドなら、正しく電源のON/OFFができた。
$ echo "tx 26:36" | cec-client -s # チューナーをけす Recording2 → Tuner2 standby $ echo "tx 26:44:6C" | cec-client -s # Recording2 → Tuner2 User Control Pressed Power Off $ echo "tx 26:44:6D" | cec-client -s # Recording2 → Tuner2 User Control Pressed Power On
ということで、cec-client を呼び出す処理を、上記のコマンドを使うようにして、無事 google-home から HomeKit 呼び出しに成功。
google-home に、”NHK をつける” と話しかけると、homebridge-gsh 経由で homebridgeが呼び出され、「地デジ切替と1チャンネルの赤外線信号」をだすし、”チューナーを消す”と言えば、cec-client 経由でtx 26:44:6c を送ってチューナーの電源が切れる。超便利。
(追記)
“tx 2X:44:6D” による電源ONは、HDMIの電源連動機能が動かないみたい。”on Y” だと、(TVで連動ON設定が必要だけど)チューナーの電源を入れれば、TVも連動してONになっていた。しかし、”tx 2X:44:6D”ではテレビがつかない。TV側の連動機能を知らないうちにOFFにしたのかと思ったけど、リモコンでチューナーをつければテレビ付くし。
ということで、cec-client を使って電源操作するシェルスクリプトに、TVの電源ON動作を行う機能を追加しておいた。
homebridge-config-ui-x を入れる
Appleの家電制御のためのHomeKitと互換性のあるソフト homebridge だけど、以前より家電の赤外線リモコンで活用しているが、google home との連携もさせたくって、homebridge-gsh を入れようとしたが、nodejs のバージョンが古く、インストールに失敗していた。
Google Home Mini で家電を制御するために、iPhone に eRemote 用のアプリを入れて、制御もしているけど、テレビなどの電源ボタンがトグル動作で、ON/OFF を正しく認識しないので、操作性が悪い。homebridge では、テレビにつけた Raspberry-Pi から、cec-client を使って、電源操作や入力切替操作が行えるので、基本は homebridge ベースに切り替えたい。
インストール
今回、nodejs のリポジトリを nodejs の本家を使うように設定して、nodejs を最新の 12.x に上げる。合わせて、設定ユーザインタフェースが便利な、homebridge-config-ui-x を入れてみた。
# リポジトリを登録 $ curl -sL https://deb.nodesource.com/setup_12.x | sudo bash - $ sudo aptitude update ; sudo aptitude safe-upgrade # Node.js のインストール $ sudo aptitude install -y nodejs $ sudo npm install -g npm # homebridge-config-ui-x のインストール $ sudo npm install -g homebridge-config-ui-x
config-ui-x を使えば、config.json の編集機能があるし、その編集も各モジュール単位で編集もできるので便利。一部のモジュールは、config.json で触る必要があって、その切り分けで手間取った。
この Web-UI では、スイッチの操作で時間のかかる処理のコマンドで、一部動きがおかしいのもあるけど、スマホ版だと問題なく動くようなので、この画面はあくまで設定用かな。
IFTTT利用を最小限に
IFTTT が 有料のIFTTT Pro のサービスに移行となり、無料契約だとアプレットを3つまでしか使えない。早々に、IFTTT からの警告メールが届き、10/7 までに契約すれば月額費用は、自分で決められるといった内容。
自宅では、Raspberry-Pi で動かしている機能や、赤外線リモコンを Google Home から制御するために、IFTTT にかなり依存していた。最近は Netflix とか Hulu とか、色々と契約しているし、出費とならないようにIFTTT 依存から脱却を図ろう。
arpに169.254.x.xが出てくる
自宅サーバの状況を見ていたら、169.254.185.142 という IP アドレスが ARP の一覧に出てくる。
MACアドレスを見ると、設置している Raspberry-Pi と同じ。
リンクローカルアドレス
以前にも同様のエントリーが出てきたことがあったので、改めて原因をしらべると、こちらに該当すると思われる解説記事。
DHCPの異常で、アドレスが得られない時に、暫定で割り振るIPアドレスみたい。その他の原因も考えられると説明があるが、実際数日間に DHCP の設定を触っていたから、出てきてもしかたがないかな。
間違ったARPエントリを消す
“arp -d 169.254.x.x”で、エントリーを消そうと思うがうまく消えてくれない。深く考えてもキリがないので、夜中にサーバの再起動させよう。
うまく消えないので、色々調べながら、以下のコマンドで消せた。
“ip -4 neigh del 169.254.x.x lladdr yy:yy:yy:yy:yy:yy dev eth0″
サーバダウン
朝起きて、”OK, Google” と叫んでも、”WiFiが繋がっていない”とのエラー。確認すると、サーバが落ちている。サーバでDHCPも動かしているので、サーバが落ちると家の中のネットワークが全部動かなくなる。それらしい時間 2020/08/20,01:15 頃の syslog などを確認するが、心配な log もあるけど、通してみると定常的な spam 系のアクセスっぽいので、原因不明。
サーバもそれなりに長期間運用しているので、新たに /var/log/trouble というフォルダを作って、syslog, messages, access.log, error.log などをコピーしておく。