2023年11月10日

【スマートホーム】Switchbotボット(指ロボット)をリプレイス

こんにちは。

半年以上ぶりの更新となりました。
今回は、スマートホーム向けのさまざまなIoTデバイスを発売しているSwitchbot社の「ボット(指ロボット)」を置き換えた話題です。
通常の利用であれば、わざわざブログに書き起こすこともないくらい単純な置き換え作業です。
ですが私は指ロボットをシングルボードコンピュータ「Raspberry Pi」からコマンドを実行して利用しているため、少し躓くことになりました。



salastore_kk07b7nxv4r.jpg



■壊れ・・・てはいない → いや壊れた

置き換えに至った経緯は単純です。経年劣化です。
バッテリーは十分な電圧なのに、指ロボットの指の動きが極めて緩慢になってしまいました。
指の挙動はSwitchbot公式モバイルアプリである程度調整できるのですが、その設定もガン無視されます。
きっとモーターがもうダメなんでしょうね。 約4年ほどで寿命を迎えたようです。
2023/11/15追記:
ついに緩慢な動きさえ出来なくなり、モーターが悲鳴を上げるだけになりました。
分解してみると、モーターから伸びるシャフトを接続する指部品の穴が割れていました。
これではモーターのパワーが指部品に伝わるはずがありません。
強力な接着剤やパテで直したりすることも考えましたが、諦めて廃棄することにしました。


■新規購入そして置き換え・・・あれ?

ちょうどAmazonでSwitchbot社製品がセールとなっていましたが、メルカリで未使用品がもっと安く手に入りました。
先述のとおり私は指ロボットを公式アプリではなくRaspberry Piから実行する環境を構築しています。
指ロボットに対するコマンドラインのうち、Bluetooth MACアドレス部分だけを書き換えれば済む・・・そう思っていました。
ええ、エラーが出て動きません。え〜〜〜・・・・・


■MACアドレスだけじゃなかった

何しろ4年ぶり。当時Raspberry Piから実行できるようになるまでにどんな手順を踏んだかなんて覚えちゃいません。
いろいろ試行錯誤しているうちになんとか動かせるようになりました。
ポイントはコマンドパラメータに与えるハンドル値でした。
Raspberry Pi(Linux)からBluetoothで指ロボットに指示を出すコマンドは以下のとおりです。

# gatttool -i <hci#> -b <BLE MACアドレス> -t random --char-write-req -a <EndGrpハンドル> -n <動作モード>

今回躓いたのは、<EndGrpハンドル>の部分。
<BLE MACアドレス>だけでなく、<EndGrpハンドル>の値を変更する必要がありました。


■手順

いろいろ試行錯誤したのでもしかしたら以下の手順のうち必要ないものもあるかもしれません。
リセットして確認する気もないので、一応やったこと全部書いていきます。

 1. Raspberry Piに指ロボットを信頼させる。
 # sudo bluetoothctl
 [bluetooth]# connect <BLE MACアドレス>
 [bluetooth]# trust <BLE MACアドレス>
 [bluetooth]# exit
 # 
 2. EndGrpハンドル値を確認する。
 # gatttool -i <hci#> -b <BLE MACアドレス> -t random --primary
 attr handle = 0x0001, end grp handle = 0x0009 uuid: 00001800-0000-1000-8000-xxxxxxxxxxx
 attr handle = 0x000a, end grp handle = 0x000d uuid: 00001801-0000-1000-8000-xxxxxxxxxxx
 attr handle = 0x000e, end grp handle = 0x0013 uuid: cba20d00-224d-11e6-9fb8-xxxxxxxxxxx
 3. 上述の指ロボットに指示を出すコマンドの可変部分に適用する。
<hci#>
Raspberry Pi側のBluetoothモジュールの識別子です。私の環境では "hci0"と指定しています。

<BLE MACアドレス>
指ロボットのBluetooth MACアドレス。公式モバイルアプリに接続するとアプリから確認できます。

<EndGrpハンドル>
上述の手順で調べたハンドル値です。

<動作モード>
指ロボットの動作をコードで指定します。押す(570100), TurnON(570103), TurnOFF(570104) 

■最後に

劣化した旧指ロボットのファームウェアバージョンはv6.3、 新規購入した指ロボットはv6.6でした。
動かなくて困っているうちにこんな相違点を見つけてしまったものですから、もう従来のgatttoolコマンド自体が受け付けられない可能性を勝手に考えてしまい迷走してしまいました。
なにしろ最近のIoT業界はMatterという規格を標準化しようとしています。
きっと新しいファームウェアが当たっている指ロボットは、Matterのお作法に従ったコマンドしか受け付けないのだ・・・そう思い込んでしまいました。

そうではないということに気付いたのはコマンドのエラーメッセージに「Invalid handle」、ハンドル値が不正だよと表示されていたからです。
素直にハンドル値を探れば良かっただけでした。ちゃんとエラーメッセージ見ようぜ私よ。

余談ですが上記のような無駄な苦労することなく、MACアドレスを指定するだけで指ロボットを動かせるPythonスクリプトがネット上に出回っています。(っていうかSwitchbot公式です)
それを使ってもよかったのですが、旧指ロボット購入時に試してパフォーマンスが悪かったので今回も敬遠しました。







.


posted by Huwy at 14:58 | Comment(0) | TrackBack(0) | スマートホーム | このブログの読者になる | 更新情報をチェックする

2023年03月02日

【日記】熊野三山と伊勢神宮

こんにちは。

掲題記事をNotionで書きました。
posted by Huwy at 02:01 | Comment(1) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2022年08月18日

【日記】CPUグリス塗り直して右往左往した話し

こんにちは。

日記です。誰の役にも立ちません。

定期的に自宅PC内部のホコリ除去などを行っています。ついでにCPUグリスも塗り直しています。
今回もいつものようにヒートシンクを取り外したのですが、そのとき基盤に固定するためのスペーサが1つぽろりと外れてしまいました。
樹脂でガチガチに固定するスペーサでしたので簡単には直せません。

01.png

02.png


とりあえず自宅にあった接着剤を使ってみました。24時間後には強力に完全硬化すると謳っている接着剤です。
その間PCを使えませんが仕方ありません。スマホやタブレットでリモートワークをこなしつつ30時間放置しました。

03.png

いざヒートシンクを取り付けて起動してみたのですが・・・・CPU温度もアチアチ、ファンも常時フル回転状態。
CPUの熱がヒートシンクにまったく伝わっていないようです。あかん・・・。

その原因を探ってみると、やはり件のスペーサが問題のようです。
スペーサにネジ止めすることでヒートシンクをCPUに押し付けなくてはなりませんが、問題のスペーサがネジ止め圧に負けて軽く浮いてしまっています。
そのせいでヒートシンクとCPUヒートスプレッダの間に僅かに隙間が出来ていました。これじゃ冷えるわけないですね。
空気の断熱効果恐るべし。

04.png


問題のスペーサは事実上もう役に立ちません。さてどうしたものか。
私の使っているPCは手のひらに乗るほどコンパクトなNUCで、ケースとヒートシンクの距離が非常に近い点に注目してみました。
(エアフローはそもそも無いに等しいのでファンとヒートシンクが命綱です)
ケースの内側の面でヒートシンクをCPUに押し付けてしまえばいいのでは?

接着剤同様にたまたま自宅にコルク製のクッションシールがありました。
1枚の厚さが1mm程度でしたのでこれを数枚重ねてケースとヒートシンクの間に挟みこみました。
1mm単位では隙間の精度に合わず若干難儀しましたが力技で対処。ケースもやや無理矢理閉じていざ再起動。

05.png


おおお!・・・嘘のように静かになりました。
クッションシールのせいで基盤に無理な力が加わっているため、実はCPUファンに影響が出て回ってないんじゃないか?とさえ思うほどに静かです。
念のためCPU温度とファン回転数をモニタするソフトウェアで両者とも安定していることを確認しました。
ブラウザでYahoo!ニュースを開いただけでドライヤーのごとく唸っていたファンでしたが、今はホロホロと穏やかに回転しています。

小さなスペーサ1つのためにPCを新調しようかとまで考えてしまいました。
載せてるCPUももう5世代前の古いものでWindows11の要件を満たせていないし!などと新調する理由を無理矢理捻り出したりもしました。
しかしこうして動作が安定すると逆に愛着が深くなってきてしまいました。
もう少し一緒にWindows10で頑張ろうね!


2025/04/21追記:

約3年前に書いたこの記事。
さすがに3年も経ちますと状況はすっかり変わっています。
まず、上述のスペーサが外れてしまった問題はエポキシ系樹脂接着剤を使うことで解決。
2つの薬剤を混合するタイプの接着剤とか初めて使いましたが、効果バツグンですね。

さらにミニPCを新調しました。Win11Pro搭載でそこそこスペックの高いものです。
というわけで、当記事で挙げている古いPCは現在メルカリで出品中です。
なにか用途はないかと考えたのですが、特に思いつきませんでした。





.

posted by Huwy at 12:14 | Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2022年08月14日

【スマートホーム】SSL証明書更新処理の自動サイクル

こんにちは。

先日似たような記事を書きました。そちらはSSL証明書更新処理結果のメール通知についてです。
今回は更新処理のサイクルについて書きます。



■Let's Encryptクライアント「Lego」の罠

SSL証明書はLet's Encryptの無料のものを利用しています。
Let's Encrypt公式のクライアントもあるのですがどうも評判がよろしくないようで、安定してると評価の高いLegoを利用しています。

Let's Encryptの証明書は90日で期限切れとなることは前回記事にも書きました。
じゃあ毎日更新しとけば安心じゃんと考えがちになってしまいますが、あまりに頻繁にリクエストすると認証局からブロックされてしまうそうです。
認証局として負荷を抑えるという目的でしょうかね。Legoもそうした方針を尊重しているようで、デフォルトでは有効期限が残り30日にならないと認証局に更新リクエストを送信しない仕様となっているようです。

実はこれに素直に従うとけっこうややこしいことになります。
月ごとに日数が異なったり2月は短かったり閏年があったり・・・ということをしっかり考慮して更新処理をスケジュールしておかないと、更新可能な30日間を取りこぼして期限切れになる可能性があります(後述)。



■定期実行のスケジュールにはcrontabを使う

crontabは指定した「月日時分秒」のパターンで同じ処理を繰り返し実行するようスケジュールできます。
SSL証明書の定期更新というタスクにはまさにうってつけで、ネット上の多くの例でも取り上げられています。
しかし「月日時分秒」でしか指定できないという点がネックとなり、更新可能30日間をすっぽりとスキップしてしまう危険も含んでいます。
例:毎月01日に更新処理をスケジュール
・01月31日が有効期限=更新可能な30日間は01月02日から開始
・01月01日に実行→更新可能期間前なので更新スキップ
・02月01日に実行→有効期限切れ

◇月2回実行
毎月2回実行していれば更新可能な30日間を取りこぼすことは無いでしょう。
しかし実際に更新できるまで少なくとも60日間あるのに2週間足らずのインターバルで無駄撃ちを重ねるのもカッコ悪いなあと思ったり。
更新処理は大した負荷ではないので気にすることはないんでしょうけど、こういうとこ気にしちゃう性格なんとかしたい。

◇その他の方法@
crontabでも工夫すれば「月日時分秒」ではなく「30日ごと」等で更新処理を動かすことも可能だそうです。
crontabのスケジュール自体は「毎日1回」としておき「当日が基準日からの経過日数30日ごとにあたる」場合にのみ更新処理を実行するという条件付けをする方法です。
しかし月2回実行以上に無駄撃ちしまくりですし、crontabの書き方もトリッキーになります。
パッと見て何やってるのか理解しにくいのが難点です。

◇その他の方法A
crontab以外にもタスクをスケジュールできるコマンドがあります。atコマンドです。
しかしatコマンドは「POSIX準拠」なる仕様だそうで、bashを標準シェルとしている多くのLinuxディストリビューションでは扱いにくいとのこと。
Raspberry Pi OSも例に漏れず、atコマンドからbashで書いたスクリプトを実行できない可能性が高いです。
そもそもRaspberry Pi OSにはatコマンドが含まれておらずインストールする必要があります。
また、atコマンド→shを呼び出し→bashを呼び出しという手間が発生し、やはり後々のメンテナンスが面倒なことになりそうです。



■Legoの理解不足だった

先程「デフォルトでは有効期限が残り30日にならないと認証局に更新リクエストを送信しない仕様」と書きました。
そうです、あくまでデフォルトではそういう仕様だというだけでオプションで変更することが出来ます。
勉強不足でこの点を見落としていました。むしろ30日制限は認証局側の制約だと勝手に誤解していました。

「--days xx」とオプション指定すれば残りxx日であれば更新を認証局にリクエストします。
なので、crontabで2ヶ月毎の01日にスケジュールして更新処理で--days 90とオプション指定しておけば、約60日ごとに証明書が更新されるサイクルが組めます。

crontab:隔月01日の03時15分に更新処理を実行する例
15 3 1 */2 * /etc/renew_ssl.sh

/etc/renew_ssl.sh:有効期限の残日数に関わらず強制的に証明書更新する例
いろいろ準備
lego xxxxxxxxx renew --days 90
いろいろ後処理


■まとめ

Legoの利用例はネット上にたくさん情報があるのですが「更新は月1回やっとけばいいっしょ」という論調が多い気がします。
しかしそこに上述のような罠が潜んでいる点まで言及している情報はありませんでした。
まあ私が読み取れていなかっただけって話しですけど・・・。
「30日制限は認証局側の制約」ってどこで誤解したんだろ・・・(´・ω・`)







.
posted by Huwy at 08:12 | Comment(0) | TrackBack(0) | スマートホーム | このブログの読者になる | 更新情報をチェックする

2022年07月30日

【オンラインストレージ】Amazon Drive終了予告

スクリーンショット 2022-07-30 155139.png

こんにちは。

微妙にショッキングなニュースが飛び込んできました。
Amazon Driveがサービス終了だそうです。


要約
  • 2023年01月31日に新規アップロードの受け付けを停止。
  • 2023年12月31日に既存コンテンツの参照が不可能に。
  • Amazon Photoには影響なし。
  • Amazon Photoに注力するための施策。

2021年06月のGoogleフォト容量無制限終了以降、私は無制限の写真ストレージとしてAmazon Photoを使ってきました。
今回のAmazon DriveシャットダウンはAmazon Photoには影響しないということで、ひとまず胸を撫で下ろしているとことです。

最近のオンライン画像管理ストレージは日付や被写体検出で勝手に整理してしまうものが多いです。
Amazon Photoも例に漏れないのですが、PhotoはDriveのサブセットという位置づけでしたので実体であるDriveで思い通りのフォルダ管理をしていました。シャットダウン後にはおそらくそうした管理が出来なくなると思われます。面倒なことになりそうで憂鬱・・・。







.



posted by Huwy at 16:09 | Comment(0) | TrackBack(0) | オンラインストレージ | このブログの読者になる | 更新情報をチェックする