2024年07月21日

【スマートホーム】Node-REDのバージョンアップでちょっと問題発生した話

こんにちは。

AmazonEchoとNode-REDをブリッジしてくれる「Node-RED Alexa Home Skill Bridge」というAlexaスキルがあります。
AmazonEchoから制御をNode-REDに渡すことで、自由自在にプログラムできるようになります。
私はこれを利用してAmzonEchoからの家電操作にひと工夫加えていました。

さて、Node-REDの新しいバージョンがリリースされました(v4.0.2)。
Raspberry PiにインストールしていたNode-REDをバージョンアップさせてみたら・・・
「Node-RED Alexa Home Skill Bridge」のサーバに繋がらなくなってしまいました(T_T)
接続を試みているようですが、ずっと下画像のまんまです。

スクリーンショット 2024-07-21 191025.png

難しいことは分かりませんが、Node-REDのバージョンアップに伴いNode.jsのバージョンも20 LTSに上げたのが原因のようです。
Node.jsのバージョンを18にダウングレードしたら無事に接続できました。

「Node-RED Alexa Home Skill Bridge」は有志による野良Alexaスキルであり、野良Node-REDノードです。
ローンチはもう8年前であり4年前を最後に更新もされていませんが、Node.js20に対応できていないからといって開発者の方に文句を言うわけにもいきません。
現在でもサーバを稼働させ続けてくれてるわけですし、むしろこれまでこのスキルのお陰でスマートライフを満喫できたことを感謝すべきでしょう。
もし将来のNode-REDがNode.js18を足切りするようなことがあればこのスキルはもう使えないということになりそうです。

ソースはGitHubで公開されているので、いっちょNode.js20対応やってみる???
すいません言ってみただけです。







.




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

2024年06月17日

【Windows一般】ネットワークアダプタがWOLを受け付けない → 解決!

こんにちは。

8年落ちでCPUがintel Core i5 第7世代というとても古いPCを、無理矢理Windows11にアップグレードしてみました。
すると、アップグレードのせいかネットワークアダプタのプロパティからWOLに関する項目が消えてしまいました。
もちろんWindows10のときには項目が表示されていましたし、WOLもちゃんと機能していました。

項目が消えたのは「詳細設定」タブのリストです。
「電源の管理」タブのMagic Packet云々の設定は表示され、チェックも入っていました。
「電源の管理」タブのほうで設定できているなら大丈夫かな〜という期待は見事に裏切られ、WOLが機能しません。
再起動などしても状況は変わりませんでした。

まずはネットワークアダプタのドライバの更新を試してみますが、
「このデバイスには最適なドライバーが既にインストールされています」
の一点張りで解決に至りません。

次にBIOS設定の再確認。
うん、ちゃんとWOL出来るように設定されています。

困ったときのGoogle先生頼み。
以下のページに網羅的に対処方法が紹介されていました。
Win10の内容ですがWin11にも適用できそうです。
載っている内容は全部試してみましたが、残念ながら解決せず。

諸設定の確認・変更もドライバー更新も効果が無いとなるとどうしたものか・・・。
ネットワークアダプタは以下の型番です。
Intel Ethernet Connection I219v
そのままググってみると、Intel公式サイトのダウンロードサイトが見つかりました。
そしてドライバーパックのバージョンや日付を見ると・・・なんか新しいバージョン出てるじゃない!
Windowsからのドライバー更新って、必ずしも最新のものを見つけてきてくれるわけじゃないんですね。

さっそくダウンロードして展開し、ドライバー検索先に指定して更新。
見事にWOL関連項目が復活しました。
しかも日本語化されてるぅ。

スクリーンショット_2024-06-17_180246-removebg-preview.png

もちろんこれで、WOLがちゃんと機能しました。
振り返ってみれば「ドライバーを最新化した」ってだけの話なんですが、Windowsに任せっきりにすると解決しない場合もあるというオチでした。







 .
posted by Huwy at 18:17 | Comment(0) | TrackBack(0) | Windows一般 | このブログの読者になる | 更新情報をチェックする

【ガジェット】パソコン買い替えました(Beelink SER8)

こんにちは。

8年ぶりにパソコンを新調しました。
すっかりミニPCのサイズ感が気に入って、3台目となります。
Beelink社のSER8というモデルです。

1._2f322cd5-c7ef-4305-836b-f139e72c12bd_1500x.jpg

これまでの2台はいずれも台湾メーカーASRock社製でしたが、この8年の間にミニPC市場はすっかり中国メーカーが席巻しています。
今回購入したミニPCもそんな中国メーカーの1つBeelink社製です。
また、今回人生で初めてのRyzen搭載PCとなります。

詳しいスペックについては公式ページやレビュー情報をご確認ください。
ゲームも動画編集もしない私のユースケースではハッキリ言ってオーバースペックな高機能モデルですが、永く使えそうな予感がしています。
懸念材料としてはやはり大手以外の中国メーカー製という点ですが、怪しげなメーカーもある中、Beelink社は比較的まともな印象があります。
プリインストールのWindows11ProもボリュームライセンスではなくちゃんとOEMライセンスでしたし、怪しげなソフトウェアも入っていませんでした。
Huaweiみたいにハードウェアに変なもの仕込んでる可能性は拭いきれませんが・・・。

中国メーカーのミニPC市場攻勢は激しく、実にたくさんのモデルが出回っています。
そんな中から私がこのモデルを選んだ最大の理由は静音性でした。
ネット上のレビュー記事・動画をいくつか拝見してみても、静音性についてはどなたも高評価を付けていました。
さらにこのモデルはダストプルーフフィルターというものが内部へのホコリの侵入を防いでくれるんだとか。
ミニPCにしてはCPUファンも大きめですしホコリも侵入しづらいのであれば、あまりメンテナンスせずとも静音性を維持してくれそうです。
実際、ほんとに動いてんの?ってくらい静かです。

これで私も約2年半遅れでWindows11デビューです。



ちなみに2台目
Beebox-S Series (Kaby Lake)(L1).png

ちなみに1台目
Core 100HT(L1).jpg






.


posted by Huwy at 15:17 | Comment(0) | TrackBack(0) | ガジェット | このブログの読者になる | 更新情報をチェックする

2024年05月05日

[日記]スマホ画面の修理(Google Pixel 7a)

こんにちは。

1年ほど前にiPhoneX→Pixel7aに乗り換えました。
1年間の保障期間がそろそろ切れるGW直前、やっちまいました。
人生初のスマホ画面クラッシュです。
2009年06月のiPhone3GS購入から始まったスマホ歴15年で初めてのことで、大変ショックを受けています。

   Viber_画像_2024-05-02_13-26-32-631.jpg

幸いiPhoneXは自宅で遊ぶために取り置いてあったので、SIMカードの差し替えで日常生活に支障はありません。
しかし一度見限ったiPhoneXをまた数年間使い続ける気になれず、Pixel7aを修理に出すことにしました。

なにしろ保障期間も迫っていたのでクラッシュ当日中にはGoogleStoreから修理申請。
まずは修理工場に送るための配送キットを自宅に送ってもらいます。
修理工場到着後は、検査→最終的な費用の決定→修理→返送という手順になります。
私の感覚では手元に戻るまで2週間はかかるだろうと思っていました。

しかし実際は以下のとおり。
Googleの修理工程めっちゃ優秀やん。
この記事を書いているのが4日目です。おそらく明日には手元に届くでしょう。

■1日目:
 ・クラッシュ当日。
 ・GoogleStoreで修正申請。

■2日目:
 ・配送キットが自宅に届く。
 ・必要な書類を同梱してコンビニから発送。

■3日目:
 ・Googleから到着したよと連絡あり。
 ・検査の結果、修理費用はこれくらい。承認してと連絡あり。
 ・→即承認。ちなみに3万円・・・😱

■4日目:
 ・修理終わって返送したよと連絡あり。

もちろん破損状況や居住地域によっては、必要な日数も大きく変動するでしょう。

さて、先述のとおり私は15年間でスマホ画面を割った経験がありませんでした。
もちろん15年の間には手を滑らせ床に落下させたことが数え切れないほどあります。
「スマホ画面はけっこう頑丈、割っちゃうなんてよっぽど手荒い使い方してたんでしょ」
そんなふうに考えていた時期が、私にもありました。

しかし今回のことでその考えを改める必要が出てきてしまいました。
なにしろ普通にポケットからポロッと路上に落としただけだったのに・・・。
今後はスマホを扱いに神経質になりそうです。

追記:
■5日目:
 ・予想通り手元に戻ってきました。修理工場って静岡県にあるんですね。

   写真 2024-05-06 12 46 31.jpg

   写真 2024-05-06 18 13 19.jpg





.



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

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) | スマートホーム | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。