スマートホーム: ホーム アシスタントで水と電気の消費量をグラフ化する

電気代や水道代の支払いを受け取るたびに、私の家族は本当にたくさんの電力を消費しているのだろうかと疑問に思うのです。 確かに、バスルームには床暖房とボイラーがありますが、彼らは常に消防士として働いているわけではありません。 私たちは水の節約にもなっているようです（ただし、私たちはバスルームで水をかけるのも好きです）。 数年前に私はすでに 接続された水道メーター и 電気 しかし、ここで問題が発生しました。 ようやく消費の分析に手が届きました。実際、それがこの記事の主題です。

最近、スマート ホーム システムとしてホーム アシスタントに切り替えました。 その理由の XNUMX つは、大量のデータの収集を整理し、さまざまな種類のグラフを簡単に作成できることです。

この記事で説明されている情報は新しいものではなく、これらすべてのことはさまざまなソースですでにインターネット上で説明されています。 ただし、各記事では、原則として XNUMX つのアプローチまたは側面のみを説明します。 これらすべてのアプローチを比較し、最も適切なものを自分で選択する必要がありました。 この記事はデータ収集に関する完全な情報をまだ提供していませんが、私がどのようにデータ収集を行ったかについての概要のようなものです。 したがって、建設的な批判や改善の提案は歓迎されます。

問題の定式化

したがって、今日の演習の目標は、水と電力の消費量の美しいグラフを取得することです。

• 2 日間、XNUMX 時間ごと
• 2週間毎日
• (オプション) 毎週および毎月

これにはいくつかの困難があります。

• 標準のグラフ コンポーネントは非常に貧弱な傾向があります。 せいぜい、点ごとに折れ線グラフを作成できます。

  よく検索すると、標準チャートの機能を拡張するサードパーティ コンポーネントを見つけることができます。 ホームアシスタントにとって、原則として、優れた美しいコンポーネント ミニグラフカードただし、ある程度制限もあります。

  • 棒グラフのパラメータを大きな間隔で設定するのは困難です (棒の幅は XNUMX 時間の小数点で設定されます。つまり、XNUMX 時間を超える間隔は小数点で設定されます)。
  • XNUMX つのグラフに異なるエンティティを追加することはできません (温度と湿度、棒グラフと線の組み合わせなど)。
• ホーム アシスタントはデフォルトで最も原始的な SQLite データベースを使用するだけでなく (便利屋の私は MySQL や Postgres のインストールをマスターしていませんでした)、データは最適な方法で保存されません。 したがって、たとえば、パラメータの最小のデジタル パラメータが変更されるたびに、サイズが約 XNUMX キロバイトの巨大な JSON がデータベースに書き込まれます。

  {"entity_id": "sensor.water_cold_hourly", "old_state": {"entity_id": "sensor.water_cold_hourly", "state": "3", "attributes": {"source": "sensor.water_meter_cold", "status": "collecting", "last_period": "29", "last_reset": "2020-02-23T21:00:00.022246+02:00", "meter_period": "hourly", "unit_of_measurement": "l", "friendly_name": "water_cold_hourly", "icon": "mdi:counter"}, "last_changed": "2020-02-23T19:05:06.897604+00:00", "last_updated": "2020-02-23T19:05:06.897604+00:00", "context": {"id": "aafc8ca305ba4e49ad4c97f0eddd8893", "parent_id": null, "user_id": null}}, "new_state": {"entity_id": "sensor.water_cold_hourly", "state": "4", "attributes": {"source": "sensor.water_meter_cold", "status": "collecting", "last_period": "29", "last_reset": "2020-02-23T21:00:00.022246+02:00", "meter_period": "hourly", "unit_of_measurement": "l", "friendly_name": "water_cold_hourly", "icon": "mdi:counter"}, "last_changed": "2020-02-23T19:11:11.251545+00:00", "last_updated": "2020-02-23T19:11:11.251545+00:00", "context": {"id": "0de64b8af6f14bb9a419dcf3b200ef56", "parent_id": null, "user_id": null}}}

  かなりの数のセンサー (各部屋の温度センサー、水道メーター、電気メーター) があり、中にはかなり大量のデータを生成するセンサーもあります。 たとえば、SDM220 電力メーターだけが 10 ～ 15 秒ごとに約 8 個の値を生成するため、そのようなメーターを 100 台設置したいと考えています。また、他のセンサーに基づいて計算されるパラメーターも大量にあります。 それか。 これらすべての値により、データベースが毎日 200 ～ XNUMX MB ずつ簡単に膨張する可能性があります。 XNUMX 週間以内にシステムはほとんど寝返りを打たなくなり、XNUMX か月後にはフラッシュ ドライブが停止します (Raspberry PI に一般的なホーム アシスタントをインストールした場合)。XNUMX 年間データを保存できるかどうかは疑問の余地がありません。

• 運が良ければ、メーター自体で消費量をカウントできます。 いつでもメーターに連絡して、累積消費量が何時であるかを尋ねることができます。 原則として、デジタル インターフェイス (RS232/RS485/Modbus/Zigbee) を備えたすべての電力メーターは、そのような機会を提供します。

  さらに悪いことに、デバイスが単に何らかの瞬間パラメータ (瞬間電力や電流など) を測定したり、X ワット時またはリットルごとにパルスを生成したりできる場合は、さらに悪いことになります。 次に、それを何をどのように統合し、どこに価値を蓄積するかを考える必要があります。 何らかの理由で次のレポートを見逃すリスクがあり、システム全体の精度に疑問が生じます。 もちろん、これらすべてをホーム アシスタントなどのスマート ホーム システムに任せることもできますが、データベース内のエントリ数に関する点は誰もキャンセルしておらず、XNUMX 秒間に XNUMX 回を超えるセンサーのポーリングは機能しません (システムの制限)ホームアシスタントアーキテクチャ）。

アプローチ 1

まず、すぐに提供されるホーム アシスタントを見てみましょう。 一定期間にわたる消費量の測定は、非常に要望の高い機能です。 もちろん、これはずっと前に特殊なコンポーネント、utility_meter として実装されました。

このコンポーネントの本質は、内部で current_accumulated_value 変数を開始し、指定された期間 (時間/週/月) の後にそれをリセットすることです。 コンポーネント自体は受信変数 (ある種のセンサーの値) を監視し、値自体の変更をサブスクライブします。最終結果を取得するだけです。 このことは、構成ファイルのわずか数行で説明されています

utility_meter:
  water_cold_hour_um:
    source: sensor.water_meter_cold
    cycle: hourly
  water_cold_day_um:
    source: sensor.water_meter_cold
    cycle: daily

ここで、sensor.water_meter_cold は、取得したメーターの現在の値 (リットル単位) です。 アイロンから直接 mqttによる。 この設計では、2 つの新しいセンサー、water_cold_hour_um と Water_cold_day_um を作成し、時間ごとおよび毎日の読み取り値を蓄積し、一定期間後にゼロにリセットします。 これは、半日の時間ごとのバッテリーのグラフです。

lovelace-UI の時間足チャートと日足チャートのコードは次のようになります。

      - type: history-graph
        title: 'Hourly water consumption using vars'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Daily water consumption using vars'
        hours_to_show: 360
        entities:
          - sensor.water_day

実際、このアルゴリズムには、このアプローチの問題点があります。 すでに述べたように、受信値 (次の各リットルの現在のメーター読み取り値) ごとに、1kb のレコードがデータベースに生成されます。 各ユーティリティ メーターも新しい値を生成し、これもベースに追加されます。 数時間、毎日、毎週、毎月の測定値を収集したい場合、そうです、複数の給水塔について、さらには電気メーターのパックを追加すると、大量のデータになります。 正確に言うと、データはそれほど多くありませんが、ホーム アシスタントが不要な情報をデータベースに大量に書き込むため、データベースのサイズは飛躍的に増大します。 週足や月足チャートのベースの大きさを見積もるのも怖いです。

また、公共料金メーター自体が問題を解決するわけではありません。 公共料金メーターのプロットは、0 時間ごとに XNUMX にリセットされる単調増加関数です。 また、期間中に何リットル食べたかといった、使いやすい消費スケジュールも必要です。 標準の履歴グラフ コンポーネントはこれを行いませんが、外部のミニグラフカード コンポーネントが役に立ちます。

これは、lovelace-UI のカード コードです。

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_hour_um
        group_by: hour
        hours_to_show: 48
        name: "Hourly water consumption aggregated by utility meter"
        points_per_hour: 1
        show:
          graph: bar
        type: 'custom:mini-graph-card'

センサー名、グラフの種類、色 (標準のオレンジが気に入らなかった) などの標準設定に加えて、ここでは 3 つの設定に注意することが重要です。

• group_by:hour - 時間の始まりに合わせて列が配置されたグラフが生成されます
• Points_per_hour: 1 時間あたり XNUMX - XNUMX バー
• そして最も重要なのは、aggregate_func: max は各時間内の最大値を取得することです。 鋸歯状グラフを棒グラフに変えるのはこのパラメータです。

左側の列の行には注意を払わないでください。これは、データがない場合のコンポーネントの標準の動作です。 しかし、データはありませんでした。私はこの記事のために、数時間前に公共料金メーターを使用したデータ収集をオンにしただけです (私の現在のアプローチについては、もう少し下で説明します)。

この図では、データ表示が機能する場合もあり、バーが実際に正しい値を反映していることを示したかったのです。 しかし、それだけではありません。 何らかの理由で、午前 11 時から午前 12 時までの期間の強調表示された列には 19 リットルが表示されますが、同じセンサーからの同じ期間の少し上の歯状のグラフでは、62 リットルの消費量が表示されます。 虫か手が曲がっているかのどちらかです。 しかし、なぜ右側のデータが途切れたのかはまだわかりません。消費量は正常であり、歯の多いグラフからもそれがわかります。

一般に、私はこのアプローチの妥当性を達成できませんでした。グラフはほとんどの場合、ある種の異端を示しています。

日中センサーの同様のコード。

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_day_um
        group_by: interval
        hours_to_show: 360
        name: "Daily water consumption aggregated by utility meter"
        points_per_hour: 0.0416666666
        show:
          graph: bar
        type: 'custom:mini-graph-card'

group_by パラメータは間隔に設定されており、points_per_hour パラメータがすべてを決定することに注意してください。 そして、これはこのコンポーネントのもう 1 つの問題です。points_per_hour は 24 時間以下のチャートではうまく機能しますが、それより長い間隔ではうんざりするほど機能しません。 したがって、0.04166666 日に XNUMX 列を取得するには、値 XNUMX/XNUMX=XNUMX を入力する必要がありました。 私は週足チャートや月足チャートについて話しているのではありません。

アプローチ 2

ホーム アシスタントについてまだ考え中だったときに、次のビデオを見つけました。

同志は、いくつかの種類の Xiaomi ソケットから消費データを収集します。 彼のタスクはもう少し単純です。今日、昨日、そして今月の消費量を表示するだけです。 チャートは必要ありません。

瞬間電力値の手動積分に関する議論は脇に置いておきましょう。このアプローチの「精度」については上ですでに書きました。 同じアウトレットによってすでに収集されている累積消費量値をなぜ彼が使用しなかったのかは明らかではありません。 私の意見では、鉄片の内部に統合する方がうまくいくと思います。

ビデオから、一定期間の消費量を手動でカウントするというアイデアを取り上げます。 男性の場合、今日と昨日の値のみが考慮されますが、さらに進んでグラフを描いてみます。 私の場合の提案手法の要点は以下の通りです。

変数 value_at_the_beginning_of_hour を作成し、そこに現在のカウンターの読み取り値を書き込みます
時間の終わり（または次の時間の始まり）のタイマーに従って、現在の測定値と時間の初めに保存された測定値の差を計算します。 この差が現在の時間の消費量になります。値をセンサーに保存し、将来的にはこの値に基づいてグラフを構築します。
また、変数 value_at_beginning_of_hour にカウンターの現在の値を書き込んで、変数 value_at_beginning_of_hour を「リセット」する必要もあります。

これらはすべて、ホーム アシスタント自体を使用して行うことができます。

前のアプローチよりも少し多くのコードを記述する必要があります。 これらの「変数」から始めましょう。 そのままでは「変数」エンティティはありませんが、MQTT ブローカーのサービスを使用できます。 そこに、retain=true フラグを付けて値を送信します。これにより、値がブローカー内に保存され、ホーム アシスタントが再起動された場合でも、いつでも取り出すことができます。 時間カウンターと日カウンターを一気に作りました。

- platform: mqtt
  state_topic: "test/water/hour"
  name: water_hour
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/hour_begin"
  name: water_hour_begin
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day"
  name: water_day
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day_begin"
  name: water_day_begin
  unit_of_measurement: l

すべての魔法はオートメーションで起こり、それぞれ毎時と毎晩実行されます。

- id: water_new_hour
  alias: water_new_hour
  initial_state: true
  trigger:
    - platform: time_pattern
      minutes: 0
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/hour"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_hour_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/hour_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

- id: water_new_day
  alias: water_new_day
  initial_state: true
  trigger:
    - platform: time
      at: "00:00:00"
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/day"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_day_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/day_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

どちらの自動化も次の 2 つのことを行います。

• 開始値と終了値の差として間隔ごとの値を計算します。
• 次の間隔の基本値を更新します

この場合のグラフの構築は、通常の履歴グラフによって解決されます。

      - type: history-graph
        title: 'Hourly water consumption using vars'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Daily water consumption using vars'
        hours_to_show: 360
        entities:
          - sensor.water_day

これは次のようになります。

原則として、これはすでに必要なものです。 この方法の利点は、データが間隔ごとに 24 回生成されることです。 それらの。 時間足チャートでは XNUMX 日あたり合計 XNUMX エントリ。

残念ながら、これでも基地の拡大という一般的な問題はまだ解決されていません。 毎月の消費量グラフが必要な場合は、少なくとも 200 年間のデータを保存する必要があります。 また、ホーム アシスタントはデータベース全体に対して 200000 つの保存期間設定しか提供しないため、システム内のすべてのデータを XNUMX 年間保存する必要があることを意味します。 たとえば、私は XNUMX 年に XNUMX 立方メートルの水を消費します。これは、データベースに XNUMX のエントリがあることを意味します。 そして、他のセンサーを考慮すると、図は一般的に卑劣になります。

アプローチ 3

幸いなことに、賢明な人々は InfluxDB データベースを作成することでこの問題をすでに解決しています。 このデータベースは、時間ベースのデータを保存するために特別に最適化されており、さまざまなセンサーの値を保存するのに最適です。 このシステムは、データベースから値を抽出し、さまざまな方法でそれらを集計できる SQL に似たクエリ言語も提供します。 最後に、異なるデータを異なる時間に保存できます。 たとえば、温度や湿度などの頻繁に変化する測定値は数週間しか保存できませんが、毎日の水消費量の測定値は XNUMX 年間保存できます。

InfluxDB に加えて、賢い人々は InfluxDB のデータからグラフを描画するシステムである Grafana も発明しました。 Grafana はさまざまなタイプのチャートを描画し、詳細にカスタマイズできます。そして最も重要なことは、これらのチャートを lovelace-UI ホーム アシスタントに「接続」できることです。

触発されます ここで и ここで。 この記事では、InfluxDB と Grafana をインストールしてホーム アシスタントに接続するプロセスについて詳しく説明します。 私は特定の問題を解決することに集中します。

そこで、まず influxDB にカウンター値を追加してみましょう。 ホーム アシスタントの設定の一部 (この例では、冷水だけでなく温水も楽しみます):

influxdb:
  host: localhost
  max_retries: 3
  default_measurement: state
  database: homeassistant
  include:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

ホーム アシスタントの内部データベースが再び膨張しないように、同じデータの保存を無効にしましょう。

recorder:
  purge_keep_days: 10
  purge_interval: 1
  exclude:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

次に、InfluxDB コンソールに移動してデータベースを設定しましょう。 特に、特定のデータを保存する期間を構成する必要があります。 これはいわゆる規制されています。 保持ポリシー - これはメイン データベース内のデータベースに似ており、各内部データベースには独自の設定があります。 デフォルトでは、すべてのデータは autogen と呼ばれる保持ポリシーに追加され、このデータは XNUMX 週間保存されます。 時間ごとのデータは XNUMX か月間保存し、週ごとのデータは XNUMX 年間保存し、月ごとのデータはまったく削除しないようにしたいと考えています。 適切な保存ポリシーを作成します

CREATE RETENTION POLICY "month" ON "homeassistant" DURATION 30d REPLICATION 1
CREATE RETENTION POLICY "year" ON "homeassistant" DURATION 52w REPLICATION 1
CREATE RETENTION POLICY "infinite" ON "homeassistant" DURATION INF REPLICATION 1

さて、実際、主なトリックは連続クエリを使用したデータ集計です。 これは、指定した間隔でクエリを自動的に起動し、そのクエリのデータを集計し、その結果を新しい値に追加するメカニズムです。 例を見てみましょう (読みやすくするために列に書いていますが、実際にはこのコマンドを XNUMX 行で入力する必要がありました)

CREATE CONTINUOUS QUERY cq_water_hourly ON homeassistant 
BEGIN 
  SELECT max(value) AS value 
  INTO homeassistant.month.water_meter_hour 
  FROM homeassistant.autogen.l 
  GROUP BY time(1h), entity_id fill(previous) 
END

このコマンド:

• homeassistant データベースに cq_water_cold_hourly という名前の継続クエリを作成します
• クエリは 1 時間ごとに実行されます (time(XNUMXh))
• クエリは、冷水と温水の測定値を含む、homeassistant.autogen.l (リットル) の測定値からすべてのデータを取得します。
• 集約されたデータはentity_idによってグループ化され、冷水と温水に別々の値が作成されます。
• リットルのカウンターは時間ごとに単調増加するため、最大値を取得する必要があり、集計は max(value) 関数によって実行されます。
• 新しい値は homeassistant.month.water_meter_hour に書き込まれます。month は、保持期間が XNUMX か月の保持ポリシーの名前です。 さらに、冷水と温水のデータは、対応するentity_idとvalueフィールドの値を持つ別々のレコードに分散されます。

夜間や家に誰もいないときは水の消費がないため、homeassistant.autogen.l にも新しいレコードはありません。 通常のクエリで値の欠落を避けるために、fill(previous) を使用できます。 これにより、InfluxDB は過去 XNUMX 時間の値を使用するようになります。

残念ながら、連続クエリには特殊な点があります。fill(previous) トリックは機能せず、レコードは単に作成されません。 さらに、これはある種の克服できない問題です。 XNUMX年以上議論されてきた。 この問題は後で扱いますが、継続クエリに fill(previous) を含めておきます。これは干渉しません。

何が起こったのかを確認してみましょう (もちろん、数時間待つ必要があります)。

> select * from homeassistant.month.water_meter_hour group by entity_id
...
name: water_meter_hour
tags: entity_id=water_meter_cold
time                 value
----                 -----
...
2020-03-08T01:00:00Z 370511
2020-03-08T02:00:00Z 370513
2020-03-08T05:00:00Z 370527
2020-03-08T06:00:00Z 370605
2020-03-08T07:00:00Z 370635
2020-03-08T08:00:00Z 370699
2020-03-08T09:00:00Z 370761
2020-03-08T10:00:00Z 370767
2020-03-08T11:00:00Z 370810
2020-03-08T12:00:00Z 370818
2020-03-08T13:00:00Z 370827
2020-03-08T14:00:00Z 370849
2020-03-08T15:00:00Z 370921

データベース内の値は UTC で保存されているため、このリストは 3 時間異なります。InfluxDB 出力の午前 7 時の値は、上のグラフの午前 10 時の値と一致します。 また、午前 2 時から 5 時の間はレコードがまったくないことにも注意してください。これはまさに継続的クエリの特徴です。

ご覧のとおり、集計値も単調増加シーケンスですが、エントリの頻度が低くなっている (XNUMX 時間に XNUMX 回) だけです。 しかし、これは問題ではありません。グラフの正しいデータを抽出する別のクエリを作成できます。

SELECT difference(max(value)) 
FROM homeassistant.month.water_meter_hour 
WHERE entity_id='water_meter_cold' and time >= now() -24h 
GROUP BY time(1h), entity_id 
fill(previous)

解読します：

• homeassistant.month.water_meter_hour データベースから、過去 24 日 (time >= now() -XNUMXh) のentity_id='water_meter_cold' のデータを取得します。
• 前述したように、homeassistant.month.water_meter_hour シーケンスから一部のエントリが欠落している可能性があります。 GROUP BY time(1h) を指定してクエリを実行して、このデータを再生成します。 今回は、fill(previous) が適切に機能し、欠落しているデータが生成されます (関数は前の値を取得します)。
• このクエリで最も重要なのは、時間マーク間の差を計算する差分関数です。 それ自体では機能しないため、集計関数が必要です。 これを以前に使用した max() とします。

実行結果はこんな感じ

name: water_meter_hour
tags: entity_id=water_meter_cold
time                 difference
----                 ----------
...
2020-03-08T02:00:00Z 2
2020-03-08T03:00:00Z 0
2020-03-08T04:00:00Z 0
2020-03-08T05:00:00Z 14
2020-03-08T06:00:00Z 78
2020-03-08T07:00:00Z 30
2020-03-08T08:00:00Z 64
2020-03-08T09:00:00Z 62
2020-03-08T10:00:00Z 6
2020-03-08T11:00:00Z 43
2020-03-08T12:00:00Z 8
2020-03-08T13:00:00Z 9
2020-03-08T14:00:00Z 22
2020-03-08T15:00:00Z 72

午前 2 時から午前 5 時 (UTC) まで消費はありませんでした。 それにもかかわらず、クエリは fill(previous) のおかげで同じ消費値を返し、差分関数はこの値をそれ自体から減算し、出力で 0 を取得しますが、これは実際に必要です。

あとはグラフを作成するだけです。 これを行うには、Grafana を開き、既存の (または新しい) ダッシュボードを開き、新しいパネルを作成します。 チャートの設定は以下のようになります。

冷水と温水のデータを同じグラフで表示します。 リクエストは上で説明したものとまったく同じです。

表示パラメータは以下のように設定します。 私にとって、それは線（線）を含むグラフであり、それは段階（階段）に進みます。 以下、Stackパラメータについて説明する。 以下にさらにいくつかの表示オプションがありますが、それほど興味深いものではありません。

結果のグラフをホーム アシスタントに追加するには、次の操作を行う必要があります。

• チャート編集モードを終了します。 何らかの理由で、正しいグラフ共有設定はダッシュボード ページからのみ提供されます。
• チャート名の横にある三角形をクリックし、メニューから「共有」を選択します
• 開いたウィンドウで、「埋め込み」タブに移動します
• 現在の時間範囲のチェックを外します - URL を介して時間範囲を設定します
• 必要なトピックを選択します。 私の場合は軽いです
• 結果の URL を lovelace-UI 設定カードにコピーします。

      - type: iframe
        id: graf_water_hourly
        url: "http://192.168.10.200:3000/d-solo/rZARemQWk/water?orgId=1&panelId=2&from=now-2d&to=now&theme=light"

期間 (過去 2 日間) はダッシュボードの設定ではなく、ここで設定されることに注意してください。

チャートはこんな感じです。 ここ2日間はお湯を使っていないので、冷水のグラフのみが描かれています。

ステップラインとリアルバーのどちらのチャートが一番好きか、私自身はまだ決めていません。 したがって、今回はバーでのみ、XNUMX日の消費スケジュールの例を簡単に示します。 クエリは上記と同じ方法で構築されます。 表示オプションは次のとおりです。

このチャートは次のようになります。

ということで、Stackパラメータについて。 このグラフでは、冷たい水のバーが熱いバーの上に描かれています。 全高は、その期間の冷水と温水の総消費量に相当します。

表示されるすべてのグラフは動的です。 マウスを関心のあるポイントの上に移動すると、特定のポイントの詳細と値を確認できます。

残念ながら、軟膏の中にハエが数匹いないわけではありませんでした。 棒グラフ (階段状のグラフとは異なります) では、棒の中央は日中ではなく 00:00 にあります。 それらの。 バーの左半分が前日の代わりに描画されます。 そのため、土曜日と日曜日のチャートは青みがかったゾーンの少し左側に描かれています。 勝ち方が分かるまでは。

もう 30 つの問題は、毎月の間隔を正しく機能できないことです。 実際には、時間/日/週の長さは固定されていますが、月の長さは毎回異なります。 InfluxDB は等間隔でのみ動作します。 これまでのところ、私の頭脳は XNUMX 日という一定の間隔を設定するのに十分でした。 はい、チャートは年間を通じて少し浮き、棒は月に正確に対応しません。 でも、これは単に表示メーターとして興味があるので、これでOKです。

少なくとも XNUMX つの解決策が考えられます。

• 月次チャートでスコアを獲得し、週次チャートに限定します。 52 年に XNUMX 週足はかなり良いように見えます
• 月々の消費量自体は方法 2 として考え、美しいグラフを作成する場合にのみ grafana を使用します。 それはかなり正確な解決策です。 過去 XNUMX 年間のチャートを重ねて比較することもできます。grafana ならそれができます。

まとめ

理由はわかりませんが、私はこの種のチャートが大好きです。 彼らは、人生が本格化し、すべてが変化していることを示しています。 昨日はたくさんありましたが、今日は少なく、明日はまた何かがあるでしょう。 消費というテーマについては、家計との協力が引き続き必要だ。 しかし、現在の食欲を考慮しても、法案に記載されている大きくて理解できない数字だけで、すでにかなり理解できる消費の全体像に変わりつつあります。

プログラマーとして 20 年近くのキャリアがあるにもかかわらず、私はデータベースにほとんど触れたことがありませんでした。 したがって、外部データベースのインストールは非常に難解で理解できないもののように思えました。 すべてが変わった 上の記事 - 適切なツールを使用すると、数回クリックするだけでネジを締めることができ、専用のツールを使用すると、プロットの作業が少し簡単になることがわかりました。

タイトルで消費電力について触れました。 残念ながら、現時点ではグラフを提供できません。 120 つの SDMXNUMX メーターが故障しており、もう XNUMX つは Modbus 経由でアクセスするとバグが発生します。 ただし、これはこの記事の主題にはまったく影響しません。グラフは水の場合と同じ方法で構築されます。

この記事では、私自身が試したアプローチを紹介しました。 確かに、私が知らないデータの収集と視覚化を整理する他の方法がいくつかあります。 コメントでそれについて教えてください。非常に興味があります。 建設的な批判と新しいアイデアを喜んで受け入れます。 上記の内容が誰かのお役に立てば幸いです。

出所： habr.com