樽スケール警報システムの構築
以前のブログでは、オフィスでコールドブリューコーヒー樽の重量を使用してSlackアラートを送信し、不足してコールドブリューコーヒー樽の補充が必要になったときに通知する方法について詳しく説明しました。
2部構成のシリーズのこの第2部では、私がどのようにスケールを構築したかを紹介します。主に、時間とお金をかけずに何かが欲しかったのですが、私たちのニーズを満たすものはまだありませんでした。
Elasticsearch樽のセットアップ要件
まず、プロジェクトの要件を分類する必要がありました。
- 安い(<$ 100)
- 最小限のケアと給餌
- リモート管理
- 樽のレベルを簡単に報告する
- 樽から冷たいビールを飲むたびに決定します(ストレッチゴール)
- 最も重要なことは、最小限の時間の投資が必要でした*
*私には日雇いの仕事があり、樽のはかりを作ることは私の仕事の説明にはありません。
初期調査
最初の課題は、樽のデータを収集する方法だけでなく、収集するデータを把握することでした。
いくつかのオープンソースプロジェクトは樽の監視を提供します、そして少しの研究の後、測定するための2つの主要な方法は次のとおりです
- 体重
- 流量計を使用する
すでに利用可能なもののほとんどは、流量計を使用しています。樽が流量で「空」であるかどうかを判断するのは少し難しいので、樽がいつ交換されたかを判断するには、何らかのユーザー介入が必要です。さらに、実際のコーヒーラインにデバイスを配置する必要がありますが、これには潜在的な問題があります。
そのため、借りる例がないにもかかわらず、スケールから始めて、重量を使用して樽のレベルを決定するように呼びかけました。
樽スケール
実際の規模のハードウェアについては、RaspberryPiのような小さなコンピューターに接続できる既製のソリューションを探しました。そこにはたくさんのWIFIとBluetoothのスケールがありますが、ほとんどは継続的に読み取られていませんでした。またはバッテリー駆動でした。またはインターフェースするのに大きな手間がかかります。樽特有の鱗がいくつか存在しますが、それらは高すぎました。
もう一度、DIYに行く必要がありました。
Raspberry Piを使用した構築の経験があるため、RaspberryPiを使用してスケールを構築するためのハードウェアが必要でした。まさにこのユースケースのために、AmazonでHX711アンプを備えた50kgのロードセルのセットを見つけました。
HX711でArduinoスケールを構築するための参考資料はたくさんありますが、Piで利用できるものははるかに少ないです。幸いなことに、Instructablesのチュートリアルと、ユーザーtatobariのGithubリポジトリを組み合わせて、法案に適合するPythonHX711ユーティリティをいくつか見つけました。
全体的なアーキテクチャ
まず、システム全体がどのようになるかを示す簡単な回路図を作成する必要がありました。
ハードウェアビルド
最初の課題は、樽の下に置くのに十分な薄さでありながら、150ポンドの樽の重さで曲がらないほど頑丈な樽用冷蔵庫に収まるスケールを見つけることでした。
スケールを補強するために複数の設計と方法を試しましたが、不安定であるか、厚みが増しすぎて、最終的にトップチューブに圧力がかかりました。
最終的なビルドには、古いグリル火格子、火格子を補強するための金物店からの鋼製cチャンネルの小片、ダクトテープの束、および結束バンドが含まれていました。
完璧ではありませんが、最終的にはすべての設計要件を満たしました(少し頑丈なソリューションを念頭に置いている人はいますか?)
配線
HX711ボードを4つのGPIOピンを介してRaspberrypiに接続し、スケールをホイートストンブリッジからの4本のワイヤーを介してHX711ボードに接続する必要がありました(Instructablesを参照)。
樽用冷蔵庫はスペースに非常に制約があり、樽を積み降ろしするときにかなり荒くなる可能性があるため、HX711とラズベリーパイを樽と一緒に配置するのは良い決断ではなかったようです。代わりに、Raspberry PiとHX711をそのすぐ隣、樽用冷蔵庫の外側に配置し、標準ケーブル(古き良き猫5または6)を使用して、実際のスケールからHX711までの距離を長くしました。一方の端に目盛りを付け、もう一方の端にHX711を付けて、RJ45コネクタを追加します。これで、古いイーサネットケーブルを使用して2つを接続できます。
HX711とラズベリーパイの間は、隣り合っているため、標準のジャンパー線を使用しました。
ソフトウェア
Raspberry Piを使用するということは、Linuxで実行されるほとんどすべてのものをソフトウェアに使用できることを意味します。
最初の部分は、GPIOを介してHX711アンプとインターフェースするためのコードです。
そこにあるHX711プロジェクトのほとんどはArduino用ですが、Pythonで書かれたこのようなRaspberryPi用のHX711コードを備えたかなりの数のGitHubリポジトリを見つけることができます。
HX711サンプルコードを使用して、Elasticsearchに送信できるファイルに定期的な重みの読み取り値を単純に書き出す小さなPythonユーティリティを作成しました。構成ファイルから機能し、いくつかのテストモードを含めるように拡張しましたが、それ以外はかなり単純なコードです。
Elasticsearchへのデータの転送
次に、データをElasticsearchに送信する必要がありました。
Filebeatを使用してウェイトファイルを読み取り、そのデータをElasticsearchに送信しました。 PythonスクリプトからElasticsearchに直接書き込むことができます。または、Logstashを使用してファイルを読み取ります。または、スクリプトを直接呼び出して、その場で測定値を取得します。 Filebeatは非常に軽量で、必要な作業は最小限です。
Filebeatを使用する際の唯一の小さな問題は、ElasticがデフォルトでRaspberry Pi/ARMのバイナリを提供しないことです。構築する必要がありました。
幸い、Elasticサイトの説明は非常に明確です。使用するFilebeatのバージョンと一致する適切なバージョンのGoを選択する限り、ビルドは非常に簡単です。 (通常、開発者ガイドで呼び出されますが、そのページの右側で正しいBeatバージョンを選択していることを確認してください。)
すべてのコンポーネントが機能するようになったら、最後のステップは、スケールリーダースクリプトとFilebeatをsystemdサービスとして構成し、起動時に起動させることでした。
データのインデックス作成
その重みデータをElasticsearchでインデックス化する必要がありました。 Filebeatを使用して、取り込みパイプラインを使用してElasticsearch側でデータを解析することにしました。繰り返しになりますが、Logstashはオプションですが、目標はRaspberry Piに絶対最小負荷を作成して、ローカルダッシュボードとして使用し、後でより多くのセンサー(温度など)で拡張できるようにすることでした。
数秒ごとに、単純なウェイトリーダーは、「2018-06-22T20:57:02 + 0000 –134.0」のようなログ行を吐き出します。これは、タイムスタンプの後に「-」と重みの読み取りが続くだけなので、解析が非常に簡単です。したがって、取り込みパイプラインも同様に単純です。
{
"description" : "Parse the readings from the keg scale",
"processors" : [
{
"grok": {
"field": "message",
"patterns": ["^%{TIMESTAMP_ISO8601:readtime}\\s+-\\s+%{BASE10NUM:weight}$"]
}
},
{
"convert": {
"field" : "weight",
"type": "float"
}
},
{
"date" : {
"field" : "readtime",
"formats" : ["ISO8601"]
}
}
],
"on_failure" : [
{
"set" : {
"field" : "ingest_error",
"value" : "{{ on_failure_processor_type }} - Error processing message - {{ _ingest.on_failure_message }} : {{ message }}"
}
}
]
}
結果は、浮動小数点の「重み」とタイムスタンプ、およびFilebeatに含まれるさまざまなメタデータ(後で複数の樽に拡張する場合に使用できます)を含む数秒ごとのドキュメントです。
Elasticsearchクラスター
ObjectRocketを使用すると、この部分が非常に簡単になります。基本的なクラスターを起動し、いくつかのACLを開き、数人のユーザーを設定してから、データの送信を開始できるからです。それ以外の場合、ここでの唯一の実際の要件は、Kibanaを使用した機能的なElasticsearchクラスターです。
まとめ
すべての設定と配置が完了したら、プラグを差し込むだけで済みました。
出来上がり!実行するだけです。
最初の結果を自分で確認できます:
結局、私たちに見せるための簡単なゲージになりました:
- 樽に残っているコールドブリューの割合
- Timelionトレンドライン
- 最新の補充日
このシステムには、CanvasやVegaなどのクールな新しいプロジェクトを含む、さらに多くのアドオンの余地がありますが、今のところ、それで仕事は終わりです。
-
MongoDBインスタンスをスケーリングするタイミング
以前のブログ投稿で、MongoDBを使用した大規模なスケーリングの概要を説明しました。スケーリングは本質的に反応的である傾向があり、アプリケーションのパフォーマンスの低下や、さらに悪いことに、アプリケーション全体のダウンタイムなどの問題を引き起こします。これらの問題は、最終的にはビジネスに影響を与えるネガティブなカスタマーエクスペリエンスにつながります。では、収益に影響を与えないように、Mongoデータベースをスケーリングするのに適切な時期をどのようにして知ることができますか? アプリに適したしきい値を見つける アプリケーションの使用量の増加とトラフィックの急増をアプリケーションが確実に乗り
-
Windows エラー 43
Windows エラー 43 これは、ハードウェアの実行に必要な重要なオプションを PC が正しく処理できないために発生する問題です。通常、このエラーは、ハードウェアのドライバーが正しくないか、実行に必要な設定を処理できないために表示されます。このチュートリアルでは、システムで Windows エラー 43 の問題を修正する方法を示します。 Windows エラー 43 の原因 このエラーは次の形式で表示されます: 問題が報告されたため、Windows はこのデバイスを停止しました (コード 43) エラーは、システムのハードウェアが正しく処理できないために発生します。このエ