Интелигентен дом: Графика на потреблението на вода и електричество в Home Assistant

Всеки път, когато получа плащане за ток и вода, се чудя - наистина ли семейството ми консумира толкова много? Е, да, има топъл под и бойлер в банята, но те не работят като пожарникари през цялото време. Изглежда също пестим вода (въпреки че обичаме да пръскаме и в банята). Преди няколко години аз вече свързани водомери и електричество към интелигентен дом, но тук нещата зациклиха. Ръцете стигнаха до анализа на потреблението едва сега, за което всъщност е тази статия.

Наскоро преминах към Home Assistant като моя система за интелигентен дом. Една от причините беше просто способността да се организира събирането на голямо количество данни с възможност за удобно изграждане на различни видове графики.

Информацията, описана в тази статия, не е нова, всички тези неща под различни сосове вече са описани в интернет. Но всяка статия, като правило, описва само един подход или аспект. Трябваше да сравня всички тези подходи и сам да избера най-подходящия. Статията все още не предоставя изчерпателна информация за събирането на данни, но е един вид обобщение на това как го направих. Така че градивната критика и предложенията за подобрение са добре дошли.

Проблем изявление

И така, целта на днешното упражнение е да получим красиви графики на потреблението на вода и електричество:

• Почасово в продължение на 2 дни
• Ежедневно в продължение на 2 седмици
• (по избор) седмично и месечно

Има някои трудности в това:

• Стандартните компоненти на диаграмата обикновено са доста бедни. В най-добрия случай можете да изградите линейна графика по точки.

  Ако търсите добре, можете да намерите компоненти на трети страни, които разширяват възможностите на стандартната диаграма. За домашен асистент по принцип е добър и красив компонент мини графична карта, но също така е донякъде ограничено:

  • Трудно е да се зададат параметрите на лентовата диаграма на големи интервали (ширината на лентата е зададена в части от час, което означава, че интервали, по-дълги от един час, ще бъдат зададени в дробни числа)
  • Не можете да добавяте различни обекти към една графика (например температура и влажност или да комбинирате лентова графика с линия)
• Домашният асистент не само използва най-примитивната база данни SQLite по подразбиране (и аз, майсторът, не усвоих инсталирането на MySQL или Postgres), данните не се съхраняват по най-оптималния начин. Така, например, с всяка промяна на всеки дори най-малък цифров параметър на параметър, огромен 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 MB дневно. След седмица системата едва ще се върти и след месец флаш устройството ще умре (в случай на типична инсталация на домашен асистент на малина PI) и не може да се говори за съхранение на данни за цяла година .

• Ако имате късмет, вашият измервателен уред може сам да отчита потреблението. Можете да се свържете с измервателния уред по всяко време и да попитате колко часа е стойността на натрупаната консумация. По правило всички електромери, които имат цифров интерфейс (RS232/RS485/Modbus/Zigbee), предоставят такава възможност.

  По-лошо е, ако устройството може просто да измерва някакъв моментен параметър (например моментна мощност или ток) или просто да генерира импулси на всеки X ватчаса или литри. След това трябва да помислите как и с какво да го интегрирате и къде да акумулирате стойност. Има риск да пропуснете следващия отчет по някаква причина, а точността на системата като цяло поражда въпроси. Можете, разбира се, да поверите всичко това на интелигентна домашна система като домашен асистент, но никой не е отменил точката за броя на записите в базата данни и сензорите за анкетиране повече от веднъж в секунда няма да работят (ограничение на архитектура на домашен асистент).

Подход 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 на всеки час. Нуждаем се и от удобен за потребителя график за консумация, колко литра са изядени през периода. Стандартният компонент за графика на историята не прави това, но компонентът за външна миниграфична карта може да ни помогне.

Това е кодът на картата за 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 - диаграмата ще се генерира с колони, подравнени към началото на часа
• точки_на_час: 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. Не говоря за седмични и месечни графики.

Подход 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

И двете автоматизации правят 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 влизания на ден за часовата графика.

За съжаление, това все още не решава общия проблем с нарастващата база. Ако искам графика на месечното потребление, ще трябва да съхранявам данни поне за една година. И тъй като домашният асистент предоставя само една настройка за продължителност на съхранение за цялата база данни, това означава, че ВСИЧКИ данни в системата ще трябва да се съхраняват цяла година. Например за една година изразходвам 200 кубика вода, което означава 200000 XNUMX записа в базата данни. И ако вземете предвид други сензори, тогава цифрата става като цяло неприлична.

Подход 3

За щастие умните хора вече са решили този проблем, като са написали базата данни InfluxDB. Тази база данни е специално оптимизирана за съхраняване на данни, базирани на времето, и е идеална за съхраняване на стойности на различни сензори. Системата също така предоставя SQL-подобен език за заявки, който ви позволява да извличате стойности от базата данни и след това да ги агрегирате по различни начини. И накрая, различни данни могат да се съхраняват за различно време. Например, често променящите се показания като температура или влажност могат да се съхраняват само за няколко седмици, докато ежедневните показания за потреблението на вода могат да се съхраняват за цяла година.

Освен InfluxDB, умните хора изобретиха и Grafana, система за чертане на графики от данни от InfluxDB. 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, тези данни ще се съхраняват за една седмица. Бих искал почасовите данни да се съхраняват за един месец, седмичните данни за една година и месечните данни изобщо да не се изтриват. Ние ще създадем подходящи политики за задържане

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

Тази команда:

• Създава непрекъсната заявка с име cq_water_cold_hourly в базата данни на homeassistant
• Заявката ще се изпълнява на всеки час (време (1 час))
• Заявката ще извади всички данни от measurement'a homeassistant.autogen.l (литри), включително показания за студена и топла вода
• Обобщените данни ще бъдат групирани по entity_id, което ще създаде отделни стойности за студена и топла вода.
• Тъй като броячът на литри е монотонно нарастваща последователност в рамките на всеки час, ще трябва да вземете максималната стойност, така че агрегирането ще се извърши от функцията max(value)
• Новата стойност ще бъде записана в homeassistant.month.water_meter_hour, където month е името на политиката за задържане с период на задържане от един месец. Освен това данните за студена и топла вода ще бъдат разпръснати в отделни записи със съответния entity_id и стойността в полето стойност

През нощта или когато няма никой вкъщи, няма консумация на вода и съответно няма нови записи в homeassistant.autogen.l. За да избегнете липсващи стойности в нормални заявки, можете да използвате fill(previous). Това ще принуди InfluxDB да използва стойността на последния час.

За съжаление, непрекъснатото запитване има една особеност: трикът за попълване (предишно) не работи и записите просто не се създават. Освен това това е някакъв непреодолим проблем, който се обсъжда повече от година. Ще се справим с този проблем по-късно и нека fill(previous) in continuous query бъде там - това не пречи.

Нека проверим какво се е случило (разбира се, трябва да изчакате няколко часа):

> 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 часа - стойностите от 7 сутринта в изхода на InfluxDB съответстват на стойностите от 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 ще изтеглим данни за entity_id='water_meter_cold' за последния ден (време >= сега() -24 часа).
• Както споменах, някои записи може да липсват в последователността homeassistant.month.water_meter_hour. Ще генерираме повторно тези данни, като изпълним заявката с ГРУПИРАНЕ ПО време (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 дни, така че се чертае само графика на студената вода.

Не съм решил за себе си коя диаграма ми харесва най-много, стъпкова линия или истински ленти. Затова просто ще дам пример за график за дневна консумация, само че този път на барове. Заявките се изграждат по същия начин, както е описано по-горе. Опциите за показване са:

Тази диаграма изглежда така:

И така, относно параметъра Stack. В тази графика лента със студена вода е начертана върху лента с гореща вода. Общата височина съответства на общата консумация на студена и топла вода за периода.

Всички показани графики са динамични. Можете да преместите мишката върху точката на интерес и да видите подробностите и стойността в конкретна точка.

За съжаление, не мина без няколко мухи в мехлема. На стълбовидна диаграма (за разлика от графиката със стъпаловидни линии) средата на лентата не е в средата на деня, а в 00:00 часа. Тези. лявата половина на лентата е начертана на мястото на предишния ден. Така че графиките за събота и неделя са нарисувани малко вляво от синкавата зона. Докато не разбрах как да го спечеля.

Друг проблем е невъзможността за коректна работа с месечни интервали. Факт е, че продължителността на часа / деня / седмицата е фиксирана, но продължителността на месеца е различна всеки път. InfluxDB може да работи само с равни интервали. Досега мозъкът ми беше достатъчен, за да задам фиксиран интервал от 30 дни. Да, графиката ще плава малко през годината и стълбовете няма да съответстват точно на месеците. Но тъй като това нещо ми е интересно само като дисплей, аз съм ок с това.

Виждам поне две решения:

• За да постигнете резултати в месечните класации и да се ограничите до седмичните. 52 седмични ленти за една година изглеждат доста добре
• Приемете самата месечна консумация като метод № 2 и използвайте графана само за красиви графики. Това е доста точно решение. Можете дори да наслагвате диаграми за изминалата година за сравнение - grafana може да направи това.

Заключение

Не знам защо, но обичам тези класации. Те показват, че животът кипи и всичко се променя. Вчера беше много, днес е малко, утре ще има нещо друго. Остава да се работи с домакинствата по темата потребление. Но дори и при сегашните апетити, само една голяма и неразбираема цифра в сметката вече се превръща в доста разбираема картина на потреблението.

Въпреки моята почти 20-годишна кариера като програмист, аз практически не съм се пресичал с бази данни. Следователно инсталирането на външна база данни изглеждаше като нещо толкова неясно и неразбираемо. Всичко се е променило горната статия - оказа се, че завинтването на подходящ инструмент става с няколко щраквания, а със специализиран инструмент задачата за чертане става малко по-лесна.

В заглавието споменах консумация на електроенергия. За съжаление в момента не мога да дам никаква графика. Единият измервателен уред SDM120 е неработещ, а другият е с грешки при достъп чрез Modbus. Това обаче по никакъв начин не засяга темата на тази статия - графиките ще бъдат изградени по същия начин, както при водата.

В тази статия дадох онези подходи, които сам съм изпробвал. Със сигурност има някои други начини за организиране на събирането и визуализирането на данни, за които не знам. Разкажете ми за това в коментарите, ще ми бъде много интересно. Ще се радвам на градивна критика и нови идеи. Надявам се, че горният материал също ще помогне на някого.

Източник: www.habr.com