Sa tuwing makakatanggap ako ng bayad para sa kuryente at tubig, nagugulat ako - ang aking pamilya ba ay talagang kumukonsumo? Buweno, oo, ang banyo ay may mainit na sahig at isang boiler, ngunit hindi sila nagsusunog ng apoy sa lahat ng oras. Mukhang nagtitipid din kami ng tubig (kahit mahilig din kaming magsaboy sa banyo). Ilang taon na ang nakalipas ko na ΠΈ sa isang matalinong tahanan, ngunit doon natigil ang mga bagay. Ngayon pa lamang tayo nakarating sa pagsusuri sa pagkonsumo, na kung ano talaga ang tungkol sa artikulong ito.
Kamakailan ay lumipat ako sa Home Assistant bilang aking smart home system. Ang isa sa mga dahilan ay tiyak ang pagkakataon na ayusin ang koleksyon ng isang malaking halaga ng data na may kakayahang maginhawang bumuo ng iba't ibang uri ng mga graph.
Ang impormasyong inilarawan sa artikulong ito ay hindi bago; ang lahat ng mga bagay na ito sa ilalim ng iba't ibang mga sarsa ay inilarawan na sa Internet. Ngunit ang bawat artikulo ay karaniwang naglalarawan lamang ng isang diskarte o aspeto. Kinailangan kong ihambing ang lahat ng mga pamamaraang ito at piliin ang pinaka-angkop sa aking sarili. Ang artikulo ay hindi pa rin nagbibigay ng komprehensibong impormasyon sa pangongolekta ng data, ngunit isang uri ng buod ng kung paano ko ito ginawa. Kaya't ang mga nakabubuo na pagpuna at mungkahi para sa pagpapabuti ay malugod na tinatanggap.
Pahayag ng problema
Kaya, ang layunin ng ehersisyo ngayon ay makakuha ng magagandang graph ng pagkonsumo ng tubig at kuryente:
- Oras-oras para sa 2 araw
- Araw-araw sa loob ng 2 linggo
- (opsyonal) lingguhan at buwanan
Mayroong ilang mga paghihirap dito:
- Karaniwang mahirap ang mga karaniwang bahagi ng tsart. Sa pinakamainam, maaari kang bumuo ng isang line graph point by point.
Kung titingnan mo nang husto, makakahanap ka ng mga bahagi ng third-party na nagpapalawak ng mga kakayahan ng karaniwang tsart. Para sa isang katulong sa bahay, sa prinsipyo, ito ay isang mahusay at magandang bahagi , ngunit ito rin ay medyo limitado:
- Mahirap itakda ang mga parameter ng isang bar chart sa malalaking agwat (ang lapad ng bar ay nakatakda sa mga fraction ng isang oras, na nangangahulugang ang mga agwat na mas mahaba kaysa sa isang oras ay itatakda sa mga fractional na numero)
- Hindi ka maaaring magdagdag ng iba't ibang entity sa isang graph (halimbawa, temperatura at halumigmig, o pagsamahin ang isang bar graph sa isang linya)
- Hindi lamang ginagamit ng home assistant bilang default ang pinaka-primitive na database ng SQLite (at ako, isang handyman, ay hindi makayanan ang pag-install ng MySQL o Postgres), ngunit ang data ay hindi nakaimbak sa pinakamainam na paraan. Kaya, halimbawa, sa tuwing babaguhin mo ang kahit na ang pinakamaliit na digital na parameter ng isang parameter, isang malaking json na halos isang kilobyte ang laki ay nakasulat sa database.
{"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}}}Mayroon akong napakaraming sensor (mga sensor ng temperatura sa bawat kuwarto, metro ng tubig at kuryente), at ang ilan ay bumubuo rin ng napakaraming data. Halimbawa, ang metro ng kuryente ng SDM220 lamang ay bumubuo ng humigit-kumulang isang dosenang halaga bawat 10-15 segundo, at gusto kong mag-install ng mga 8 ganoong metro. Mayroon ding isang buong grupo ng mga parameter na kinakalkula batay sa iba pang mga sensor. yun. lahat ng mga halagang ito ay madaling mapalaki ang database ng 100-200 MB araw-araw. Sa isang linggo ang system ay halos hindi gumagalaw, at sa isang buwan ang flash drive ay mamamatay (sa kaso ng isang tipikal na pag-install ng home assistant sa isang Raspberry PI), at ang pag-iimbak ng data para sa isang buong taon ay wala sa tanong.
- Kung ikaw ay mapalad, ang iyong metro ay maaaring magbilang ng pagkonsumo mismo. Maaari kang lumiko sa metro anumang oras at magtanong kung anong oras ang naipong halaga ng pagkonsumo. Bilang panuntunan, lahat ng metro ng kuryente na may digital na interface (RS232/RS485/Modbus/Zigbee) ay nagbibigay ng pagkakataong ito.
Mas malala kung masusukat lang ng device ang ilang instant na parameter (halimbawa, instantaneous power o current), o mag-generate lang ng mga pulso bawat X watt-hours o liters. Pagkatapos ay kailangan mong isipin kung paano at kung ano ang isasama nito at kung saan mag-iipon ng halaga. May panganib na mawala ang susunod na ulat para sa anumang kadahilanan, at ang katumpakan ng system sa kabuuan ay nagtataas ng mga katanungan. Siyempre, maaari mong ipagkatiwala ang lahat ng ito sa isang matalinong sistema ng tahanan tulad ng home assistant, ngunit walang sinuman ang nagkansela ng punto tungkol sa bilang ng mga tala sa database, at hindi posibleng mag-poll ng mga sensor nang higit sa isang beses sa isang segundo (a limitasyon ng arkitektura ng katulong sa bahay).
Pagdulog 1
Una, tingnan natin kung ano ang ibinibigay ng katulong sa bahay sa labas ng kahon. Ang pagsukat ng pagkonsumo sa loob ng isang panahon ay isang lubos na hinahangad na pag-andar. Siyempre, ito ay ipinatupad ng matagal na ang nakalipas sa anyo ng isang dalubhasang bahagi - utility_meter.
Ang kakanyahan ng bahagi ay ang panloob na paglikha ng isang variable na current_accumulated_value at ni-reset ito pagkatapos ng isang tinukoy na panahon (oras/linggo/buwan). Ang bahagi mismo ay sinusubaybayan ang input variable (ang halaga ng ilang sensor), nag-subscribe sa sarili sa mga pagbabago sa halaga - nakuha mo lang ang natapos na resulta. Ang bagay na ito ay inilarawan sa ilang linya lamang sa configuration file
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Narito ang sensor.water_meter_cold ay ang kasalukuyang halaga ng metro sa litro na natatanggap ko sa pamamagitan ng mqtt. Lumilikha ang disenyo ng 2 bagong sensor na water_cold_hour_um at water_cold_day_um, na nag-iipon ng oras-oras at pang-araw-araw na pagbabasa, na nire-reset ang mga ito sa zero pagkatapos mag-expire ang panahon. Narito ang isang graph ng oras-oras na baterya para sa kalahating araw.
Ang code para sa oras-oras at pang-araw-araw na mga chart para sa lovelace-UI ay ganito ang hitsura:
- 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
Sa totoo lang, ang problema sa diskarteng ito ay nasa algorithm na ito. Tulad ng nabanggit ko na, para sa bawat halaga ng input (kasalukuyang pagbabasa ng metro para sa bawat susunod na litro) 1kb ng mga talaan ay nabuo sa database. Ang bawat metro ng utility ay bumubuo rin ng bagong halaga, na idinaragdag din sa base. Kung gusto kong mangolekta ng oras-oras/araw-araw/lingguhan/buwanang mga pagbabasa, at para sa ilang water risers, at magdagdag ng isang pakete ng mga electric meter, iyon ay magiging maraming data. Well, mas tiyak, walang maraming data, ngunit dahil ang katulong sa bahay ay nagsusulat ng isang grupo ng mga hindi kinakailangang impormasyon sa database, ang laki ng database ay lalago nang mabilis. Natatakot akong kahit na tantyahin ang laki ng base para sa lingguhan at buwanang mga chart.
Bilang karagdagan, ang metro ng utility mismo ay hindi malulutas ang problema. Ang graph ng mga value na ginawa ng utility meter ay isang monotonically na pagtaas ng function na nagre-reset sa 0 bawat oras. Kailangan namin ng tsart ng pagkonsumo na nauunawaan ng gumagamit, na nagpapakita kung gaano karaming litro ang nakonsumo sa panahon. Hindi ito magagawa ng karaniwang bahagi ng history-graph, ngunit makakatulong sa atin ang panlabas na bahagi ng mini-graph-card.
Ito ang card code para sa 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'Bilang karagdagan sa mga karaniwang setting tulad ng pangalan ng sensor, uri ng graph, kulay (hindi ko gusto ang karaniwang orange), mahalagang tandaan ang 3 mga setting:
- group_by:hour β bubuuin ang graph gamit ang mga bar na nakahanay sa simula ng oras
- points_per_hour: 1 - isang bar para sa bawat oras
- At ang pinakamahalaga, aggregate_func: max - kunin ang maximum na halaga sa loob ng bawat oras. Ang parameter na ito ang nagpapalit ng sawtooth graph sa mga bar
Huwag pansinin ang hilera ng mga haligi sa kaliwa - ito ang karaniwang pag-uugali ng bahagi kung walang data. Ngunit walang data - In-on ko lang ang pagkolekta ng data ng metro ng utility ilang oras ang nakalipas para lang sa artikulong ito (ilarawan ko ang aking kasalukuyang diskarte sa ibaba).
Sa larawang ito nais kong ipakita na kung minsan ang pagpapakita ng data ay gumagana at ang mga bar ay talagang nagpapakita ng mga tamang halaga. Ngunit hindi lang iyon. Para sa ilang kadahilanan, ang napiling hanay para sa panahon mula 11 hanggang 12 ng umaga ay nagpapakita ng 19 litro, bagaman sa graph na may ngipin na medyo mas mataas para sa parehong panahon mula sa parehong sensor ay nakikita natin ang pagkonsumo ng 62 litro. Maaaring may surot o baluktot ang mga kamay. Ngunit hindi ko pa rin maintindihan kung bakit naputol ang data sa kanan - normal ang pagkonsumo doon, na nakikita rin mula sa graph na may ngipin.
Sa pangkalahatan, hindi ko nakamit ang katumpakan ng diskarteng ito - ang graph ay halos palaging nagpapakita ng ilang uri ng maling pananampalataya.
Katulad na code para sa sensor ng araw.
- 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'
Pakitandaan na ang group_by parameter ay nakatakda sa pagitan, at ang points_per_hour na parameter ang namamahala sa lahat. At doon ay namamalagi ang isa pang problema sa bahaging ito - ang points_per_hour ay gumagana nang maayos sa mga chart ng isang oras o mas kaunti, ngunit ito ay sumisipsip sa mas malalaking agwat. Kaya para makakuha ng isang column sa isang araw, kailangan kong ilagay ang value na 1/24=0.04166666. Hindi ko man lang pinag-uusapan ang lingguhan at buwanang mga chart.
Pagdulog 2
Habang nauunawaan pa rin ang katulong sa bahay, nakita ko ang video na ito:
Kinokolekta ng isang kaibigan ang data ng pagkonsumo mula sa ilang uri ng Xiaomi socket. Ang kanyang gawain ay medyo mas simple - ipakita lamang ang halaga ng pagkonsumo para sa ngayon, kahapon at para sa buwan. Walang kinakailangang mga iskedyul.
Iwanan natin ang mga talakayan tungkol sa manu-manong pagsasama ng mga agarang halaga ng kapangyarihan - Naisulat ko na sa itaas ang tungkol sa "katumpakan" ng diskarteng ito. Hindi malinaw kung bakit hindi niya ginamit ang naipon na halaga ng pagkonsumo, na nakolekta na ng parehong outlet. Sa aking opinyon, ang pagsasama sa loob ng hardware ay gagana nang mas mahusay.
Mula sa video ay kukuha kami ng ideya ng manu-manong pagbibilang ng pagkonsumo sa loob ng isang panahon. Binibilang lamang ng lalaki ang mga halaga para sa ngayon at kahapon, ngunit lalakad pa tayo at susubukan na gumuhit ng isang graph. Ang kakanyahan ng iminungkahing pamamaraan sa aking kaso ay ang mga sumusunod.
Gumawa tayo ng variable value_at_the_beginning_of_hour, kung saan itatala natin ang kasalukuyang mga pagbabasa ng metro
Gamit ang timer, sa pagtatapos ng oras (o sa simula ng susunod) kinakalkula namin ang pagkakaiba sa pagitan ng kasalukuyang pagbabasa at ang nakaimbak sa simula ng oras. Ang pagkakaibang ito ay ang pagkonsumo para sa kasalukuyang oras - ise-save namin ang halaga sa sensor, at sa hinaharap ay bubuo kami ng isang graph batay sa halagang ito.
Kailangan mo ring "i-reset" ang value_at_beginning_of_hour variable sa pamamagitan ng pagsusulat ng kasalukuyang counter value doon.
Ang lahat ng ito ay maaaring gawin sa pamamagitan ng home assistant mismo.
Kakailanganin mong magsulat ng kaunti pang code kaysa sa nakaraang diskarte. Una, gawin natin itong parehong "mga variable". Out of the box wala kaming "variable" na entity, ngunit magagamit namin ang mga serbisyo ng mqtt broker. Magpapadala kami ng mga halaga doon kasama ang retain=true flag - ito ay magse-save ng halaga sa loob ng broker, at maaari itong ma-pull out doon anumang oras, kahit na ang home assistant ay na-reboot. Gumawa ako ng oras-oras at pang-araw-araw na mga counter nang sabay-sabay.
- 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: lAng lahat ng magic ay nangyayari sa automation, na tumatakbo bawat oras at gabi-gabi ayon sa pagkakabanggit.
- 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: trueAng parehong mga automation ay nagsasagawa ng 2 pagkilos:
- Kalkulahin ang halaga para sa isang agwat bilang pagkakaiba sa pagitan ng mga halaga ng simula at pagtatapos
- I-update ang base value para sa susunod na agwat
Ang pagbuo ng mga graph sa kasong ito ay nalulutas ng karaniwang history-graph:
- 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_dayMukhang ito:
Sa prinsipyo, ito na ang kailangan. Ang bentahe ng pamamaraang ito ay ang data ay nabuo nang isang beses bawat pagitan. Yung. 24 na tala lamang bawat araw para sa isang oras-oras na tsart.
Sa kasamaang palad, hindi pa rin nito malulutas ang pangkalahatang problema ng lumalaking base. Kung gusto ko ng buwanang graph ng pagkonsumo, kailangan kong mag-imbak ng data nang hindi bababa sa isang taon. At dahil nagbibigay lamang ang home assistant ng isang setting ng tagal ng imbakan para sa buong database, nangangahulugan ito na LAHAT ng data sa system ay kailangang maimbak sa loob ng isang buong taon. Halimbawa, sa isang taon kumokonsumo ako ng 200 metro kubiko ng tubig, na nangangahulugang nangangahulugan ito ng 200000 mga entry sa database. At kung isasaalang-alang mo ang iba pang mga sensor, kung gayon ang pigura ay nagiging karaniwang hindi disente.
Pagdulog 3
Sa kabutihang palad, nalutas na ng matatalinong tao ang problemang ito sa pamamagitan ng pagsulat ng database ng InfluxDB. Ang database na ito ay espesyal na na-optimize para sa pag-iimbak ng data na nakabatay sa oras at perpekto para sa pag-iimbak ng mga halaga ng iba't ibang mga sensor. Nagbibigay din ang system ng mala-SQL na query language na nagbibigay-daan sa iyong kunin ang mga halaga mula sa database at pagkatapos ay pagsama-samahin ang mga ito sa iba't ibang paraan. Sa wakas, ang iba't ibang data ay maaaring maimbak para sa iba't ibang oras. Halimbawa, ang madalas na pagbabago ng mga pagbabasa tulad ng temperatura o halumigmig ay maaaring iimbak sa loob lamang ng ilang linggo, habang ang pang-araw-araw na pagbabasa ng pagkonsumo ng tubig ay maaaring iimbak para sa isang buong taon.
Bukod sa InfluxDB, naimbento rin ng mga matatalinong tao ang Grafana, isang sistema para sa pagguhit ng mga graph batay sa data mula sa InfluxDB. Maaaring gumuhit ang Grafana ng iba't ibang uri ng mga graph, i-customize ang mga ito nang detalyado, at, higit sa lahat, maaaring "i-plug" ang mga graph na ito sa lovelace-UI home assistant.
Maging inspirasyon ΠΈ . Inilalarawan ng mga artikulo nang detalyado ang proseso ng pag-install at pagkonekta ng InfluxDB at Grafana sa home assistant. Tutuon ako sa paglutas ng aking partikular na problema.
Kaya, una sa lahat, simulan natin ang pagdaragdag ng counter value sa influxDB. Isang piraso ng pagsasaayos ng katulong sa bahay (sa halimbawang ito ay magiging masaya ako hindi lamang sa malamig, kundi pati na rin sa mainit na tubig):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldHuwag paganahin ang pag-save ng parehong data na ito sa panloob na database ng katulong sa bahay upang hindi ito muling mabuo:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldPumunta tayo ngayon sa InfluxDB console at i-configure ang aming database. Sa partikular, kailangan mong i-configure kung gaano katagal iimbak ang ilang partikular na data. Ito ay kinokontrol ng tinatawag na. patakaran sa pagpapanatili - ito ay katulad ng mga database sa loob ng isang pangunahing database, na ang bawat panloob na database ay may sariling mga setting. Bilang default, ang lahat ng data ay nakaimbak sa isang patakaran sa pagpapanatili na tinatawag na autogen; ang data na ito ay maiimbak sa loob ng isang linggo. Gusto kong panatilihin ang oras-oras na data sa loob ng isang buwan, ang lingguhang data na itago sa loob ng isang taon, at ang buwanang data ay hindi kailanman matanggal. Gumawa tayo ng naaangkop na patakaran sa pagpapanatili
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 1Ngayon, sa katunayan, ang pangunahing lansihin ay ang pagsasama-sama ng data gamit ang tuluy-tuloy na query. Ito ay isang mekanismo na awtomatikong nagpapatakbo ng query sa mga tinukoy na agwat, pinagsasama-sama ang data para sa query na ito, at nagdaragdag ng resulta sa isang bagong halaga. Tingnan natin ang isang halimbawa (nagsusulat ako sa isang haligi para sa pagiging madaling mabasa, ngunit sa katotohanan kailangan kong ipasok ang utos na ito sa isang linya)
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)
ENDAng utos na ito:
- Lumilikha ng tuluy-tuloy na query na pinangalanang cq_water_cold_hourly sa homeassistant database
- Ang kahilingan ay isasagawa bawat oras (oras(1h))
- Sisikatin ng kahilingan ang lahat ng data mula sa homeassistant.autogen.l (litro) ng pagsukat, kabilang ang mga pagbabasa ng malamig at mainit na tubig
- Ang pinagsama-samang data ay papangkatin ayon sa entity_id, na magbibigay sa amin ng magkahiwalay na halaga para sa malamig at mainit na tubig
- Dahil ang litro counter ay isang monotonically pagtaas ng sequence sa loob ng bawat oras, ito ay kinakailangan upang kunin ang maximum na halaga, kaya ang pagsasama-sama ay isasagawa sa pamamagitan ng function max(value)
- Ang bagong halaga ay isusulat sa homeassistant.month.water_meter_hour, kung saan ang buwan ay ang pangalan ng patakaran sa pagpapanatili na may panahon ng pagpapanatili na isang buwan. Bukod dito, ang data sa malamig at mainit na tubig ay ikakalat sa magkahiwalay na mga talaan na may kaukulang entity_id at halaga sa field ng halaga
Sa gabi o kapag walang tao sa bahay, walang pagkonsumo ng tubig, at samakatuwid ay walang mga bagong entry sa homeassistant.autogen.l. Upang maiwasan ang mga nawawalang halaga sa mga regular na query, maaari mong gamitin ang fill(nakaraan). Pipilitin nito ang InfluxDB na gamitin ang halaga ng huling oras.
Sa kasamaang palad, ang tuluy-tuloy na query ay may kakaiba: ang fill(nakaraang) trick ay hindi gumagana at ang mga tala ay hindi nagagawa. Bukod dito, ito ay isang uri ng hindi malulutas na problema na . Haharapin natin ang problemang ito sa ibang pagkakataon, ngunit hayaang punan ang(nakaraan) sa tuluy-tuloy na query - hindi ito makagambala.
Suriin natin kung ano ang nangyari (siyempre, kailangan mong maghintay ng ilang oras):
> 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
Tandaan na ang mga halaga sa database ay naka-imbak sa UTC, kaya ang listahang ito ay naiiba ng 3 oras - ang mga halaga ng 7am sa output ng InfluxDB ay tumutugma sa mga halaga ng 10am sa mga graph sa itaas. Tandaan din na sa pagitan ng 2 at 5 am ay walang mga tala - ito ang parehong tampok ng tuluy-tuloy na query.
Tulad ng nakikita mo, ang pinagsama-samang halaga ay isa ring monotonically na pagtaas ng pagkakasunud-sunod, ang mga entry lang ay nangyayari nang mas madalas - isang beses bawat oras. Ngunit hindi ito problema - maaari tayong magsulat ng isa pang query na kukuha ng tamang data para sa graph.
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)Ide-decipher ko:
- Mula sa database ng homeassistant.month.water_meter_hour kukuha kami ng data para sa entity_id='water_meter_cold' para sa huling araw (oras >= ngayon() -24h).
- Gaya ng nabanggit ko na, maaaring nawawala ang ilang entry sa homeassistant.month.water_meter_hour sequence. Buuin namin ang data na ito sa pamamagitan ng pagpapatakbo ng query na may GROUP BY time(1h). Ang oras na ito fill(nakaraan) ay gagana gaya ng inaasahan, na bumubuo ng nawawalang data (ang function ay kukuha ng nakaraang halaga)
- Ang pinakamahalagang bagay sa kahilingang ito ay ang function ng pagkakaiba, na kakalkulahin ang pagkakaiba sa pagitan ng mga marka ng oras. Hindi ito gumagana nang mag-isa at nangangailangan ng aggregation function. Hayaang ito ang max() na ginamit noon.
Ang resulta ng pagpapatupad ay ganito
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 72Mula 2 hanggang 5 am (UTC) ay walang pagkonsumo. Gayunpaman, ibabalik ng query ang parehong halaga ng pagkonsumo salamat sa pagpuno (nakaraan), at ang pagkakaiba ng function ay ibawas ang halagang ito mula sa sarili nito at ang output ay magiging 0, na kung ano mismo ang kinakailangan.
Ang natitira na lang ay bumuo ng isang graph. Upang gawin ito, buksan ang Grafana, buksan ang ilang umiiral na (o gumawa ng bago) dashboard, at lumikha ng bagong panel. Magiging ganito ang mga setting ng chart.
Ipapakita ko ang data ng malamig at mainit na tubig sa parehong graph. Ang kahilingan ay eksaktong kapareho ng inilarawan ko sa itaas.
Ang mga parameter ng display ay itinakda bilang mga sumusunod. Para sa akin ito ay isang graph na may mga linya, na napupunta sa mga hakbang (hagdan). Ipapaliwanag ko ang Stack parameter sa ibaba. Mayroong ilang higit pang mga opsyon sa pagpapakita sa ibaba, ngunit hindi sila ganoon kawili-wili.
Upang idagdag ang resultang chart sa home assistant kailangan mong:
- lumabas sa chart editing mode. Para sa ilang kadahilanan, ang tamang mga setting ng pagbabahagi ng chart ay inaalok lamang mula sa pahina ng dashboard
- Mag-click sa tatsulok sa tabi ng pangalan ng chart at piliin ang ibahagi mula sa menu
- Sa window na bubukas, pumunta sa tab na naka-embed
- Alisan ng check ang kasalukuyang hanay ng oras - itatakda namin ang hanay ng oras sa pamamagitan ng URL
- Piliin ang kinakailangang paksa. Sa aking kaso ito ay magaan
- Kopyahin ang resultang URL sa card ng mga setting ng 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"
Pakitandaan na ang hanay ng oras (huling 2 araw) ay nakatakda dito, at hindi sa mga setting ng dashboard.
Ang graph ay ganito ang hitsura. Hindi ako gumamit ng mainit na tubig sa nakalipas na 2 araw, kaya ang graph lang ng malamig na tubig ang iginuhit.
Hindi ko pa rin napagpasyahan para sa sarili ko kung aling graph ang mas gusto ko, isang line-step, o mga totoong bar. Samakatuwid, magbibigay lang ako ng isang halimbawa ng isang pang-araw-araw na tsart ng pagkonsumo, sa pagkakataong ito lamang sa mga bar. Ang mga query ay binuo katulad ng mga inilarawan sa itaas. Ang mga opsyon sa pagpapakita ay:
Ang graph na ito ay ganito ang hitsura:
Kaya tungkol sa parameter ng Stack. Sa graph na ito, isang column ng malamig na tubig ang iginuhit sa ibabaw ng isang column ng mainit na tubig. Ang kabuuang taas ay tumutugma sa kabuuang pagkonsumo ng malamig at mainit na tubig para sa panahon.
Ang lahat ng mga graph na ipinapakita ay dynamic. Maaari mong i-hover ang iyong mouse sa punto ng interes at makita ang mga detalye at halaga sa isang partikular na punto.
Sa kasamaang palad, mayroong isang pares ng langaw sa pamahid. Sa isang bar chart (hindi tulad ng isang chart na may mga hakbang na linya), ang gitna ng bar ay wala sa kalagitnaan ng araw, ngunit sa 00:00. Yung. ang kaliwang kalahati ng column ay iginuhit bilang kapalit ng nakaraang araw. Kaya ang mga graph para sa Sabado at Linggo ay bahagyang iginuhit sa kaliwa ng mala-bughaw na sona. Hanggang sa naisip ko kung paano ito matatalo.
Ang isa pang problema ay ang kawalan ng kakayahan na gumana nang maayos sa buwanang agwat. Ang katotohanan ay ang haba ng oras/araw/linggo ay naayos, ngunit ang haba ng buwan ay iba sa bawat oras. Ang InfluxDB ay maaari lamang gumana sa pantay na pagitan. Sa ngayon ay sapat na ang aking utak upang magtakda ng isang nakapirming pagitan ng 30 araw. Oo, ang graph ay lulutang ng kaunti sa buong taon at ang mga bar ay hindi eksaktong tumutugma sa mga buwan. Ngunit dahil interesado ako sa bagay na ito bilang isang display meter lamang, ok lang ako dito.
Nakikita ko ang hindi bababa sa dalawang solusyon:
- Sumuko sa mga buwanang chart at limitahan ang iyong sarili sa mga lingguhang chart. Ang 52 lingguhang bar para sa taon ay mukhang maganda
- Isaalang-alang ang buwanang pagkonsumo mismo bilang paraan No. 2, at gumamit lamang ng grafana para sa magagandang mga graph. Ito ay magiging isang tumpak na solusyon. Maaari ka ring mag-overlay ng mga graph para sa nakaraang taon para sa paghahambing - magagawa rin iyon ng grafana.
Konklusyon
Hindi ko alam kung bakit, pero nahuhumaling ako sa mga ganitong klaseng graph. Ipinakita nila na ang buhay ay puspusan at lahat ay nagbabago. Kahapon marami, ngayon konti, bukas iba na. Ang natitira na lang ay makipagtulungan sa mga miyembro ng sambahayan sa paksa ng pagkonsumo. Ngunit kahit na sa kasalukuyang mga gana, ang isang malaki at hindi maintindihan na figure sa slip ng pagbabayad ay nagiging isang medyo naiintindihan na larawan ng pagkonsumo.
Sa kabila ng aking halos 20-taong karera bilang isang programmer, halos wala akong kontak sa mga database. Samakatuwid, ang pag-install ng isang panlabas na database ay tila isang bagay na napakahirap at hindi maintindihan. Binago ang lahat β ito ay lumabas na ang pag-attach ng isang angkop na tool ay ginagawa sa ilang mga pag-click, at sa isang dalubhasang tool, ang gawain ng pag-plot ng mga chart ay nagiging mas madali.
Sa pamagat ay binanggit ko ang pagkonsumo ng kuryente. Sa kasamaang palad, sa ngayon ay hindi ako makapagbigay ng anumang mga graph. Isang SDM120 meter ang namatay para sa akin, at ang isa ay glitchy kapag na-access sa pamamagitan ng Modbus. Gayunpaman, hindi ito nakakaapekto sa paksa ng artikulong ito sa anumang paraan - ang mga graph ay gagawin sa parehong paraan tulad ng para sa tubig.
Sa artikulong ito ipinakita ko ang mga diskarte na sinubukan ko sa aking sarili. Tiyak na may ilang iba pang paraan upang ayusin ang pangongolekta at visualization ng data na hindi ko alam. Sabihin sa akin ang tungkol dito sa mga komento, magiging interesado ako. Ako ay natutuwa sa nakabubuo na pagpuna at mga bagong ideya. Umaasa ako na ang materyal na ipinakita ay makakatulong din sa isang tao.
Pinagmulan: www.habr.com