Í hvert skipti sem ég fæ greiðslu fyrir rafmagn og vatn velti ég því fyrir mér - eyðir fjölskyldan mín virkilega svooooo mikið? Jæja, já, það er upphitað gólf og ketill á baðherberginu, en þeir vinna ekki sem slökkviliðsmenn allan tímann. Við virðumst líka spara vatn (þó okkur finnst líka gaman að skvetta á baðherbergið). Fyrir nokkrum árum síðan ég þegar и að snjallheimili, en þetta er þar sem hlutirnir festust. Hendurnar eru komnar í greiningu á neyslu fyrst núna, sem er reyndar það sem þessi grein fjallar um.
Ég skipti nýlega yfir í Home Assistant sem snjallheimakerfið mitt. Ein af ástæðunum var bara hæfileikinn til að skipuleggja söfnun á miklu magni af gögnum með möguleika á þægilegri smíði ýmiss konar grafa.
Upplýsingarnar sem lýst er í þessari grein eru ekki nýjar, öllum þessum hlutum undir mismunandi sósum hefur þegar verið lýst á netinu. En hver grein lýsir að jafnaði aðeins einni nálgun eða þætti. Ég þurfti að bera saman allar þessar aðferðir og velja þá sem hentaði best sjálfur. Greinin veitir samt ekki tæmandi upplýsingar um gagnasöfnun heldur er hún nokkurs konar samantekt á því hvernig ég gerði það. Þannig að uppbyggileg gagnrýni og tillögur til úrbóta eru vel þegnar.
Samsetning vandans
Svo, markmið æfingarinnar í dag er að fá falleg línurit af vatns- og rafmagnsnotkun:
- Á klukkutíma fresti í 2 daga
- Daglega í 2 vikur
- (valfrjálst) vikulega og mánaðarlega
Það eru nokkrir erfiðleikar í þessu:
- Venjulegir töfluhlutar hafa tilhneigingu til að vera frekar lélegir. Í besta falli er hægt að byggja línurit eftir punktum.
Ef þú leitar vel geturðu fundið íhluti frá þriðja aðila sem auka möguleika staðlaða töflunnar. Fyrir heimili aðstoðarmaður, í grundvallaratriðum, góður og fallegur hluti , en það er líka nokkuð takmarkað:
- Erfitt er að stilla færibreytur súluritsins með miklu millibili (breidd súlu er stillt í klukkutímabrotum, sem þýðir að lengra bil en klukkutími verða sett í brotatölum)
- Þú getur ekki bætt mismunandi einingum við eitt línurit (til dæmis hitastig og rakastig, eða sameinað súlurit með línu)
- Heimilisaðstoðarmaðurinn notar ekki aðeins frumstæðasta SQLite gagnagrunninn sjálfgefið (og ég, handverksmaðurinn, náði ekki tökum á uppsetningu MySQL eða Postgres), gögnin eru ekki geymd á sem bestan hátt. Svo, til dæmis, með hverri breytingu á hverri jafnvel minnstu stafrænu færibreytu færibreytu, er risastórt json um kílóbæti að stærð skrifað í gagnagrunninn
{"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}}}Ég er með allmarga skynjara (hitaskynjara í hverju herbergi, vatns- og rafmagnsmælar) og sumir búa líka til talsvert mikið af gögnum. Til dæmis framleiðir aðeins SDM220 rafmagnsmælirinn um tugi gilda á 10-15 sekúndna fresti, og ég myndi vilja setja upp 8 slíka mæla. Og það er líka fullt af breytum sem eru reiknaðar út frá öðrum skynjurum. Það. öll þessi gildi geta auðveldlega blásið upp gagnagrunninn um 100-200 MB daglega. Eftir viku mun kerfið varla fara og snúast og eftir mánuð deyr flash-drifið (ef um er að ræða dæmigerða uppsetningu á heimilisaðstoðarmanni á raspberry PI) og það er ekki hægt að tala um að geyma gögn í heilt ár .
- Ef þú ert heppinn getur mælirinn sjálfur talið eyðslu. Hægt er að hafa samband við mælinn hvenær sem er og spyrja á hvaða tíma uppsafnað neyslugildi sé. Að jafnaði gefa allir rafmagnsmælar sem eru með stafrænu viðmóti (RS232/RS485/Modbus/Zigbee) slíkt tækifæri.
Það sem verra er, ef tækið getur einfaldlega mælt einhverja tafarlausa færibreytu (til dæmis samstundis afl eða straum), eða einfaldlega framleitt púls á X wattstundum eða lítra fresti. Síðan þarf að hugsa um hvernig og með hverju á að samþætta það og hvar á að safna verðmætum. Hætta er á að missa af næstu skýrslu af einhverjum ástæðum og nákvæmni kerfisins í heild vekur spurningar. Þú getur auðvitað falið þetta snjallheimakerfi eins og heimilisaðstoðarmann, en enginn hefur aflýst punktinum um fjölda færslna í gagnagrunninum og könnunarskynjarar oftar en einu sinni á sekúndu virka ekki (takmörkun á heimilisaðstoðararkitektúr).
Aðkoma 1
Fyrst skulum við sjá hvaða heimilisaðstoðarmaður er útvegaður úr kassanum. Mæling á neyslu yfir ákveðið tímabil er mjög eftirsótt virkni. Auðvitað var það innleitt fyrir löngu síðan sem sérhæfður hluti - utility_meter.
Kjarninn í íhlutnum er að hann byrjar núverandi_uppsafnað_gildi breytu inni og endurstillir hana eftir tiltekið tímabil (klukkutíma/viku/mánuður). Íhluturinn sjálfur fylgist með innkominni breytu (gildi einhvers konar skynjara), gerist áskrifandi að breytingum á gildinu sjálfu - þú færð bara fullunna niðurstöðu. Þessu atriði er lýst í örfáum línum í stillingarskránni
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Hér er sensor.water_meter_cold núverandi gildi mælisins í lítrum sem ég fæ eftir mqtt. Hönnunin býr til 2 nýja skynjara water_cold_hour_um og water_cold_day_um, sem safna klukkutíma og daglegum aflesturum og núllstilla þá eftir tímabil. Hér er línurit af klukkutíma rafhlöðu í hálfan dag.
Klukkutímabundinn og daglegur grafkóði fyrir lovelace-UI lítur svona út:
- 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
Reyndar, í þessari reiknirit liggur vandamálið við þessa nálgun. Eins og ég hef áður nefnt, fyrir hvert móttekið gildi (núverandi mælalestur fyrir hvern næsta lítra), myndast 1kb af skrá í gagnagrunninum. Hver veitumælir býr einnig til nýtt gildi, sem einnig bætist við grunninn. Ef ég vil safna klukkutíma/daglega/vikulegu/mánaðarlega aflestri, já, fyrir nokkur vatnsstig, og jafnvel bæta við pakka af rafmagnsmælum, þá verður þetta mikið af gögnum. Jæja, nánar tiltekið, það er ekki mikið af gögnum, en þar sem heimilisaðstoðarmaðurinn skrifar fullt af óþarfa upplýsingum í gagnagrunninn mun stærð gagnagrunnsins vaxa stórum skrefum. Ég er jafnvel hræddur við að áætla stærð grunnsins fyrir viku- og mánaðarkort.
Auk þess leysir veitumælirinn sjálfur ekki vandann. Notamælislóðin er eintóna vaxandi aðgerð sem endurstillir sig á 0 á klukkutíma fresti. Við þurfum líka notendavæna neysluáætlun, hversu margir lítrar voru borðaðir á tímabilinu. Staðlaði söguritshlutinn gerir þetta ekki, en ytri smáritkortshlutinn getur hjálpað okkur.
Þetta er kortakóðinn fyrir 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'Til viðbótar við staðlaðar stillingar eins og skynjaranafn, grafgerð, lit (mér líkaði ekki við venjulega appelsínugula), er mikilvægt að hafa í huga 3 stillingar hér:
- group_by:hour - myndritið verður búið til með dálkum í samræmi við upphaf klukkustundarinnar
- stig_á klukkustund: 1 - ein bar á klukkustund
- Og síðast en ekki síst, aggregate_func: max er að taka hámarksgildi innan hverrar klukkustundar. Það er þessi breytu sem breytir sagtannatöflunni í súlur.
Ekki gefa gaum að röðinni af dálkum til vinstri - þetta er staðlað hegðun íhlutans ef engin gögn eru til. En það voru engin gögn - ég kveikti aðeins á gagnasöfnun með því að nota veitumælirinn fyrir nokkrum klukkustundum, bara vegna þessarar greinar (ég mun lýsa núverandi nálgun minni aðeins lægra).
Á þessari mynd vildi ég sýna að stundum virkar gagnaskjárinn jafnvel og súlurnar endurspegla raunverulega rétt gildi. En það er ekki allt. Af einhverjum ástæðum sýnir auðkenndur dálkur fyrir tímabilið 11:12 til 19:62 XNUMX lítra, þó að á tönnu línuritinu aðeins hærra fyrir sama tímabil frá sama skynjara sjáum við eyðslu upp á XNUMX lítra. Annað hvort eru pöddur eða hendur skakkar. En ég skil samt ekki hvers vegna gögnin hægra megin slitnuðu - neyslan þar var eðlileg, sem sést líka á tönnu línuritinu.
Almennt séð tókst mér ekki að ná trúverðugleika þessarar nálgunar - línuritið sýnir nánast alltaf einhvers konar villutrú.
Svipaður kóða fyrir dagskynjarann.
- 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'
Vinsamlegast athugaðu að group_by færibreytan er stillt á interval, og points_per_hour færibreytan ræður öllu. Og þetta er annað vandamál með þennan þátt - points_per_hour virkar vel á töflum sem eru klukkutíma eða minna, en ógeðslega á stærra millibili. Svo til að fá einn dálk á einum degi þurfti ég að slá inn gildið 1/24=0.04166666. Ég er ekki að tala um viku- og mánaðarkort.
Aðkoma 2
Á meðan ég var enn að finna út heimilisaðstoðarmanninn rakst ég á þetta myndband:
Félagi safnar neyslugögnum úr nokkrum gerðum af Xiaomi innstungum. Verkefni hans er aðeins einfaldara - sýndu bara verðmæti neyslu í dag, í gær og fyrir mánuðinn. Engin kort krafist.
Við skulum sleppa rökunum um handvirka samþættingu tafarlausra kraftgilda - ég skrifaði þegar um „nákvæmni“ þessarar nálgunar hér að ofan. Ekki er ljóst hvers vegna hann notaði ekki uppsafnað neyslugildi, sem þegar er safnað af sama útsölustað. Að mínu mati mun samþætting inni í járnstykkinu virka betur.
Frá myndbandinu munum við taka hugmyndina um að telja neyslu handvirkt í ákveðinn tíma. Fyrir karlmann eru aðeins gildin fyrir í dag og í gær tekin til greina, en við munum ganga lengra og reyna að teikna línurit. Kjarni fyrirhugaðrar aðferðar í mínu tilviki er sem hér segir.
Við munum búa til breytu gildi_at_the_beginning_of_hour, þar sem við munum skrifa núverandi teljara.
Samkvæmt tímamælinum í lok klukkustundar (eða í upphafi þess næsta), reiknum við mismuninn á núverandi aflestri og þeim sem er geymdur í upphafi klukkustundarinnar. Þessi munur verður eyðslan fyrir núverandi klukkutíma - við munum vista gildið í skynjaranum og í framtíðinni munum við byggja línurit sem byggir á þessu gildi.
Þú þarft líka að „endurstilla“ breytuna value_at_beginning_of_hour með því að skrifa núverandi gildi teljarans þar.
Allt þetta er hægt að gera í gegnum vel ... með aðstoð heimaþjónustunnar sjálfs.
Þú verður að skrifa aðeins meiri kóða en í fyrri nálgun. Byrjum á þessum "breytum". Upp úr kassanum höfum við ekki „breytilega“ eininguna, en þú getur notað þjónustu mqtt miðlara. Við munum senda gildi þangað með retain=true fánanum - þetta mun vista gildið inni í miðlaranum og það er hægt að draga það út hvenær sem er, jafnvel þegar heimilisaðstoðarmaðurinn er endurræstur. Ég gerði klukkutíma- og dagteljara í einu.
- 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: lAllir galdarnir gerast í sjálfvirkninni, sem keyrir á klukkutíma fresti og á hverju kvöldi, í sömu röð.
- 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: trueBáðar sjálfvirknivarnir gera 2 hluti:
- Reiknaðu gildið fyrir hvert bil sem mismuninn á upphafs- og lokagildi
- Uppfærðu grunngildið fyrir næsta bil
Bygging línurita í þessu tilfelli er leyst með venjulegu söguriti:
- 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Það lítur svona út:
Í grundvallaratriðum er þetta nú þegar það sem þú þarft. Kosturinn við þessa aðferð er að gögnin eru búin til einu sinni á millibili. Þeir. alls 24 færslur á dag fyrir tímaritið.
Því miður leysir þetta enn ekki almennan vanda vaxandi grunns. Ef ég vil mánaðarlegt neyslugraf þarf ég að geyma gögn í að minnsta kosti eitt ár. Og þar sem heimilisaðstoðarmaður gefur aðeins upp eina geymslutímastillingu fyrir allan gagnagrunninn þýðir þetta að ÖLL gögn í kerfinu verða að vera geymd í heilt ár. Til dæmis, á ári neyta ég 200 rúmmetra af vatni, sem þýðir 200000 færslur í gagnagrunninn. Og ef þú tekur tillit til annarra skynjara, þá verður myndin almennt ósæmileg.
Aðkoma 3
Sem betur fer hefur klárt fólk þegar leyst þetta vandamál með því að skrifa InfluxDB gagnagrunninn. Þessi gagnagrunnur er sérstaklega fínstilltur til að geyma tímatengd gögn og er tilvalin til að geyma gildi mismunandi skynjara. Kerfið býður einnig upp á SQL-líkt fyrirspurnarmál sem gerir þér kleift að draga gildi úr gagnagrunninum og safna þeim síðan saman á ýmsan hátt. Að lokum er hægt að geyma mismunandi gögn fyrir mismunandi tíma. Til dæmis er hægt að geyma mælingar sem breytast oft eins og hitastig eða rakastig í aðeins nokkrar vikur, á meðan daglegar mælingar á vatnsnotkun geta verið geymdar í heilt ár.
Auk InfluxDB fann snjallt fólk upp Grafana, kerfi til að teikna línurit úr gögnum frá InfluxDB. Grafana getur teiknað mismunandi gerðir af töflum, sérsniðið þau í smáatriðum, og síðast en ekki síst er hægt að „tengja“ þessum töflum í lovelace-UI heimilisaðstoðarmanninn.
vera innblástur и . Greinarnar lýsa ítarlega ferlinu við að setja upp og tengja InfluxDB og Grafana við heimilisaðstoðarmann. Ég mun einbeita mér að því að leysa tiltekið vandamál mitt.
Svo, fyrst og fremst, skulum byrja að bæta við teljaragildinu í influxDB. Hluti af uppsetningu heimilisaðstoðarmanna (í þessu dæmi mun ég skemmta mér ekki aðeins með köldu, heldur einnig með heitu vatni):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldVið skulum slökkva á vistun sömu gagna í innri gagnagrunni heimilisaðstoðarmanns til að blása þau ekki upp aftur:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldVið skulum nú fara í InfluxDB stjórnborðið og setja upp gagnagrunninn okkar. Sérstaklega þarftu að stilla hversu lengi ákveðin gögn verða geymd. Þetta er stjórnað af svokölluðu. varðveislustefna - þetta er svipað og gagnagrunna í aðalgagnagrunninum, þar sem hver innri gagnagrunnur hefur sínar eigin stillingar. Sjálfgefið er að öllum gögnum er bætt við varðveislustefnuna sem kallast autogen, þessi gögn verða geymd í viku. Ég vil að tímabundin gögn séu geymd í mánuð, vikugögn í eitt ár og mánaðarlegum gögnum verði aldrei eytt. Við munum búa til viðeigandi varðveislustefnu
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 1Nú er í raun aðalbragðið gagnasöfnun með því að nota stöðuga fyrirspurn. Þetta er vélbúnaður sem setur sjálfkrafa af stað fyrirspurn með tilteknu millibili, safnar saman gögnum fyrir þessa fyrirspurn og bætir niðurstöðunni við nýtt gildi. Við skulum skoða dæmi (ég skrifa í dálk fyrir læsileika, en í raun þurfti ég að slá inn þessa skipun á einni línu)
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Þessi skipun:
- Býr til samfellda fyrirspurn sem heitir cq_water_cold_hourly í heimahjálpargagnagrunninum
- Fyrirspurnin verður framkvæmd á klukkutíma fresti (tími (1klst))
- Fyrirspurnin mun draga út öll gögn frá measurement'a homeassistant.autogen.l (lítra), þar á meðal lestur á köldu og heitu vatni
- Söfnuð gögn verða flokkuð eftir entity_id, sem mun búa til aðskilin gildi fyrir kalt og heitt vatn.
- Þar sem lítrateljarinn er eintóna vaxandi röð innan hverrar klukkustundar þarftu að taka hámarksgildið, þannig að samansöfnunin fer fram með max(gildi) fallinu
- Nýja gildið verður skrifað á homeassistant.month.water_meter_hour þar sem mánuður er heiti varðveislustefnunnar með varðveislutíma í einn mánuð. Þar að auki verður gögnum um kalt og heitt vatn dreift í aðskildar færslur með samsvarandi entity_id og gildið í gildisreitnum
Á nóttunni eða þegar enginn er heima er engin vatnsnotkun og því eru heldur engin ný met í homeassistant.autogen.l. Til að forðast að vanta gildi í venjulegum fyrirspurnum geturðu notað fill(fyrra). Þetta mun neyða InfluxDB til að nota síðustu klukkustundargildið.
Því miður hefur stöðug fyrirspurn sérkenni: fylla (fyrra) bragðið virkar ekki og færslur eru einfaldlega ekki búnar til. Þar að auki er þetta einhvers konar óyfirstíganlegt vandamál, sem . Við munum takast á við þetta vandamál síðar og láta fylla (fyrri) í stöðugri fyrirspurn vera þar - það truflar ekki.
Við skulum athuga hvað gerðist (auðvitað þarftu að bíða í nokkrar klukkustundir):
> 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
Athugaðu að gildin í gagnagrunninum eru geymd í UTC, þannig að þessi listi munar um 3 klukkustundir - 7am gildin í InfluxDB úttakinu passa við 10am gildin í töflunum hér að ofan. Athugaðu líka að á milli 2 og 5 á morgnana eru einfaldlega engar skrár - þetta er einmitt eiginleiki stöðugrar fyrirspurnar.
Eins og þú sérð er uppsafnað gildi líka eintóna vaxandi röð, aðeins færslurnar eru sjaldgæfari - einu sinni á klukkustund. En þetta er ekki vandamál - við getum skrifað aðra fyrirspurn sem mun draga út rétt gögn fyrir töfluna.
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)Ég mun ráða:
- Úr homeassistant.month.water_meter_hour gagnagrunninum munum við draga gögn fyrir entity_id='water_meter_cold' fyrir síðasta daginn (tími >= now() -24h).
- Eins og ég nefndi, gætu einhverjar færslur vantað í homeassistant.month.water_meter_hour röðina. Við munum endurskapa þessi gögn með því að keyra fyrirspurnina með GROUP BY time(1h). Að þessu sinni mun fylla (fyrra) virka rétt og búa til þau gögn sem vantar (aðgerðin tekur fyrra gildi)
- Það mikilvægasta í þessari fyrirspurn er mismunafallið, sem mun reikna út mismuninn á klukkutímamerkjunum. Í sjálfu sér virkar það ekki og krefst samsöfnunaraðgerðar. Láttu þetta vera max() notað áður.
Framkvæmdarniðurstaðan lítur svona út
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 72Frá 2:5 til 0:XNUMX (UTC) var engin neysla. Engu að síður mun fyrirspurnin skila sama neyslugildi þökk sé fill(previous), og mismunafallið mun draga þetta gildi frá sjálfu sér og fá XNUMX við úttakið, sem í raun er krafist.
Það eina sem eftir er að gera er að búa til línurit. Til að gera þetta, opnaðu Grafana, opnaðu núverandi (eða búðu til nýtt) mælaborð, búðu til nýtt spjald. Kortastillingarnar verða sem hér segir.
Ég mun birta gögn um kalt og heitt vatn á sama línuriti. Beiðnin er nákvæmlega sú sama og ég lýsti hér að ofan.
Sýnisbreytur eru stilltar sem hér segir. Fyrir mér verður það graf með línum (línum), sem fer í þrepum (stiga). Stafla færibreytan verður útskýrð hér að neðan. Það eru nokkrir fleiri skjámöguleikar hér að neðan, en þeir eru ekki svo áhugaverðir.
Til að bæta grafinu sem myndast við heimilisaðstoðarmanninn þarftu að:
- fara úr myndvinnsluhamnum. Af einhverjum ástæðum eru réttar samnýtingarstillingar aðeins í boði á stjórnborðssíðunni
- Smelltu á þríhyrninginn við hliðina á nafni kortsins, veldu deila í valmyndinni
- Í glugganum sem opnast, farðu í flipann embed
- Taktu hakið úr núverandi tímabili - við munum stilla tímabilið með vefslóð
- Veldu viðeigandi efni. Í mínu tilfelli er það létt
- Afritaðu vefslóðina sem myndast á lovelace-UI stillingakortið
- 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"
Vinsamlegast athugaðu að tímabilið (síðustu 2 dagar) er stillt hér, en ekki í stillingum mælaborðsins.
Taflan lítur svona út. Ég hef ekki notað heitt vatn síðustu 2 daga, þannig að aðeins er teiknað graf af köldu vatni.
Ég hef ekki ákveðið sjálfur hvaða töflu mér líkar best, skreflína eða alvöru súlur. Þess vegna mun ég einfaldlega gefa dæmi um daglega neysluáætlun, aðeins að þessu sinni á börum. Fyrirspurnir eru byggðar upp á sama hátt og lýst er hér að ofan. Sýnavalkostirnir eru:
Þetta graf lítur svona út:
Svo, um Stack færibreytuna. Í þessu grafi er kalt vatnsslá teiknuð ofan á heitri stiku. Heildarhæð samsvarar heildarnotkun á köldu og heitu vatni á tímabilinu.
Öll myndrit sem sýnd eru eru kraftmikil. Þú getur fært músina yfir áhugaverðan stað og séð upplýsingar og gildi á tilteknum stað.
Því miður var það ekki án nokkurra flugu í höfuðið. Á súluriti (ólíkt línuritinu með skrefalínum) er miðja súlunnar ekki um miðjan dag, heldur klukkan 00:00. Þeir. vinstri helmingur stikunnar er dreginn í stað fyrri dags. Kortin fyrir laugardag og sunnudag eru því dregin aðeins til vinstri við bláleita svæðið. Þangað til ég fann út hvernig ég ætti að vinna það.
Annað vandamál er vanhæfni til að vinna rétt með mánaðarlegu millibili. Staðreyndin er sú að lengd klukkutíma / dags / viku er föst, en lengd mánaðarins er mismunandi í hvert skipti. InfluxDB getur aðeins unnið með jöfnu millibili. Hingað til hefur heilinn minn dugað til að stilla fast 30 daga millibili. Já, grafið mun fljóta aðeins yfir árið og súlurnar samsvara ekki nákvæmlega mánuðinum. En þar sem þetta er áhugavert fyrir mig bara sem skjámælir, þá er ég í lagi með þetta.
Ég sé að minnsta kosti tvær lausnir:
- Til að skora á mánaðarlegum töflum og takmarka þig við vikulega. 52 vikulegir barir á ári líta nokkuð vel út
- Líttu á mánaðarlega neysluna sjálfa sem aðferð nr. 2 og notaðu grafana aðeins fyrir falleg línurit. Það er frekar nákvæm lausn. Þú getur jafnvel lagt yfir töflur fyrir síðasta ár til samanburðar - grafana getur gert það.
Ályktun
Ég veit ekki af hverju, en ég elska svona töflur. Þær sýna að lífið er á fullu og allt að breytast. Í gær var mikið, í dag er lítið, á morgun verður eitthvað annað. Það á eftir að vinna með heimilum um neysluefnið. En jafnvel með núverandi matarlyst er bara stór og óskiljanleg tala í frumvarpinu þegar að breytast í nokkuð skiljanlega mynd af neyslu.
Þrátt fyrir næstum 20 ára feril minn sem forritari, skarstaði ég nánast ekki gagnagrunnum. Þess vegna virtist uppsetning ytri gagnagrunns vera eitthvað svo fáránlegt og óskiljanlegt. Allt hefur breyst - það kom í ljós að skrúfa viðeigandi verkfæri er gert með nokkrum smellum og með sérhæfðu verkfæri verður teikningin aðeins auðveldari.
Í fyrirsögninni minntist ég á rafmagnsnotkun. Því miður get ég ekki gefið neinar töflur í augnablikinu. Einn SDM120 metri er dauður og hinn er gallaður þegar hann er aðgengilegur í gegnum Modbus. Hins vegar hefur þetta ekki áhrif á efni þessarar greinar á nokkurn hátt - línuritin verða byggð á sama hátt og fyrir vatn.
Í þessari grein hef ég gefið þessar aðferðir sem ég hef reynt sjálfur. Það eru örugglega einhverjar aðrar leiðir til að skipuleggja söfnun og sjónræningu gagna sem ég veit ekki um. Segðu mér frá því í athugasemdunum, ég mun hafa mikinn áhuga. Ég mun vera ánægður með uppbyggjandi gagnrýni og nýjar hugmyndir. Ég vona að ofangreint efni muni líka hjálpa einhverjum.
Heimild: www.habr.com