스마트 홈: 홈 어시스턴트에서 물 및 전기 소비량 차트

전기와 물에 대한 대가를 받을 때마다 궁금해집니다. 우리 가족이 정말 그렇게 많이 소비할까요? 예, 욕실에는 바닥 난방과 보일러가 있지만 항상 소방관으로 일하지는 않습니다. 우리는 또한 물을 절약하는 것 같습니다(화장실에서 물을 튀기는 것도 좋아하지만). 나는 몇 년 전에 이미 연결된 수량계 и 전기 스마트 홈으로 전환했지만 거기에서 문제가 발생했습니다. 우리는 이제 소비 분석에 들어섰고, 이것이 바로 이 기사의 실제 내용입니다.

최근에 스마트 홈 시스템으로 Home Assistant로 전환했습니다. 그 이유 중 하나는 다양한 종류의 그래프를 편리하게 구성할 수 있는 가능성과 함께 많은 양의 데이터 수집을 구성할 수 있는 능력이었습니다.

이 기사에 설명된 정보는 새로운 것이 아니며 다른 소스에 있는 이러한 모든 내용은 이미 인터넷에 설명되어 있습니다. 그러나 각 기사는 원칙적으로 하나의 접근 방식이나 측면만 설명합니다. 이 모든 접근 방식을 비교하고 가장 적합한 방식을 직접 선택해야 했습니다. 이 기사는 여전히 데이터 수집에 대한 완전한 정보를 제공하지는 않지만 내가 수행한 방법에 대한 일종의 요약입니다. 따라서 건설적인 비판과 개선을 위한 제안을 환영합니다.

문제 성명

따라서 오늘 운동의 목표는 물과 전기 소비에 대한 아름다운 그래프를 얻는 것입니다.

• 2일 동안 매시간
• 2주간 매일
• (선택 사항) 매주 및 매월

여기에는 몇 가지 어려움이 있습니다.

• 표준 차트 구성 요소는 상당히 열악한 경향이 있습니다. 기껏해야 포인트별로 선 그래프를 작성할 수 있습니다.

  잘 검색하면 표준 차트의 기능을 확장하는 타사 구성 요소를 찾을 수 있습니다. 가정 비서의 경우 원칙적으로 훌륭하고 아름다운 구성 요소 미니 그래프 카드, 그러나 다소 제한적입니다.

  • 막대 그래프의 매개 변수를 큰 간격으로 설정하기 어렵습니다(막대의 너비는 시간 단위로 설정되므로 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-XNUMXMB씩 쉽게 확장할 수 있습니다. 일주일 안에 시스템은 간신히 뒤척이고 한 달 안에 플래시 드라이브가 죽고 (라즈베리 PI에 일반적인 홈 어시스턴트 설치의 경우) XNUMX 년 동안 데이터 저장에 대한 의문의 여지가 없습니다.

• 운이 좋다면 측정기가 소비량 자체를 계산할 수 있습니다. 언제든지 미터기를 켜서 누적 소비량이 몇시인지 물어볼 수 있습니다. 일반적으로 디지털 인터페이스(RS232/RS485/Modbus/Zigbee)가 있는 모든 전기 계량기는 이러한 기회를 제공합니다.

  설상가상으로 장치가 일부 순간 매개변수(예: 순간 전력 또는 전류)를 단순히 측정하거나 단순히 X 와트시 또는 리터마다 펄스를 생성할 수 있는 경우입니다. 그런 다음 어떻게 무엇을 통합하고 어디에 가치를 축적할지 고민해야 합니다. 어떤 이유로든 다음 보고서를 놓칠 위험이 있으며 시스템 전체의 정확성에 의문이 제기됩니다. 물론 이 모든 것을 홈 어시스턴트와 같은 스마트 홈 시스템에 맡길 수 있지만 아무도 데이터베이스의 항목 수에 대한 포인트를 취소하지 않았으며 폴링 센서는 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을 만들어 시간별 및 일별 판독값을 누적하고 일정 기간 후에 XNUMX으로 재설정합니다. 다음은 반나절 동안의 시간당 배터리 그래프입니다.

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의 레코드가 데이터베이스에 생성됩니다. 각 유틸리티 미터는 또한 기본에 추가되는 새 값을 생성합니다. 시간별/일별/주별/월별 판독값을 수집하고 싶다면 예, 여러 개의 급수관에 대해 전기 계량기 팩을 추가하려면 많은 데이터가 필요할 것입니다. 더 정확하게는 데이터가 많지 않지만 홈 어시스턴트가 데이터베이스에 불필요한 정보를 많이 작성하기 때문에 데이터베이스 크기가 비약적으로 커집니다. 주간 및 월간 차트의 기준 크기를 추정하는 것도 두렵습니다.

또한 유틸리티 측정기 자체로는 문제가 해결되지 않습니다. utility meter 플롯은 매시간 0으로 재설정되는 단조롭게 증가하는 함수입니다. 또한 사용자 친화적인 소비 일정, 즉 해당 기간 동안 몇 리터를 섭취했는지도 필요합니다. 표준 히스토리 그래프 구성 요소는 이를 수행하지 않지만 외부 미니 그래프 카드 구성 요소가 도움이 될 수 있습니다.

이것은 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 - 시간당 하나의 막대
• 그리고 가장 중요한 것은 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 매개변수는 모든 것을 지배합니다. 그리고 이것은 이 구성 요소의 또 다른 문제입니다. points_per_hour는 1시간 이하의 차트에서는 잘 작동하지만 더 큰 간격에서는 역겹게 작동합니다. 그래서 하루에 하나의 컬럼을 얻으려면 24/0.04166666=XNUMX 값을 입력해야 했습니다. 나는 주간 및 월간 차트에 대해 말하는 것이 아닙니다.

접근법 2

여전히 홈 어시스턴트를 파악하는 동안 나는 다음 비디오를 발견했습니다.

동지는 여러 유형의 Xiaomi 소켓에서 소비 데이터를 수집합니다. 그의 작업은 조금 더 간단합니다. 오늘, 어제 및 해당 월의 소비 가치를 표시하기만 하면 됩니다. 차트가 필요하지 않습니다.

순간 전력 값의 수동 통합에 대한 논쟁은 제쳐두고 위의이 접근 방식의 "정확성"에 대해 이미 썼습니다. 동일한 매장에서 이미 수집한 누적 소비 가치를 사용하지 않은 이유는 명확하지 않습니다. 제 생각에는 철 조각 내부의 통합이 더 잘 작동할 것입니다.

비디오에서 일정 기간 동안 수동으로 소비를 계산하는 아이디어를 가져옵니다. 남자의 경우 오늘과 어제의 값만 고려하지만 더 나아가 그래프를 그려 보겠습니다. 필자의 경우 제안하는 방법의 본질은 다음과 같다.

현재 카운터 판독값을 쓸 변수 value_at_the_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

두 자동화 모두 다음 두 가지 작업을 수행합니다.

• 시작 값과 끝 값의 차이로 간격당 값을 계산합니다.
• 다음 간격의 기준 값 업데이트

이 경우 그래프 구성은 일반적인 히스토리 그래프로 해결됩니다.

      - 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개의 항목이 있습니다.

불행히도 이것은 여전히 ​​성장하는 기반의 일반적인 문제를 해결하지 못합니다. 월간 소비량 그래프를 원한다면 최소 200년 동안 데이터를 저장해야 합니다. 그리고 홈 어시스턴트는 전체 데이터베이스에 대해 하나의 저장 기간 설정만 제공하므로 시스템의 모든 데이터는 200000년 동안 저장되어야 합니다. 예를 들어, 저는 XNUMX년에 XNUMX입방미터의 물을 소비합니다. 이는 데이터베이스에 XNUMX개의 항목이 있음을 의미합니다. 그리고 다른 센서를 고려하면 그 수치는 일반적으로 음란해집니다.

접근법 3

다행히 똑똑한 사람들은 이미 InfluxDB 데이터베이스를 작성하여 이 문제를 해결했습니다. 이 데이터베이스는 시간 기반 데이터를 저장하는 데 특별히 최적화되어 있으며 다양한 센서의 값을 저장하는 데 이상적입니다. 이 시스템은 또한 데이터베이스에서 값을 추출한 다음 다양한 방법으로 집계할 수 있는 SQL과 같은 쿼리 언어를 제공합니다. 마지막으로, 서로 다른 데이터를 서로 다른 시간에 저장할 수 있습니다. 예를 들어, 온도나 습도와 같이 자주 변하는 판독값은 단 XNUMX주 동안만 저장할 수 있는 반면 물 소비량의 일일 판독값은 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년 동안, 월별 데이터는 절대 삭제되지 않았으면 합니다. 적절한 보존 정책을 만들 것입니다.

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

이제 사실 주요 트릭은 연속 쿼리를 사용한 데이터 집계입니다. 이는 지정된 간격으로 쿼리를 자동으로 시작하고 이 쿼리에 대한 데이터를 집계하고 결과를 새 값에 추가하는 메커니즘입니다. 예를 들어보자(가독성을 위해 칼럼에 적었지만 실제로는 이 명령어를 한 줄에 입력해야 했다)

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라는 연속 쿼리를 생성합니다.
• 쿼리는 매시간(time(1h)) 실행됩니다.
• 쿼리는 냉수 및 온수 판독값을 포함하여 measurement'a homeassistant.autogen.l(리터)에서 모든 데이터를 가져옵니다.
• 집계된 데이터는 entity_id로 그룹화되어 냉수 및 온수에 대해 별도의 값을 생성합니다.
• 리터 카운터는 매 시간마다 단조롭게 증가하는 시퀀스이므로 최대값을 취해야 하므로 집계는 max(value) 함수로 수행됩니다.
• 새 값은 homeassistant.month.water_meter_hour에 기록됩니다. 여기서 Month는 보존 기간이 XNUMX개월인 보존 정책의 이름입니다. 또한 냉수 및 온수에 대한 데이터는 값 필드의 해당 엔터티_id 및 값을 사용하여 별도의 레코드로 분산됩니다.

밤이나 집에 사람이 없을 때는 물 소비가 없으므로 homeassistant.autogen.l에도 새로운 기록이 없습니다. 일반 쿼리에서 값이 누락되지 않도록 하려면 fill(이전)을 사용할 수 있습니다. 이렇게 하면 InfluxDB가 지난 시간 값을 사용하게 됩니다.

안타깝게도 연속 쿼리에는 특이점이 있습니다. 채우기(이전) 트릭이 작동하지 않고 레코드가 생성되지 않습니다. 게다가 이것은 일종의 극복할 수 없는 문제입니다. 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시 사이에는 단순히 레코드가 없다는 점에 유의하십시오. 이것이 바로 연속 쿼리의 특징입니다.

보시다시피 집계된 값도 단조롭게 증가하는 시퀀스이며 항목만 빈도가 낮습니다(한 시간에 한 번). 그러나 이것은 문제가 되지 않습니다. 차트에 대한 올바른 데이터를 추출하는 다른 쿼리를 작성할 수 있습니다.

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 데이터베이스에서 지난 날(time >= now() -24h)의 entity_id='water_meter_cold' 데이터를 가져옵니다.
• 앞서 언급했듯이 homeassistant.month.water_meter_hour 시퀀스에서 일부 항목이 누락되었을 수 있습니다. GROUP BY 시간(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를 열고 일부 기존(또는 새 대시보드 생성) 대시보드를 열고 새 패널을 생성합니다. 차트 설정은 다음과 같습니다.

같은 그래프에 냉온수 데이터를 표시하겠습니다. 요청은 위에서 설명한 것과 정확히 동일합니다.

표시 매개변수는 다음과 같이 설정됩니다. 나에게 그것은 계단(계단)으로 가는 선(선)이 있는 그래프가 될 것입니다. 스택 매개변수는 아래에서 설명합니다. 아래에 몇 가지 표시 옵션이 더 있지만 그다지 흥미롭지는 않습니다.

결과 그래프를 홈 어시스턴트에 추가하려면 다음을 수행해야 합니다.

• 차트 편집 모드를 종료합니다. 어떤 이유로 올바른 차트 공유 설정은 대시보드 페이지에서만 제공됩니다.
• 차트 이름 옆에 있는 삼각형을 클릭하고 메뉴에서 공유를 선택합니다.
• 열리는 창에서 퍼가기 탭으로 이동합니다.
• 현재 시간 범위 선택 취소 - 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일 동안 뜨거운 물을 사용하지 않아 찬물 그래프만 그려집니다.

나는 내가 가장 좋아하는 차트, 스텝 라인 또는 실제 막대를 스스로 결정하지 않았습니다. 따라서 나는 단순히 일일 소비 일정의 예를 제시할 것입니다. 이번에는 바로 바입니다. 쿼리는 위에서 설명한 것과 같은 방식으로 작성됩니다. 표시 옵션은 다음과 같습니다.

이 차트는 다음과 같습니다.

따라서 Stack 매개 변수에 대해. 이 그래프에서는 냉수 막대가 뜨거운 막대 위에 그려져 있습니다. 총 높이는 해당 기간 동안 냉수 및 온수의 총 소비량에 해당합니다.

표시된 모든 그래프는 동적입니다. 관심 지점 위로 마우스를 이동하면 특정 지점의 세부 정보와 값을 볼 수 있습니다.

불행히도 연고에는 파리 두 마리가있었습니다. 막대 차트에서는(계단선이 있는 차트와 달리) 막대의 중앙이 정중앙에 있지 않고 00:00에 있습니다. 저것들. 열의 왼쪽 절반이 전날 대신 그려집니다. 따라서 토요일과 일요일에 대한 그래프는 푸른색 영역의 약간 왼쪽에 그려집니다. 내가 그것을 이길 방법을 알아낼 때까지.

또 다른 문제는 매월 간격으로 올바르게 작동하지 않는다는 것입니다. 사실은 시간/일/주의 길이는 고정되어 있지만 한 달의 길이는 매번 다릅니다. InfluxDB는 동일한 간격으로만 작동할 수 있습니다. 지금까지 내 두뇌는 30일이라는 고정된 간격을 설정하기에 충분했습니다. 예, 차트는 XNUMX년 동안 약간 떠다니며 막대는 월과 정확히 일치하지 않습니다. 그러나 이것은 디스플레이 미터로서 나에게 흥미롭기 때문에 이것으로 괜찮습니다.

적어도 두 가지 해결책이 있습니다.

• 월간 차트에서 점수를 매기고 자신을 주간 차트로 제한합니다. 52년에 XNUMX개의 위클리 바가 꽤 괜찮아 보입니다.
• 월간 소비량 자체를 방법 2번으로 생각하시고, 그라파나는 아름다운 그래프만을 위해 사용하세요. 꽤 정확한 해결책입니다. 비교를 위해 지난 해의 차트를 오버레이할 수도 있습니다. grafana는 그렇게 할 수 있습니다.

결론

이유는 모르겠지만 이런 종류의 차트를 좋아합니다. 그들은 인생이 한창이고 모든 것이 변하고 있음을 보여줍니다. 어제는 많았고 오늘은 적었고 내일은 다른 것이 있을 것입니다. 소비 주제에 대해 가정과 협력하는 것이 남아 있습니다. 그러나 현재의 식욕에도 불구하고 법안의 크고 이해할 수없는 수치는 이미 상당히 이해할 수있는 소비 그림으로 바뀌고 있습니다.

거의 20년의 프로그래머 경력에도 불구하고 나는 사실상 데이터베이스와 교차하지 않았습니다. 따라서 외부 데이터베이스를 설치하는 것은 너무 난해하고 이해할 수 없는 일처럼 보였습니다. 모든 게 바뀌었다 위의 기사 -적절한 도구를 조이는 것이 몇 번의 클릭만으로 이루어지며 특수 도구를 사용하면 플로팅 작업이 조금 더 쉬워집니다.

제목에서 전기 사용량에 대해 언급했습니다. 안타깝게도 현재 그래프를 제공할 수 없습니다. 하나의 SDM120 미터가 작동하지 않고 다른 하나는 Modbus를 통해 액세스할 때 버그가 있습니다. 그러나 이것은 이 기사의 주제에 어떤 식으로든 영향을 미치지 않습니다. 그래프는 물과 같은 방식으로 작성됩니다.

이 기사에서는 내가 직접 시도한 접근 방식을 제공했습니다. 확실히 내가 모르는 데이터 수집 및 시각화를 구성하는 다른 방법이 있습니다. 의견에 대해 알려주십시오. 매우 관심이 있습니다. 나는 건설적인 비판과 새로운 아이디어에 기뻐할 것입니다. 위의 자료가 누군가에게 도움이 되었으면 합니다.

출처 : habr.com