Паметна кућа: У Хоме Ассистант-у правимо графиконе потрошње воде и електричне енергије

Сваки пут када добијем уплату за струју и воду, изненадим се – да ли моја породица заиста толико троши? Па, да, купатило има грејани под и бојлер, али они не пале ватру стално. Чини се и да штедимо воду (иако волимо и да се прскамо по купатилу). Пре неколико година већ сам прикључени водомери и струја у паметну кућу, али ту су ствари запеле. Тек смо сада дошли до анализе потрошње, о чему је заправо овај чланак.

Недавно сам прешао на Хоме Ассистант као свој систем паметне куће. Један од разлога је управо била могућност да се организује прикупљање велике количине података са могућношћу погодног конструисања различитих типова графикона.

Информације описане у овом чланку нису нове, све ове ствари под различитим сосовима су већ описане на Интернету. Али сваки чланак обично описује само један приступ или аспект. Морао сам да упоредим све ове приступе и сам изаберем најприкладнији. Чланак још увек не пружа свеобухватне информације о прикупљању података, већ је нека врста резимеа како сам то урадио. Дакле, конструктивна критика и предлози за побољшање су добродошли.

Проблем статемент

Дакле, циљ данашње вежбе је да добијете лепе графиконе потрошње воде и струје:

• На сат 2 дана
• Дневно током 2 недеље
• (опционо) недељно и месечно

Постоје неке потешкоће са овим:

• Стандардне компоненте графикона су обично прилично лоше. У најбољем случају, можете да направите линијски графикон тачку по тачку.

  Ако погледате довољно добро, можете пронаћи компоненте треће стране које проширују могућности стандардног графикона. За кућног помоћника, у принципу, ово је добра и лепа компонента мини-графска картица, али је такође донекле ограничен:

  • Тешко је подесити параметре тракастог графикона у великим интервалима (ширина траке се поставља у деловима сата, што значи да ће интервали дужи од једног сата бити подешени у разломцима)
  • Не можете додати различите ентитете на један графикон (на пример, температуру и влажност, или комбиновати тракасти графикон са линијом)
• Не само да кућни асистент подразумевано користи најпримитивнију СКЛите базу података (а ја, мајстор, нисам могао да се носим са инсталирањем МиСКЛ-а или Постгреса), већ се подаци не чувају на најоптималнији начин. Тако, на пример, сваки пут када промените чак и најмањи дигитални параметар параметра, огроман јсон величине око килобајта се уписује у базу података

  {"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}}}

  Имам доста сензора (сензори температуре у свакој просторији, бројила за воду и струју), а неки такође генеришу доста података. На пример, само струјомер СДМ220 генерише десетак вредности сваких 10-15 секунди, а ја бих желео да инсталирам око 8 таквих бројила. То. све ове вредности могу лако надувати базу података за 100-200 МБ дневно. За недељу дана систем ће се једва померити, а за месец дана флеш диск ће умрети (у случају типичне инсталације кућног помоћника на Распберри ПИ), а чување података током целе године не долази у обзир.

• Ако имате среће, ваш мерач може сам да рачуна потрошњу. У сваком тренутку можете се обратити на бројило и питати колико је сати акумулирана вредност потрошње. По правилу, сва бројила електричне енергије која имају дигитални интерфејс (РС232/РС485/Модбус/Зигбее) пружају ову могућност.

  Још је горе ако уређај може једноставно да измери неки тренутни параметар (на пример, тренутну снагу или струју) или једноставно генерише импулсе сваких Кс ват-часова или литара. Затим треба да размислите како и са чиме да га интегришете и где да акумулирате вредност. Постоји ризик да из било ког разлога пропустите следећи извештај, а тачност система у целини поставља питања. Све ово можете, наравно, поверити систему паметне куће као што је кућни помоћник, али нико није поништио тачку о броју записа у бази и сензоре неће бити могуће испитивати више од једном у секунди (а ограничење архитектуре кућног помоћника).

Приступ 1

Прво, да видимо шта кућни асистент нуди из кутије. Мерење потрошње током одређеног периода је веома тражена функционалност. Наравно, давно је имплементиран у виду специјализоване компоненте - утилити_метер.

Суштина компоненте је да интерно креира променљиву цуррент_аццумулатед_валуе и ресетује је након одређеног периода (сат/седмица/месец). Сама компонента прати улазну променљиву (вредност неког сензора), претплаћује се на промене вредности - само добијате готов резултат. Ова ствар је описана у само неколико редова у конфигурационој датотеци

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

Овде сензор.ватер_метер_цолд је тренутна вредност мерача у литрима коју добијам директно из комада гвожђа би мктт. Дизајн креира 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

Заправо, проблем са овим приступом лежи у овом алгоритму. Као што сам већ поменуо, за сваку улазну вредност (тренутно очитавање бројила за сваки следећи литар) 1кб записа се генерише у бази података. Сваки бројило такође генерише нову вредност, која се такође додаје бази. Ако желим да прикупим сатна/дневна/недељна/месечна очитавања, и за неколико водостаја, и да додам пакет електричних бројила, то ће бити много података. Па, тачније, нема пуно података, али пошто кућни помоћник уписује гомилу непотребних информација у базу података, величина базе ће расти скоковима и границама. Плашим се чак ни да проценим величину базе за недељне и месечне графиконе.

Поред тога, мерач комуналних услуга сам по себи не решава проблем. Графикон вредности које производи мерач је монотоно растућа функција која се сваког сата враћа на 0. Потребан нам је графикон потрошње који је разумљив кориснику, који показује колико је литара потрошено током периода. Стандардна компонента графикона историје то не може да уради, али спољна компонента мини графичке картице може да нам помогне.

Ово је код картице за ловелаце-УИ:

      - 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 подешавања:

• гроуп_би:хоур — графикон ће бити генерисан са тракама поравнатим са почетком сата
• поена_по_сату: 1 - једна трака за сваки сат
• И што је најважније, аггрегате_фунц: мак - узмите максималну вредност у току сваког сата. Управо овај параметар претвара график тестера у шипке

Не обраћајте пажњу на ред колона са леве стране - ово је стандардно понашање компоненте ако нема података. Али није било података - само сам укључио прикупљање података о комуналним бројилима пре неколико сати само због овог чланка (описаћу свој тренутни приступ у наставку).

На овој слици сам желео да покажем да понекад приказ података чак функционише и да траке заправо одражавају тачне вредности. Али то није све. Из неког разлога, изабрана колона за период од 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'

Имајте на уму да је параметар гроуп_би подешен на интервал, а параметар поинт_пер_хоур управља свиме. И ту лежи још један проблем са овом компонентом - поинт_пер_хоур добро ради на графиконима од сат времена или мање, али је лош у већим интервалима. Дакле, да бих добио једну колону у једном дану, морао сам да унесем вредност 1/24=0.04166666. О недељним и месечним графиконима чак и не говорим.

Приступ 2

Док сам још увек разумео помоћника у кући, наишао сам на овај видео:

Пријатељ прикупља податке о потрошњи са неколико типова Ксиаоми утичница. Његов задатак је мало једноставнији - једноставно приказати вредност потрошње за данас, јуче и за месец. Нису потребни распореди.

Оставимо по страни дискусије о ручној интеграцији тренутних вредности снаге - већ сам писао изнад о „тачности“ овог приступа. Није јасно зашто није искористио акумулиране вредности потрошње које већ прикупља иста продавница. По мом мишљењу, интеграција унутар хардвера ће радити боље.

Из видеа ћемо преузети идеју о ручном бројању потрошње током одређеног периода. Момак броји само вредности за данас и јуче, али ми ћемо ићи даље и покушати да нацртамо графикон. Суштина предложене методе у мом случају је следећа.

Хајде да креирамо променљиву валуе_ат_тхе_беиннинг_оф_хоур, у коју ћемо снимити тренутна очитавања бројила
Користећи тајмер, на крају сата (или на почетку следећег) израчунавамо разлику између тренутног очитавања и оног сачуваног на почетку сата. Ова разлика ће бити потрошња за текући сат - вредност ћемо сачувати у сензор, а у будућности ћемо градити графикон на основу ове вредности.
Такође морате да „ресетујете“ променљиву валуе_ат_бегиннинг_оф_хоур тако што ћете тамо уписати тренутну вредност бројача.

Све ово се може урадити преко самог кућног помоћника.

Мораћете да напишете мало више кода него у претходном приступу. Прво, направимо ове исте „варијабле“. Изван кутије немамо „променљиви“ ентитет, али можемо да користимо услуге мктт брокера. Тамо ћемо послати вредности са заставицом ретаин=труе - ово ће сачувати вредност унутар брокера и може се извући одатле у било ком тренутку, чак и када се кућни помоћник поново покрене. Направио сам сатне и дневне бројаче одједном.

- 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 уноса у базу података. А ако узмете у обзир друге сензоре, онда цифра постаје генерално непристојна.

Приступ 3

Срећом, паметни људи су већ решили овај проблем писањем ИнфлукДБ базе података. Ова база података је посебно оптимизована за складиштење података заснованих на времену и идеална је за чување вредности различитих сензора. Систем такође обезбеђује језик упита сличан СКЛ-у који вам омогућава да извучете вредности из базе података и затим их агрегирате на различите начине. Коначно, различити подаци се могу чувати за различита времена. На пример, очитавања која се често мењају као што су температура или влажност могу се чувати само неколико недеља, док се дневна очитавања потрошње воде могу чувати током целе године.

Осим ИнфлукДБ-а, паметни људи су измислили и Графану, систем за цртање графикона на основу података из ИнфлукДБ-а. Графана може да нацрта различите типове графикона, да их детаљно прилагоди, и, што је најважније, ови графикони се могу „прикључити“ на кућни помоћник ловелаце-УИ.

Добити инспирацију овде и овде. Чланци детаљно описују процес инсталирања и повезивања ИнфлукДБ и Графана са кућним помоћником. Фокусираћу се на решавање свог специфичног проблема.

Дакле, пре свега, почнимо са додавањем вредности бројача у инфлукДБ. Комад конфигурације кућног помоћника (у овом примеру ћу се забављати не само хладном, већ и топлом водом):

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

Идемо сада на ИнфлукДБ конзолу и конфигуришемо нашу базу података. Конкретно, потребно је да конфигуришете колико дуго ће се одређени подаци чувати. Ово је регулисано тзв. политика задржавања – ово је слично базама података унутар главне базе података, при чему свака интерна база података има своја подешавања. Подразумевано, сви подаци се чувају у политици задржавања која се зове аутоген; Желео бих да се подаци по сату чувају месец дана, да се недељни чувају годину дана, а да се месечни никада не бришу. Хајде да креирамо одговарајућу политику задржавања

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

Ова команда:

• Креира континуирани упит под називом цк_ватер_цолд_хоурли у бази података хомеассистант
• Захтев ће се извршавати сваког сата (време (1х))
• Захтев ће састругати све податке са мерења хомеассистант.аутоген.л (литара), укључујући очитавања хладне и топле воде
• Збирни подаци ће бити груписани према ентити_ид, што ће нам дати одвојене вредности за хладну и топлу воду
• Пошто је бројач литара монотоно растући низ у току сваког сата, биће потребно узети максималну вредност, па ће се агрегација вршити помоћу функције мак(вредност)
• Нова вредност ће бити уписана у хомеассистант.монтх.ватер_метер_хоур, где је месец назив политике задржавања са периодом задржавања од једног месеца. Штавише, подаци о хладној и топлој води ће бити разбацани у посебне записе са одговарајућим ентити_ид и вредношћу у пољу вредности

Ноћу или када никога нема код куће, нема потрошње воде, па стога нема нових уноса у хомеассистант.аутоген.л. Да бисте избегли да недостају вредности у редовним упитима, можете користити филл(превиоус). Ово ће приморати ИнфлукДБ да користи вредност последњег сата.

Нажалост, континуирани упит има посебност: трик попуњавања (претходног) не ради и записи се једноставно не креирају. Штавише, ово је нека врста непремостивог проблема који расправља се већ неколико година. Касније ћемо се позабавити овим проблемом, али нека филл(превиоус) буде у континуираном упиту - то не омета.

Хајде да проверимо шта се десило (наравно, треба сачекати пар сати):

> 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

Имајте на уму да се вредности у бази података чувају у УТЦ-у, тако да се ова листа разликује за 3 сата - вредности од 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)

ја ћу дешифровати:

• Из базе података хомеассистант.монтх.ватер_метер_хоур издвојићемо податке за ентити_ид='ватер_метер_цолд' за последњи дан (време >= сада() -24х).
• Као што сам већ поменуо, неки уноси можда недостају у низу хомеассистант.монтх.ватер_метер_хоур. Ове податке ћемо поново генерисати покретањем упита са ГРОУП БИ тиме(1х). Овог пута попуњавање (претходно) ће радити како се очекује, генеришући податке који недостају (функција ће узети претходну вредност)
• Најважнија ствар у овом захтеву је функција разлике, која ће израчунати разлику између сати. Не ради самостално и захтева функцију агрегације. Нека ово буде мак() који је раније коришћен.

Резултат извршења изгледа овако

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 ујутру (УТЦ) није било потрошње. Ипак, упит ће вратити исту вредност потрошње захваљујући филл(превиоус), а функција разлике ће одузети ову вредност од себе и излаз ће бити 0, што је управо оно што је потребно.

Остаје само да се направи графикон. Да бисте то урадили, отворите Графану, отворите неку постојећу (или направите нову) контролну таблу и направите нови панел. Подешавања графикона ће бити оваква.

Приказаћу податке о хладној и топлој води на истом графикону. Захтев је потпуно исти као што сам горе описао.

Параметри приказа су подешени на следећи начин. За мене ће то бити график са линијама, који иде у корацима (степеницама). У наставку ћу објаснити параметар стека. Постоји још неколико опција приказа испод, али оне нису толико занимљиве.

Да бисте резултујућу табелу додали кућном помоћнику, потребно је да:

• изађите из режима за уређивање графикона. Из неког разлога, исправна подешавања дељења графикона се нуде само на страници контролне табле
• Кликните на троугао поред назива графикона и изаберите дељење из менија
• У прозору који се отвори идите на картицу за уграђивање
• Поништите избор тренутног временског опсега - временски опсег ћемо поставити преко УРЛ-а
• Изаберите потребну тему. У мом случају је светло
• Копирајте добијену УРЛ адресу на картицу подешавања ловелаце-УИ

      - 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 дана, тако да је нацртан само графикон хладне воде.

Још увек нисам одлучио за себе који графикон ми се више допада, линијски корак или праве траке. Стога ћу једноставно дати пример дневног графикона потрошње, само овога пута у шипкама. Упити се конструишу слично онима описаним горе. Опције приказа су:

Овај графикон изгледа овако:

Дакле, о параметру Стацк. На овом графикону, стуб хладне воде је нацртан на врху стуба топле воде. Укупна висина одговара укупној потрошњи хладне и топле воде за период.

Сви приказани графикони су динамички. Можете да поставите показивач миша преко тачке интересовања и видите детаље и вредност на одређеном месту.

Нажалост, било је неколико мува у масти. На тракастом графикону (за разлику од графикона са степенастим линијама), средина траке није усред дана, већ у 00:00. Оне. лева половина колоне је нацртана на месту претходног дана. Дакле, графикони за суботу и недељу су нацртани благо лево од плавичасте зоне. Док нисам схватио како да га победим.

Други проблем је немогућност правилног рада у месечним интервалима. Чињеница је да је дужина сата/дана/недеље фиксна, али је дужина месеца сваки пут другачија. ИнфлукДБ може да ради само у једнаким интервалима. До сада је мој мозак био довољан да поставим фиксни интервал од 30 дана. Да, графикон ће мало плутати током целе године и траке неће тачно одговарати месецима. Али пошто ме ова ствар занима само као мерач приказа, слажем се са тим.

Видим најмање два решења:

• Одустаните од месечних графикона и ограничите се на недељне. 52 недељна трака за годину изгледају прилично добро
• Сматрајте саму месечну потрошњу методом бр. 2 и користите графану само за лепе графиконе. Биће то сасвим тачно решење. Можете чак и преклапати графиконе за прошлу годину ради поређења - графана такође то може.

Закључак

Не знам зашто, али ја сам опседнут оваквим графиконима. Они показују да је живот у пуном јеку и да се све мења. Јуче је било много, данас мало, сутра ће бити нешто друго. Остаје само да се ради са укућанима на тему потрошње. Али и са тренутним апетитима, само велика и неразумљива цифра на уплатници већ се претвара у прилично разумљиву слику потрошње.

Упркос мојој скоро 20-годишњој каријери програмера, нисам имао практично никакав контакт са базама података. Стога је инсталирање екстерне базе података изгледало као нешто тако нејасно и несхватљиво. Променио све изнад чланка — показало се да се причвршћивање одговарајућег алата врши у пар кликова, а уз помоћ специјализованог алата задатак исцртавања графикона постаје мало лакши.

У наслову сам поменуо потрошњу електричне енергије. Нажалост, у овом тренутку не могу дати никакве графиконе. Један мерач СДМ120 ми је умро, а други је квар када се приступа преко Модбус-а. Међутим, то ни на који начин не утиче на тему овог чланка - графови ће бити конструисани на исти начин као и за воду.

У овом чланку сам представио приступе које сам и сам испробао. Сигурно постоје неки други начини за организовање прикупљања података и визуелизације за које ја не знам. Реците ми о томе у коментарима, биће ме веома заинтересовано. Биће ми драго конструктивној критици и новим идејама. Надам се да ће и представљени материјал некоме помоћи.

Извор: ввв.хабр.цом