CrowdSec - オンラインからブロックリストをフェッチできるFail2Banの代替OSS
LinuxでDDoSなんかをログからいい感じにブロックするソフトウェアといったらFail2Ban。
IPをアクセス回数と間隔で監視してアウトな子はiptablesでブロックというシンプルかつ強力なソフトです。
そんなF2Bを代替するOSS「CrowdSec」は、F2B的な機能に加えて、CrowdSecコミュニティが提供するブロックリストも利用できるみたいです。
インストール方法
・テスト環境：Ubuntu 20.04 LTS
下記のコマンド群を実行すればOK。
sudo apt install bash gettext whiptail curl wget curl -s https://api.github.com/repos/crowdsecurity/crowdsec/releases/latest | grep browser_download_url| cut -d '"' -f 4 | wget -i - tar xvzf crowdsec-release.tgz cd crowdsec-v* sudo ./wizard.sh -i
なにやらサービスを選択する画面が出てくる。デフォのLinuxログやらsshdやらnginxやら、インストールされているサービスを勝手に認識してここにリストアップしてくれるので、ログを監視したいサービスを選択する。
apacheとかmysqlとかvsftpdとかも対応している。なかなか優秀。
インストールを進めていると「CrowdSec単体ではIPをブロックできひんで、ブロッカーがいるで」という忠告が。
ブロッカーは以下のページで公開。通常のNetfilterのほか、Cloudflareやnginx、WordPressと連携してブロックできるみたい。
「cs-netfilter-blocker」でNetfilterを使ったブロックができる。インストールは以下コマンド。
wget https://github.com/crowdsecurity/cs-netfilter-blocker/releases/download/v0.1.0/cs-netfilter-blocker.tgz tar xzvf cs-netfilter-blocker.tgz cd cs-netfilter-blocker-v0.1.0 sudo ./install.sh sudo systemctl status netfilter-blocker
これでCrowdSec経由でNetfilterを利用できるようになったみたい。
使い方
cscliというコマンドが用意されており、cscli listで有効化されている設定を確認可能。
sudo ipset listすると、勝手にブロック対象のIPがリストに追加されているのがわかる。これはCrowdSec Hubというコミュニティからオンラインで取ってきたものみたい。逆にこちらのブロック情報もコミュニティに送信される。
iptablesのINPUTチェインにも勝手にルールが追加されている。うーん楽ちん。
基本的な使い方は以下。
・cscli ban add/del IPアドレス：IPをブロック/ブロック解除
・cscli ban flush：ブロック設定をDBに書き込み
・cscli install collection：監視対象のサービスを新規設定
・cscli update：CrowdSec Hub(これがCrowdSecのコミュニティ)から最新のブロック情報を取ってくる
なんとCrowdSecは6060ポートからPrometheusのメトリクスを出力してくれる。つよい。cscli metricsでメトリクス情報をまとめて表示してくれる。
Dockerをインストールした状態でcscli dashboard setupすると、CrowdSecのダッシュボードを設定できる。
テストで使っただけなのでブロック情報がたまらなかったため、公式から画像を拝借。こんな感じでmetabaseを使ってブロック情報を可視化してくれる。
ブロックしているIP一覧なんかもダッシュボードで確認できる。こいつぁすげえや。
感想
個人で使うなら全然F2Bから乗り換えですね。仕事で使う場合はブロック情報をコミュニティに送信するというのがネックか。
まあこういうのが必要なオンプレ環境を持っている人がどれくらいいるかという話なんですが…
P.S.
エントリ書いてる最中にグロージャンが大クラッシュしてビビりました。
LinuxのブラウザでYouTube 4K60fpsをヌルヌルで再生したい人生だった
「みんなやってそうだけど意外と情報がなかった」シリーズ、始まりました。
記念すべき第一回は「YouTubeの4K60fpsムービーをLinux＆ブラウザで視聴する」です。
意外と情報がなかったので、戦いの模様を書いておきます。
そろそろグラボ買い替えよか
Radeon RX480 限界に到達
YouTubeの4K60fpsは「VP9」コーデックなんですが、こいつのデコードに我が家のおじさんグラボ(Radeon RX480)は対応していないとのこと。
腐っても3年前のミドルハイなんですから、VP9くらいサクッと読み解いていただきたいものなんですが・・・
ちなみに同世代のGeforceはVP9デコードに対応しており、RadeonがVP9デコードにきちんと対応したのはRX5000シリーズから。
AMDさん、あんまり動画やる気ないんですかね(Fluid Motion廃止とか)。
日本橋になんか怪しいやつが売ってた
「最近シロッコファンのGTX1660Tiがパソコン工房に蔓延している」という情報を聞きつけ、日本橋に赴くとこんなものを拾うことができました。
完全にノーブランドの謎グラボ。例のグラボとは違って映像出力はきちんとついています。
私が使っているJonsbo RM2はけっこう小さいケースなんで、外排気のシロッコファンはありがたい。何回かベンチ回しましたが、とりあえず無事動いてるみたいです。
こんな感じでめちゃくちゃ溢れてました。15000円台で10日保証は買いですね。
GTX1660TI15980円とGTX16660 13980円 pic.twitter.com/EcIgD2wYRD
— 白銀のレガ (@megutasorin) 2020年11月21日
LinuxでVP9は一筋縄ではいかないみたい
我が家のCPUはおじいさんHaswell(Core i5 4570)なので、4K60fpsのVP9をCPUだけで再生するのは無理。
というわけでグラボに再生支援していただきたいのですが、これがどうも一筋縄ではいかないようで。
LinuxとNvidiaとVP9を取り巻く現状
以下、適当まとめ。
・Geforce GTX1660TiはVP9デコードに対応している
・NvidiaのLinux向けプロプライエタリドライバもVDPAUによるVP9デコードに対応している
・LinuxではChromiumのbeta/dev版とFirefoxでVAAPIによる再生支援を利用できる
・VAAPIのバックエンドにVDPAUを使える「vdpau-va-driver」というものが存在する
ここまで聞くとブラウザでもVP9を再生支援できそうなのですが、vdpau-va-driverがVP9に非対応。
あぁ〜夢敗れる・・・と思いきや、捨てる神あれば拾う神ありとはよく言ったもの。
vdpau-va-driver-vp9
なんと有志によってvdpau-va-driverにVP9デコード対応パッチを当てた「vdpau-va-driver-vp9」というものが公開されていました。
これを使うとVAAPIのバックエンドにVDPAUを使ってVP9を再生支援できる！！
というわけでセットアップやっていきましょう。
vdpau-va-driver-vp9セットアップ
まずは依存パッケージをインストール。ビルド時のエラーを見つつ調整していったので、もしかしたら無駄なパッケージがあるかもしれません。
sudo apt install \ git \ build-essential \ automake \ autoconf \ libtool \ pkg-config \ meson \ libx11-dev \ xtrans-dev \ x11proto-dri2-dev \ x11proto-dev \ libxext-dev \ x11proto-xext-dev \ libx11-xcb-dev \ doxygen \ dot2tex \ libva-dev
続いてVP9パッチ済みのVDPAUライブラリ(libvdpau)をビルド＆インストール。
git clone https://gitlab.freedesktop.org/vdpau/libvdpau.git cd libvdpau meson --prefix=/usr build ninja -C build sudo ninja -C build install
今回のチャレンジの核となるvdpau-va-driver-vp9 をビルド＆インストールします。インストールしたあとは念のため再起動。
git clone https://github.com/xtknight/vdpau-va-driver-vp9.git cd vdpau-va-driver-vp9 ./autogen.sh --prefix=/usr make sudo make install
Firefoxを使いたい場合はそのままでOK、Chromiumを使いたい場合はbeta/dev版をインストール。
sudo add-apt-repository ppa:saiarcot895/chromium-dev sudo apt update sudo apt install chromium-browser
Chromiumの場合はchrome://flagsで「Hardware-accelerated video decode」を有効に。
これで万事OKのはず！だったんですが・・・
結果
無念の敗北
嬉々としてYouTubeの4K60fps動画を再生してみると・・・カクカクなんですが。
vainfoを見るとnvidia_drv_video.soを読み込んでいるし、VAProfileVP9Profile0も認識している。
何よりCPUが張り付いてしまっている。
SMPlayerでハードウェアデコードに「VAAPI」を設定すると、きちんとSMPlayerバックエンドのmpvがGPUのメモリを使う。動画自体もヌルヌルで再生できる。ハードウェアデコードに「VDPAU」を設定した場合も同じ。
たぶん原因は「LinuxのブラウザでVAAPIの再生支援が使えなくなっている」
状況から見て、おそらくブラウザでVAAPIの再生支援が効かなくなってしまっていますね。なぜか。
これが直ればたぶん「LinuxでブラウザからYouTubeの4K60fpsをグラボの支援を使ってヌルヌルで再生する」という夢を叶えることができると思うのですが、今回は力及ばずここまで・・・
SMPlayerを使えば「LinuxでYouTubeの4K60fpsをグラボの支援を使ってヌルヌルで再生する」ことは可能なので、しらばくこれで我慢します。
ブラウザのVAAPI再生支援はバグで死んでいるのか、こちらの不手際なのか、ちょっとわからないので追加で調査していきます。
YouTuber・瀬戸弘司の4K60fps実況をコメントと一緒に再生できる日は来るのか・・・
P.S.
RX480のリファレンス(左)と今回のGTX1660Ti(右)のサイズ比較。基板だけならGTX1660Tiのほうが短いのにケース含めるとRX480のほうが短くなるという。
というわけでRX480さん、3年間お疲れ様でした。
AWS ソリューションアーキテクトアソシエイト(AWS SAA)を一週間で取得した
AWSを実際に触ることはあまりないのですが、AWS SAAを取得しました。
仕事柄、知識としてAWSを頭に入れておくのはいいことだと思いましたので。
今回は資格取得を目的としているため、ハンズオンなどを行わない最短ルートを突っ走り。
初期スペック
使ったもの
黒本
LPIC受験時にお世話になった黒本。
これだけで受かることはまずありませんが、AWSにどんなサービスがあるのかを素早くざっくり把握するにはいい本です。
Udemy
これ。実戦形式の問題が6セット入っています。
難易度としては本番より少し難しいといったところ。 この問題セットを解きつつわからなかった問題を復習するというかたちで学習を進めていきます。
スケジュール
AWS SAAに一週間で合格するスケジュールをば。
日曜日
日曜日はさっと黒本に目を通します。
ElastiCache、DynamoDB、SQSなどなど、サービスの概要を把握していきます。
月曜日〜土曜日朝
Udemyの問題集を一日1セットこなします。
問題を解く→復習という流れ。
問題を解くのに1時間、復習に1時間半ほどかけていました。
問題集の消化フェーズでサービスとサービスの鉄板構成やオンプレ構成をAWSで再構築する場合のサービスの組み合わせなどを頭に入れていきます。
土曜日午後
テストセンターでいざ受験。身分証は2種類(ex 免許証&保険証)必要なのでお忘れなく。
試験時間は140分で、自分はめいっぱいまで使い切りました。
アンケートに答えた後、「合格」という文字が見えればクリアです。
日曜日
あそびましょう。
完走した感想
思ったよりも本番試験が難しくて焦りました。
Udemyの模擬試験が細かいサービス(ex AWS Lex)までカバーしているのに対し、本番試験はRDSやS3などの基本的なサービスの理解が深く問われたという印象です。
単語の暗記では合格できませんね…
ちなみにスコアはこんな感じでした。
「AWSなんもわからんけどとりあえずどんなもんか知りたい」なら、AWS クラウドプラクティショナーを先に取得するのがおすすめ。
自分は金が惜しいので飛び級でSAAを取得しました。
なにはともあれ、ハンズオンを伴っていないので現場でAWSをゴリゴリ触っていく場合は非推奨な取得ルートです。
P.S.
金欠にもかかわらず、iPhone 12 miniを買ってしまった…
このサイズ感、本当にちょうどよくて優勝です。
ユーノスロードスターにアジアンタイヤ「NANKANG NS-2」を履かせました
レッドブルホンダ、調子悪いですね…PUトラブル2連発は、よろしくない。
ロードスターが履いていたタイヤがカチコチ石頭の坊主頭だったので、これを機にアジアンタイヤを履かせてみました。
もうタイヤは限界でした
中古でロードスターを購入した当初から履かされていたのが「DUNLOP DIREZZA DZ102 205/50R15」。
車を購入した2年前はそこそこ残っていた山も、今となっては(ほぼ)つるつる坊主。
ひび割れもひどく、かなりゴムの硬化が進んでいます。
アジアンタイヤ、使ってみよう
NANKANG Sportnex NS-2 205/50R15
というわけで新しいタイヤを選定。金欠だったのでネットで評判のいいアジアンタイヤ「NANKANG NS-2」を楽天市場のオートスポーツで購入しました。
トレッドパターンはスポーティ。ゴムも弾力あります。
走ってみた感想
グリップ
とりあえず乾いた路面ではグリップは申し分ない。
ただ、バンクがかかった道路に進入すると、トレッドの剛性が足りないので「クニャ」という感覚が伝わってきます。
雨の日はまだ走れていないので、またいずれ。
ノイズ
ロードスター自体がノイズの塊なのであまり気になりませんが、よく耳をすませると「ザー」という音が聞こえます。
静粛性の高い車だとおそらく気になると思います。
柔らかさ
前回のタイヤが完全に硬化していたので、感触はかなりソフトになりました。
そのせいかリアがばたつくようになったので、ダンパーの減衰力を調整する必要がありそう。
まとめ
1本6000円台で送料無料のタイヤとしてはコスパがよすぎますね。
タイヤの真価は限界時の制動性にも左右されますが、そのへんはテストできてないので判断できません。
そこそこ長持ちするようなら、リピ確定です。
P.S.
タイヤ交換時にまさかの事態が発覚。
なんと、ホイールナットの何本かに、テーパー型ではなくホンダ純正の球面型が使われていました…
中古で車両を買ってからタイヤを取り外したことがなかったので、丸2年ほど気づかず走行していたということになります。恐ろしすぎる。
すぐさまテーパーのホイールナットに交換しました…
あやうくオーストリアGPのキミになるところでした。
ユーノスロードスターのステアリングがキシキシ鳴るのでステアリングボスを交換
F1が始まって歓喜しているいぶろぐです。 レッドブルホンダ、苦戦しておりますね・・・
夏場になると、うちのロードスターのステアリングが「キシキシ、キシキシ」と鳴り始めるので、ステアリングボスを交換してみました。
暑くなると鳴り始める
ロードスターに乗り始めて今年で2年目ですが、夏になるとステアリングを切ったときに「キシキシ」っていう音が鳴るんですよね。
夏に限らず車内の温度が上がると鳴り始め、エアコンで温度が下がると収まります。
引っかかる感覚があったのでステアリングボスのなんらかが膨張しているのかな、と思い、ステアリングボスを交換することに。
ステアリングボス選定
HKBかなあ
これを機に跳ね上げ式のステアリングボスに交換しようかなと思いましたが、お値段を見て尻込み。
ステアリングコラムの交換も必要になりそうだったので、安心と信頼のHKB製を選ぶことにしました。
自分のロードスターに適合するボスはどれ？
ユーノスロードスターはステアリングボスの形状が複数あるらしく、自分が乗っているNA8C Sr 1.5 VスペシャルはOR-18が適合するみたい。
MOMO純正ステアリングがついているモデルはOR-119が適合する模様。
(最初間違ってOR-119を買ってしまいました・・・装着できそうではありますが、ステアリングは大切な部分なのでOR-18を買い直しました)
交換作業
最初にバッテリーのマイナス端子を外しておきます。これをやらないとホーンが意図せず鳴ってしまうので要注意。
バッテリーを外したらホーンボタンを取り外します。するとステアリングボスを固定するためのナットが出現。
ナットは非常に強く固定されているので、左手でステアリングを固定しながら頑張ってナットを外します。
ナットを少し緩めた状態で、ステアリングごと上下にガタガタ揺らすとボスが外れます。
新旧ボスを比較するとこんな感じ。特に劣化は見られませんが・・・交換して音が収まってくれるとうれしいところ。
グリスを塗り塗りしてステアリングボスにステアリングを固定し、ナットでボスを固定します。固定にはトルクスレンチを用いて適切なトルクで締めておきます。
交換してみて
試運転した感想は・・・
でした。
間違いなく古いボスが劣化してなんか引っかかってましたね。すいすいステアリング切れるようになりました。
もちろんキシキシ音も解消。ボスの値段が2000円くらいだったので、もっと早くやっておけばよかったなあ。
P.S.
今年は車検。ステアリングラックブーツは破れていて交換確定なので、早めに作業するなりお店にお願いするなりしなければ。
Ubuntu 20.04でsystemd-bootを試してみたら、けっこういい感じだった
最近姿勢を正そうと頑張っているいぶろぐです。
Linuxのsystemdに「systemd-boot」という軽量ブートローダーが組み込まれているということを知ったので、Ubuntu 20.04でちょっと試してみました。
systemd-boot
Arch Wikiによると・・・
前は「gummiboot」という名前だったらしい。
Arch Wikiが詳しいです。
適当にまとめると、以下のような感じらしいです。
・systemdが入っていれば導入可能
・起動が速い
・セキュアブート対応
ラップトップのブートローダーなんて速ければOKと思っているので、早速入れてみることに。
導入方法
ブートローダーインストール
以下、Ubuntu 20.04環境でやってます。とりえあず下記コマンドでブートローダーをESPにインストール。boot領域をいじるので、rootユーザーで作業したほうが楽です。
bootctl install
エントリーファイル「/boot/efi/loader/entries/ubuntu.conf」を作成します。GRUBでは「grub.cfg」にすべてのエントリー情報が記述されていますが、systemd-bootでは「entries」ディレクトリの下にエントリーごとにファイルを作成するようです。
エントリーファイルの中身はこんな感じ。
title Ubuntu linux /vmlinuz initrd /initrd.img options root=UUID=blkidで調べたUUID quiet splash rw #追記：btrfsをrootディレクトリに使っている場合は「rootflags=subvol=@」が必要でした
OSが入ったディスクのUUIDはblkidなどのコマンドで調べてください。なお、カーネルイメージやinitrdのパスはESPのrootから相対パスで記述します。Ubuntuはデフォルトでは「/boot/efi」にESPをマウントするので、上の設定は「/boot/efi」直下にカーネルイメージを配置する場合の記述になります。
ついでにこんな感じで前バージョンのカーネル用エントリーファイル「ubuntu-old.conf」も記述しておくことに。
title Ubuntu-old linux /vmlinuz.old initrd /initrd.img.old options root=UUID=blkidで調べたUUID rw
続いて「/boot/efi/loader/loader.conf」を下記のように編集。defaultにはデフォルトで起動したいOSのエントリーファイル名を拡張子なしで指定します。カーネルパラメータに「init=/bin/bash」などと指定されないよう、editorの項目でカーネルパラメータの編集を無効にしておきます。ブートメニューは非表示にしたいのでtimeoutの項目はコメントアウト。
#timeout 3 default ubuntu editor no
ここまででブートローダーの設定は完了です。
カーネル関連をごにょごにょ
Ubuntuはデフォルトだと、
・「/boot/efi」にESPをマウント
・「/boot」にカーネルイメージやinitrdを配置
となっているのですが、systemd-bootはESPからしかカーネルをロードできません。「/boot」にあるカーネルイメージはロードできないので、「/boot/efi」にコピーしてあげる必要があります。
というわけでコピーします。「/boot」以下の無印カーネルイメージやinitrdは最新のイメージへのシンボリックリンクなので、-fオプションだけ指定してcpしてやれば実体がコピーされます。
cp -f /boot/vmlinuz /boot/efi/vmlinuz cp -f /boot/initrd.img /boot/efi/initrd.img cp -f /boot/vmlinuz.old /boot/efi/vmlinuz.old cp -f /boot/initrd.img.old /boot/efi/initrd.img.old
といってもaptでカーネル更新するたびに毎回イメージをコピーしてエントリーファイルを修正するのはかなり面倒なので、systemdのユニットファイルを作ってカーネルを更新したら自動でコピーするように設定しておきます。
まずはパス監視用のユニットファイル「/etc/systemd/system/kernel-update.path」を作成。カーネルが更新される≒initrdが新しく作成されるというわけで、initrdを監視しています。
[Unit] Description=Copy Kernel to ESP [Path] PathChanged=/boot/initrd.img [Install] WantedBy=multi-user.target WantedBy=system-update.target
カーネルをコピーするためのユニットファイル「/etc/systemd/system/kernel-update.service」も作成。
[Unit] Description=Copy Kernel to ESP [Service] Type=oneshot ExecStart=/usr/bin/cp -f /boot/vmlinuz /boot/efi/vmlinuz ExecStart=/usr/bin/cp -f /boot/initrd.img /boot/efi/initrd.img ExecStart=/usr/bin/cp -f /boot/vmlinuz.old /boot/efi/vmlinuz.old ExecStart=/usr/bin/cp -f /boot/initrd.img.old /boot/efi/initrd.img.old
あとはsystemdのサービスとして有効化。
systemctl enable kernel-update.path
これでapt経由でカーネルを更新しても自動でイメージがESPにコピーされるようになり、systemd-bootによるブートの準備も整いました。
どんくらい速いの
とりあえず起動するか確認
まずはefibootmgrしてみます。
# efibootmgr BootCurrent: 0000 Timeout: 10 seconds BootOrder: 0001,0000,2001,2002,2003 Boot0000* EFI Hard Drive (LITEON CB1-SD256) Boot0001* Linux Boot Manager Boot2001* EFI USB Device Boot2002* EFI DVD/CDROM Boot2003* EFI Network
「Linux Boot Manager」というやつをUEFIでブート先にしてやればいいみたい。特にスクショはないですが、しっかり起動しました。スペースキー押しながら起動するとブートメニューが出ます。
GRUB2と比較して起動の速さは・・・
MateBook X 2017でこんな感じでした。systemd-bootの方が速い。設定もシンプルなので意外といいかもです。
| GRUB2 | systemd-boot |
|---|---|
| 16.8秒 | 13.8秒 |
systemd-bootに乗り換え
特に問題なさそうだったので、GRUB2からsystemd-bootに乗り換えました。GRUBアンインストールってけっこう新鮮な体験でしたね。
個人的にsystemdは好きなので、この調子でcronとかも置き換わっていくといい感じです。
P.S.
二尊院、本当によいところ。
SESAME miniのロックをMi Band 4で無理やりこじあけてみた
ちょっと油断したら半年弱記事を書いていなかったいぶろぐです。
タイトルには「無理やり」という言葉を入れましたが、ちゃんと正規の手順を踏んでおります。
いきさつ
SESAME miniを買った
いぶろぐはよく持ち物をなくします。家の鍵も例外ではありません。
なくした後に探して出てくればいいのですが、先日家の鍵をガチで紛失してしまいまして。
「家の外に鍵を持ち出すから鍵がなくなるのだ！鍵を持ち歩かなくて済むスマートロックを導入しよう！！」ということで、評判がよく価格も比較的安い「SESAME mini」を購入。
元気に働いてくれています。
どうせならMi Band 4で開錠したい
いぶろぐは現在スマートバンド「Mi Band 4」を愛用しております。
最近はPR動画でコケたXiaomiですが、ハードはやっぱりいい。Apple Watchから乗り換えて大正解でした。
ただ、Apple WatchはSESAME miniに対応していて、Apple Watchからドアの鍵を開けることができるんですよね……
なんか悔しいので、Mi Band 4でもSESAME miniの鍵を開けてみることにしました。
やりかた
必要なもの
SESAME miniの設定はモジュールともどもよしなにやっておいてください。クラウドとの連携もオンにしておく必要があります。
また、「Notify & Fitness for Mi Band」はAndroidのアプリなので、Google Play Storeからインストールしておいてください。
これ、Xiaomi謹製の「Mi Fit」よりもかなり高機能なので、とってもおすすめです。Mi Fitなしで動かせる裏技もあるので、中華アプリを入れたくない方にもおすすめ。
あとはIFTTTですが、アカウントを作っておいてください。
それでは手順というか、備忘録を書いていきます。
手順
１. 下記URLを参考にして、SESAME miniとIFTTTを連携させます。
２. IFTTTのサイトにアクセスし、
「My services」 ↓
「Webhooks」 ↓
「Settings」
と進み、URLの「https://maker.ifttt.com/use/〇〇」の部分をメモしておく
３. IFTTTにて「手順2で設定したWebhookが発火したら、SESAME miniを開錠する」というアプレットを作成する
具体的には……
「Create」 ↓
「This」 ↓
「Webhooks」 ↓
「Receive a web request」 ↓
「Event Name」を適当に入力 ↓
「Create trigger」 ↓
「That」 ↓
「Sesame by CANDY HOUSE」 ↓
「Open Sesame」 ↓
「Create Action」 ↓
「Finish」
これでIFTTTの設定が完了します(全部文字ですみません……)
４. Notify & Fitness for Mi Band側で、Mi Band 4のアクション経由でIFTTTを操作する
具体的には……
「設定」 ↓
「タッチボタン」 ↓
「Button actions - swiping」 ↓
「ボタンの操作」で「IFTTT webhook」を選択 ↓
「設定」 ↓
「イベント名」に先ほどIFTTTで入力した「Event Name」を入力 ↓
「APIキー」に先ほどメモしたURLの〇〇部分を入力 ↓
「テスト」を実行
SESAME miniがきちんと開錠できれば、設定はすべて完了です。
いざ実行！
ボタンの動作は以下の動画がわかりやすいです。
実際にやってみると、無事Mi Band 4でSESAME miniを開錠できました！
ひらけゴマ、できたけど……
まあこんな感じで開錠できるようになったわけですが、予想はしていたものの「レスポンスが激遅」です。
Mi Band 4で操作して、だいたい8秒くらいで開錠されるイメージ。しかもラグが一定ではなく、10秒以上かかることもあります。
なので、いい感じに玄関に着く前に操作して、オートロックの時間も調整しておく必要があります。
さらに致命的なのが、なぜか勝手にSESAME miniが開錠されますwww
履歴を見るとIFTTT経由で開錠されており、大体毎日同じ時間帯で開錠されるので、何かがあるんだろうなと思っていますが、まだ詳しく調査できていません。
オートロックを設定しているので開きっぱなしにはならないのですが、この辺は追ってレポートできたらなと。
スマホを操作せずに鍵を開けることができるようになったのは快適といえば快適なので、満足はしています。
P.S.
曽爾高原、気持ちえぇ～。3密を回避しながら気分転換できるので、自粛で鬱屈とした関西人はぜひ。
