こちらの記事は、William Belk 氏により2016年8月に公開された『 Keep the Beer Cold with IoT (but not too cold) 』の和訳です。
本記事は原著者から許可を得た上で記事を公開しています。
これは業務用冷蔵庫の温度を監視し、SMSのテキストメッセージを送信し、中央サービスにデータを公開する3.3ボルトのシンプルなArduino対応デバイスの話です。
IoTは最もクールなテクノロジーです。基板は毎年のように小さくなり、その可能性は日々広がっていきます。 私もスマートデバイスを生活やビジネスに取り入れる方法を見つけようとしてきました。そして、私のビール会社である Blessed Brewingは 楽しいIoTの実験場として最適だと考えています。
課題
何かを冷やしておくこと自体は、とてもシンプルなことのように思えます。業務用冷蔵装置にはあらゆる形とサイズがあります。しかし、かなり細かい精度で監視や調整をすることは、驚くほど難しいのです。Blessed Brewingでは、おそらく3万ドル相当の生ビールを冷蔵倉庫に保管しています。もしビールを約2°Cに保つことができたら、お客様は最もダイナミックな風味のビールを楽しめるようになります。冷たいビールはより長い時間新鮮さを保つことができますが、それ以上に重要なのは、その微妙な風味のニュアンスを保っていることです。これは、特に、Big Fifty Pale Aleのようなホップの香りがするデリケートなビールには重要です。
醸造業界の一般的な経験則としては、約38°Cで1週間保存されたビールは、約21°Cで2ヶ月保存されたビールと同じくらい古く、約4°Cで1年保存されたビールと同じくらい古い味がするというものがあります。
保冷庫はシンプルで機械的で予測可能なので、彼らは、IoTパフォーマンス監視、障害防止、通知のための非常に説得力のあるケースを作成しています。
- 装置のデフォルトの温度範囲がアプリケーションに合っていない場合は？
- サービス技術者がサーモスタットの調整を怠った場合は？
- コンプレッサーが故障したら？
- サーキットブレーカーがパネル上で爆発したら？
- 私たちが不在の間に当社の施設で停電があったら？
- 休暇中の週末にこれらのことが起こった場合や、4日間クーラーのドアを開けなかった場合は？
- 従業員がクーラーの温度が36度ではなく59度であることに気づかなかった場合は？
一方、クーラーが冷えすぎたら？
週末の休日にクーラーの温度が約-9ºCになったら？
私たちのサーモスタットが故障したり 校正ができなくなったり ワイヤーがショートしたりする可能性もあります。
https://inkybeer.com/tag/frozen-beer/
3万ドルの価値もある私たちの栄光のビールが爆発（冷凍されたビールは爆発してしまいます）してしまったり、または私たちの樽のバルブが、冷圧で膨張し、永久的な損傷を引き起してしまったら、私たちは泣いてしまうでしょう。
解決策
3.3V、2GのSMS Arduinoデバイスをいくつか構築し、導入してみましょう。これは、クリティカルなインフラの故障という潜在的なリスクを制限したいという飽くなき欲求を満たすはずです。
これらのセンサーは以下の項目に従ってプログラムしていきます。
- 電波の強さを表示、携帯電話のネットワークに登録し、多くのステータスライトを点灯します。
- 1分ごとに温度を測ります。
- 温度が約-2ºCまたは8ºCになったら、SMSでテキストメッセージを送信します。
- 過去の傾向を解析したデータをダッシュボードに可視化します。
2G SMS、HTTP通信、48 時間駆動のリチウム電池搭載の 3.3V IoT 温度センサー
デバイスの構成
- HTTP送信のためのGPRSおよび、SMSのための 2G SIM 付属の Arduino対応の基板
- 防水の温度センサー
- リチウム電池
- アンテナ
- USBウォールソケットとケーブル
- 電源スイッチ
- LED電球
- たくさんのはんだ付け
- たくさんのC言語で書かれたコード
デザインの検討
なぜ、業務用で使用可能なWiFiセンサーを使っていないのしょうか？ WiFiは電池が切れたり、Time Warnerのネットワークがダウンした場合は動作しなくなってしまいます。(どんなインターネット企業でも、Wi-Fiが最も必要なときにどれだけ信頼できるかを聞いてみてください)。2Gデータネットワークは非常に安定し、省電力であり、また当社のデバイスはSMSテキストを送信したり、当社のメインサービスにデータを公開したりしている間、48時間以上もバックアップバッテリーで動作することができます。さらにリアルタイムのデータをWiFi経由でストリームする必要はありません。温度は2分以上変化せず、変化はほとんど直線的だからです(冷却中は下降、コンプレッサーが作動していない場合は上昇します。)。私は、http://wirelesstag.net/ やその他のサイトを見てみたが、データ接続をWiFiに完全に依存するのはあまりにも脆弱で、リソースを大量に消費してしまいます。私が考えていた最もクールなデバイスはMonnitの工業的なセンサーです。しかし、これは自己完結型のユニットではなく、各センサーがウェブサービスにデータを送信するために接続するための追加の中央セルラーゲートウェイを必要とします。さらに、1つのデバイスを拡張して、GPS＋温度のように複数のことができるようにすることができません（「冷蔵配送車」の項は下を読んでください）。最後に、自分で作らないと面白くないですよね!
**各冷蔵庫をArduinoセンサーに接続し、リレーを使って温度に応じてオンオフを制御するのはどうでしょうか。**これは非常に魅力的なオプションですが、車輪の再発明はしたくありませんでした。私たちのサーモスタットは素晴らしいです。一度適切に調整されれば（新しいデータの可視化の助けを借りて）、当社のサーモスタットは予想される範囲内で確実に動作し、小さな校正のためのコードプッシュを必要としません。
BrewPiを使うのはどうでしょうか？BrewPiは総合的に見れば素晴らしいですが、いくつかの理由、1.)機器が大きく場所をとってしまう、2.) 冷蔵庫の自家醸造用に最適化されている、3.)電気消費が激しく、バッテリーのフェイルオーバーが考慮されていない(何日かはバッテリーを維持する必要がある)ことにより、私たちにとっては理想的なオプションではありませんでした。
重要なポイント
全体としては難しいプロジェクトでしたが、非常にやりがいのあるものでした。細部に至るまで、コード、ハードウェア、センサー、業務用冷蔵庫、サーモスタットなどには多くの面白い癖がありました。特に面白かったのは、冷蔵システムの様子が変化することを可視化できたことです。
私は当初、以下のようなことに対して、非常に無知/無意識になっていました。
- 温度計が完全に正確になることは稀です。私たちの温度計の1つは、約3ºCほどずれていました。
- サーモスタットは、まったく同じように調整されていることはほとんどありません。例えば、カットインとカットアウトの温度が全てマップ上にありました。私たちのユニットの一つで、機械式のRancoサーモスタット(最終的にサーモスタットを2つの異なるモデルに交換しなければならなかった)は、-2ºCの温度変動から始めるようにしました。
- 下の図に示すように、希望する平均温度を達成するための適切なカットイン/カットアウトの調整の重要性を簡単に視覚化することができます。当社のウォークインクーラーの1つは、デフォルトの温度範囲が非常に狭いものでした。ユニットのLED温度表示は常に予想される範囲内にあるため、データをグラフ化してみないとわかりませんでした。実際の温度データをグラフ化してみたところ、コンプレッサーの希望の平均温度を達成するためのサイクルが短く、オン/オフのサイクルが多くなってしまい、将来的にコンプレッサーが早期に故障してしまう可能性が高いことがわかりました。
冷蔵庫を二度と信用してはいけないと教えてくれたことを除けば、このプロジェクトから得た一番の収穫は、IoTへの興奮を煽り、Arduinoと低消費電力のコネクテッドデバイスが、今後10年の間に世界的なイノベーションの大きな部分を占めるだろうと感じさせてくれたことです。
冷蔵配送車はどうでしょうか？
よく聞いてくれました！GPSと温度監視を一緒にするのは大変なので、3.3 V 2 G SMS Temperature Sensorsの機能を5 V 3 Gデバイスに拡張して、配達箱の温度を監視し、車のGPS位置をマッピングします。データはこちらです(http://data.blssd.co/data/vehicles)
冷蔵車の方が荷台の開放や積み下ろしなどで温度変化が起きやすいので、潜在的な故障シナリオや調整などでうんざりさせないように考慮します。現在の実装では、ビールはどこにあるのか？ とか、**配送トラックの荷台が冷えることはないのか？**など
これで終わりです！
もし私たちの完璧に冷えたビールに興味を持ってくれた方は、サンルイス・オビスポとロサンゼルスで生ビールや瓶ビールをご用意しております。
もし、醸造所、ワイン、食品サービス会社がクールなIoTテクノロジーを実装するのを私に手伝ってほしい場合は、iot@blessedbrewing.comにメッセージを送ってください。
翻訳協力
Original Author: William Belk
Thank you for letting us share your knowledge!
この記事は以下の方々のご協力により公開する事が出来ました。
改めて感謝致します。
選定担当: tsurumaki
翻訳担当: @r_pg10
監査担当: takujio
公開担当: @r_pg10
ご意見・ご感想をお待ちしております
今回の記事は、いかがだったでしょうか？
・こうしたら良かった、もっとこうして欲しい、こうした方が良いのではないか
・こういったところが良かった
などなど、率直なご意見を募集しております。
いただいたお声は、今後の記事の質向上に役立たせていただきますので、お気軽にコメント欄にてご投稿ください。
みなさまのメッセージをお待ちしております。