2021年08月08日

【スマートホーム】え?Beebotte終わり?

こんにちは。

我が家のスマートホームの構成要素の1つとして「マンションのエントランスドアを鍵を使わずに解錠する」というフローがあります。
このフローは次のような仕組みにしていました。
  1. スマホからMQTTブローカBeebotteにWebhook送信
  2. BeebotteからサブスクライバであるRespberryPiにメッセージ送信
  3. RaspberryPiのNode-REDでメッセージを受信しBluetooth経由でSwitchbotを操作
  4. Switchbotで室内インターホンのエントランスドア解錠ボタンを押下
このフローがひと月前ほどから不安定になり、エントランスで立ち往生することが頻発していました。
数回チャレンジすれば正常動作するので、私は上記3のBluetooth送信が不安定なのかなと思っていました。
ちなみにこの場合、普通に物理鍵を使って解錠してたので実害がありません。
こういう事態に備えて常に物理鍵を持ち歩くという全然スマートじゃないホームだったというわけです。

今日(2021/08/08)になって完全に動作しなくなってしまい、上記3を疑っている私はNode-REDのデバッグを実施。
その結果、Node-REDのBeebotteノードが受信待ちのままスタックしてしまっていることが分かりました。

MQTTでは実際のメッセージ送信前にブローカとサブスクライバの間で事前通信が行われます。
一応Beebotteノードが反応するので、この事前通信は問題ないようです。
おかしいなと思いBeebotteの公式サイトに何かしらの情報が無いかと確認してみました。

SS-2021-08-08 162956.jpg

・・・サーバ死んでるやんけ!
「GOTO HOMEPAGE」とかボタンが表示されていますが、これがそのホームページです。
え〜〜〜〜〜障害?メンテナンス?それともサービス終了?
ネット検索してみましたが何の情報も得られません。
いずれの原因にせよ何の事前通告も無いとなると突然の障害ということでしょうか?
ひと月前からの不安定さを放置し続けたとなれば、サービスを放棄したのでしょうか?
比較的最近書いた記事が現実となってしまい、サーバ設置を許可しないプロバイダに改めて舌打ちしてしまいましたよ。

さてこうなってしまった以上、対策を考えねばなりません。
別のMQTTブローカサービスを検討するのが現実的でしょう。
はあ、めんど。

追記:
本記事を投稿した2時間40分後の2021/08/08 20:00現在、復旧したようです。
サブスクライバとの疎通も確認出来ましたし、公式サイトも従来どおりアクセスできます。
ただし障害やメンテについての報告はどこにもありませんでした。
本件でいろいろネット検索している中で公式Twitterアカウントも確認しましたが、2019年以降ツイートしていないようです。
もうあまりやる気がないのかな・・・
もしものために引き続き他のMQTTブローカを検討しておこうと思います。






.


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

2021年07月21日

【スマートホーム】Nature Remo Local APIが安定しない

こんにちは。

Nature社サーバへの依存度を下げるために、公開されているLocal APIを利用して家電操作を自宅ネットワーク内で完結することにしました。
結論から言うと上手くいかず凍結しています。


セットアップ

Local APIの具体的な利用についてはもうたくさんの情報がネット上にあるので割愛します。
ざっくり書いておくと以下の段取りとなります。
  • Nature Remo本体のホスト名とIPアドレスを調べる。
  • 実行したい家電操作に対応したIRシグナル情報を取得する。
  • IRシグナル情報をHTTPリクエストする。

我が家での問題

セットアップに従って上手く行くには行くのです。
しかし、数時間のインターバルを空けて実行すると、最初の1発目が100%失敗します。
Nature Remo本体からは何のレスポンスもなく原因の特定に至っていません。
失敗の5秒後以降はまた問題なく成功します。


自宅ネットワークの問題?

問題の切り分けが出来ていません。
Nature社もAPI利用の問い合わせには消極的な態度です。

ネット上には同様の例が上がっていないので、もしかしたら我が家のネットワーク固有の問題でインターバル明け1発目のルーティングが失敗している可能性もあります。
自宅ネットワーク内のパケット監視などしてみるとボトルネックがハッキリするかもしれませんが、そこまでやる気もないです。


追記

パケット監視まではしていませんが、様々なパターンで検証してみました。
結果として私はNature Remo本体の問題と結論づけています。
指定したタイムアウト期限までにクライアントに応答できないことが多く家電操作も実行されず、受信後の処理がスタックしてしまってる印象を受けます。
またHTTPレスポンスステータスコード200(=成功)を返してくるもののやはり家電操作が行われなかったりといったことがありました。

いずれも数時間のインターバルを空けた最初のリクエストです。その数秒後からは正常に動作します。
久しぶりのリクエストを受けるとコンディションを整えきれずに失敗するようです。
暖機が必要になる冬の自動車みたいな感じ。

私はHTTPプロトコルについては全くの素人です。
クライアント側はこうしたことを想定して実装するのが常識なのでしょうか?
例えば、まずはサーバにお伺いを立ててから正式にリクエストする所謂コネクション型でリクエストすべき等。
ただしNature RemoのLocal API仕様にはその点には触れていません。
もしかしたらNature Remo本体はNature社サーバと常にコネクションを維持しており、LocalAPIに対しコネクションレスでリクエストしても聞く耳を持たないのかもしれません。

今後この分野に携わることは無いと思いますが、一つの貴重な経験として記憶しておこうと思います。


凍結

Cloud APIは問題なく利用できていて、Nature社サーバがメンテしたり障害が発生しない限りは困ることもありません。
というわけで、Local APIの利用は凍結しました。






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

広告


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

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

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


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。