Her cara ku ez heqê elektrîk û avê distînim, ez ecêbmayî dimînim - gelo bi rastî malbata min ew qas zêde dixwe? Belê, erê, serşokê qatek germkirî û boyler heye, lê ew her dem agir naşewitînin. Em di heman demê de dixuye ku em avê teserûfê dikin (her çend em jî hez dikin ku li serşokê birijînin). Çend sal berê min berê xwe da и xaniyek jîr, lê li wir tişt asê mane. Em tenê nuha gihîştine analîza serfkirinê, ya ku ev gotar bi rastî li ser e.
Min vê dawîyê wekî pergala xweya xaniyê jîr veguherî Alîkarê Malê. Yek ji wan sedeman tam fersenda organîzekirina berhevkirina hejmareke mezin a daneyan bi şiyana ku bi rehetî çêkirina cûrbecûr grafikan çêbikin bû.
Agahiyên ku di vê gotarê de têne diyar kirin ne nû ne ev hemî tiştên ku di bin sosên cûda de berê li ser Înternetê hatine vegotin. Lê her gotar bi gelemperî tenê nêzîkbûnek an aliyek diyar dike. Ez neçar bûm ku van hemî nêzîkatiyan berhev bikim û ya herî guncaw bixwe bibijêrim. Gotar hîna jî agahdariya berfireh li ser berhevkirina daneyan peyda nake, lê celebek kurteyek e ku min ew çawa kir. Ji ber vê yekê rexneyên çêker û pêşniyarên ji bo çêtirkirinê bi xêr hatin.
Formulkirina pirsgirêkê
Ji ber vê yekê, mebesta werzîşê ya îro ev e ku meriv grafikên xweşik ên xerckirina av û elektrîkê bigire:
- Saet ji bo 2 rojan
- Rojane ji bo 2 hefteyan
- (vebijarkî) heftane û mehane
Di vê yekê de hinek zehmetî hene:
- Parçeyên nexşeya standard bi gelemperî pir xizan in. Ya çêtirîn, hûn dikarin xal bi xal grafiyek rêzê ava bikin.
Ger hûn têra xwe dijwar lê mêze bikin, hûn dikarin pêkhateyên sêyemîn ên ku kapasîteyên nexşeya standard berfireh dikin bibînin. Ji bo arîkarek malê, di prensîbê de, ev hêmanek baş û xweşik e , lê ew jî hinekî sînorkirî ye:
- Zehmet e ku meriv pîvanên nexşeya barkê di navberên mezin de bicîh bike (firehiya barkê di perçeyên saetekê de tê danîn, ku tê vê wateyê ku navberên ji saetek dirêjtir dê di hejmarên perçeyî de bêne danîn)
- Hûn nikarin hebûnên cihêreng li yek grafîkê zêde bikin (mînak, germahî û nemû, an grafika barkê bi xêzekê re bikin yek)
- Ne tenê arîkarê malê ji hêla xwerû ve databasa SQLite ya herî primitive bikar tîne (û ez, pisporek, min nikarîbû MySQL an Postgres saz bikim), lê dane jî bi awayê herî çêtirîn nayê hilanîn. Ji ber vê yekê, wek nimûne, her gava ku hûn pîvanek dîjîtal a herî piçûk a parametreyê jî biguhezînin, jsonek mezin bi qasî kîlobyte li databasê tê nivîsandin.
{"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}}}Gelek senzorên min hene (sensorên germahiyê li her odeyê, metreyên av û elektrîkê), û hin jî gelek daneyan çêdikin. Mînakî, metreya elektrîkê ya SDM220 tenê her 10-15 saniyeyan deh nirxan çêdike, û ez dixwazim bi qasî 8 metreyên weha saz bikim. Va. van hemî nirxan dikarin rojane bi 100-200 MB databasê bi hêsanî zêde bikin. Di nav hefteyekê de dê pergal bi zor tevbigere, û di mehekê de ajokera flash dê bimire (di rewşa sazkirina arîkarê malê ya tîpîk de li ser Raspberry PI), û hilanîna daneyan ji bo salek tevahî ne pirs e.
- Heke hûn bi şens in, metreya we dikare xwe bixwe bijmêre. Hûn dikarin her dem li metreyê bizivirin û bipirsin nirxa vexwarinê ya berhevkirî çend demjimêr e. Wekî qaîdeyek, hemî pîvanên elektrîkê yên ku pêwendiyek dîjîtal heye (RS232 / RS485 / Modbus / Zigbee) vê derfetê peyda dikin.
Xirabtir e heke amûrek bi hêsanî dikare hin parametreyên tavilê bipîve (mînak, hêza tavilê an niha), an jî bi tenê her X watt-saet an lître pêlşan çêbike. Dûv re hûn hewce ne ku bifikirin ka meriv çawa û bi çi wê entegre bike û li ku derê nirx berhev bike. Metirsiya wendakirina rapora paşîn ji ber sedemek heye, û rastbûna pergalê bi tevahî pirsan derdixe pêş. Bê guman, hûn dikarin van hemîyan bispêrin pergalek xaniyek aqilmend mîna arîkarê malê, lê kesî xala li ser hejmara tomarên di databasê de betal nekiriye, û ew ê nekare ji saniyeyê zêdetir senzoran bipirse (a sînorkirina mîmariya arîkarê malê).
Nêzîkbûn 1
Pêşîn, ka em bibînin ka arîkarê malê ji hundurê çi peyda dike. Pîvandina vexwarinê di heyamekê de fonksiyonek pir tê xwestin e. Bê guman, ew demek dirêj berê di forma pêkhateyek pispor - utility_meter de hate bicîh kirin.
Esasê beşê ev e ku ew di hundurê xwe de guhêrbarek niha_accumulated_value diafirîne û piştî demek diyarkirî (saet / hefte / meh) wê ji nû ve saz dike. Parçeyek bixwe guhêrbara têketinê (nirxa hin senzorê) dişopîne, xwe di guheztinên nirxê de vedigire - hûn tenê encama qedandî digirin. Ev tişt di pelê veavakirinê de tenê di çend rêzan de tê vegotin
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Li vir sensor.water_meter_cold nirxa metreya heyî bi lîtreyan e ku ez distînim ji hêla mqtt. Sêwiran 2 senzorên nû water_cold_hour_um û water_cold_day_um diafirîne, ku xwendinên demjimêr û rojane berhev dikin, piştî ku heyam qediya wan vedigerîne sifirê. Li vir grafiyek pîlê saetê ji bo nîv rojê heye.
Koda ji bo nexşeyên demjimêr û rojane yên ji bo lovelace-UI wiha xuya dike:
- 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
Bi rastî, pirsgirêka vê nêzîkbûnê di vê algorîtmê de ye. Wekî ku min berê jî behs kir, ji bo her nirxa têketinê (xwendina metreya heyî ji bo her lîtreyek din) 1kb tomar di databasê de têne çêkirin. Her metreya karûbar jî nirxek nû çêdike, ku ew jî li bingehê tê zêdekirin. Ger ez bixwazim xwendinên saetî / rojane / heftane / mehane, û ji bo çend rakêşên avê berhev bikim, û pakêtek metreyên elektrîkê lê zêde bikim, ew ê bibe gelek dane. Welê, bi rastî, pir dane tune, lê ji ber ku arîkarê malê komek agahdariya nehewce li databasê dinivîse, mezinahiya databasê dê bi lez û bez mezin bibe. Ez ditirsim ku mezinahiya bingehê ji bo nexşeyên heftane û mehane jî texmîn bikim.
Wekî din, metreya karûbar bi serê xwe pirsgirêkê çareser nake. Grafika nirxên ku ji hêla metreya karûbar ve hatî hilberandin fonksiyonek monotonîk e ku her demjimêr li 0-ê vedigere. Pêdiviya me bi nexşeyek vexwarinê heye ku ji bikarhêner re tê fam kirin, ku destnîşan bike ka çend lître di heyamê de hatine vexwarin. Parçeya standard-dîrok-grafî nikare vê yekê bike, lê hêmana derveyî ya mini-grafî-karta dikare alîkariya me bike.
Ev koda qerta ji bo lovelace-UI ye:
- 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'Ji bilî mîhengên standard ên wekî navê sensor, celebê grafîkê, reng (min ji porteqalê standard hez nekir), girîng e ku 3 mîhengan binihêrin:
- group_by:saet - grafîk dê bi barên ku li destpêka demjimêrê hatine rêz kirin were çêkirin
- xalên_per_saetê: 1 - ji bo her saetekê barek
- Û ya herî girîng, aggregate_func: max - di nav her demjimêrê de nirxa herî zêde bigire. Ev parametre ye ku grafiya diranan vediguherîne baran
Bala xwe nedin rêza stûnên li milê çepê - heke dane tune be ev tevgera standard a pêkhateyê ye. Lê dane tune bû - min tenê ji bo xatirê vê gotarê çend demjimêran berê berhevkirina daneyên pîvana karûbar vekir (ez ê nêzîkatiya xweya heyî li jêr diyar bikim).
Di vê wêneyê de min xwest nîşan bidim ku carinan nîşana daneyê jî dixebite û bar bi rastî nirxên rast nîşan didin. Lê ev ne hemû ye. Ji ber hin sedeman, stûna hilbijartî ji bo heyama ji 11 heta 12 danê sibê 19 lître nîşan dide, her çend li ser grafika diranan ji bo heman heyamê ji heman senzorê hinekî bilindtir em vexwarina 62 lîtreyan dibînin. An kêzikek heye an jî dest qut in. Lê ez hîn jî fam nakim çima daneyên li ser rastê qut bûn - vexwarina li wir normal bû, ku ji grafika diranan jî xuya ye.
Bi gelemperî, min nekarî bigihêjim pêbaweriya vê nêzîkatiyê - graf hema hema her gav celebek virek nîşan dide.
Koda bi heman rengî ji bo senora rojê.
- 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'
Ji kerema xwe bala xwe bidin ku pîvana group_by wekî navberê hatî danîn, û parametreya points_per_hour her tiştî hukum dike. Û di wê de pirsgirêkek din a vê hêmanê heye - points_per_hour li ser nexşeyên saetek an kêmtir baş dixebite, lê ew di navberên mezintir de dimije. Ji ber vê yekê ji bo ku ez di rojekê de stûnek bistînim, diviya bû ku ez nirxa 1/24=0.04166666 binivîsim. Ez behsa nexşeyên heftane û mehane jî nakim.
Nêzîkbûn 2
Dema ku hîn jî arîkarê malê fam kir, min rastî vê vîdyoyê hat:
Hevalek daneyên serfkirinê ji çend celeb soketên Xiaomi berhev dike. Karê wî hinekî hêsan e - tenê nirxa vexwarinê ya îro, duh û mehê nîşan bide. No schedules pêwîst.
Ka em nîqaşên li ser yekbûna destanî ya nirxên hêza tavilê bihêlin - min berê li jor li ser "rastbûna" vê nêzîkatiyê nivîsî. Ne diyar e ka çima wî nirxên serfkirinê yên berhevkirî yên ku berê ji hêla heman dergehê ve têne berhev kirin, bikar neaniye. Bi dîtina min, entegrasyonê di hundurê hardware de dê çêtir bixebite.
Ji vîdyoyê em ê fikra jimartina bi destan serfkirinê di heyamekê de bigirin. Zilam tenê ji bo îro û duh nirxan dihejmêre, lê em ê pêşdetir biçin û hewl bidin ku grafiyek xêz bikin. Esasê rêbaza pêşniyarkirî di doza min de wiha ye.
Ka em guhêrbarek value_at_the_beginning_of_hour biafirînin, ku tê de em ê xwendinên metreya heyî tomar bikin.
Bi karanîna demjimêrê, di dawiya saetê de (an jî di destpêka saeta din de) em ferqa di navbera xwendina heyî û ya ku di destpêka saetê de hatî hilanîn hesab dikin. Ev cûdahî dê ji bo demjimêra heyî vexwarinê be - em ê nirxê di senzorê de hilînin, û di pêşerojê de em ê li ser vê nirxê grafiyek ava bikin.
Her weha hûn hewce ne ku guhêrbara value_at_beginning_of_hour bi nivîsandina nirxa jimareya heyî li wir "ji nû ve saz bikin".
Hemî ev dikare bi navgîniya alîkarê malê bixwe were kirin.
Pêdivî ye ku hûn ji nêzîkatiya berê hinekî bêtir kodê binivîsin. Pêşîn, em van heman "guherbaran" biafirînin. Li derveyî sindoqê me saziyek "guhêrbar" tune, lê em dikarin karûbarên brokera mqtt bikar bînin. Em ê bi ala retain=true nirxan bişînin wir - ev ê nirxê di hundurê brokerê de xilas bike, û ew dikare di her kêliyê de ji wir were derxistin, hetta dema ku arîkarê malê ji nû ve were destpêkirin. Min jimarevanên saet û rojane bi carekê re çêkirin.
- 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: lHemî sêrbaz di otomasyonê de pêk tê, ku bi rêzê her demjimêr û her şev dimeşe.
- 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: trueHer du otomasyon 2 çalakiyan pêk tînin:
- Nirxê ji bo navberekê wekî ferqa di navbera nirxên destpêk û dawiyê de hesab bikin
- Ji bo navbera paşîn nirxa bingehîn nûve bikin
Avakirina grafikan di vê rewşê de ji hêla dîrok-grafiya asayî ve tê çareser kirin:
- 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_dayEv wisa xuya dike:
Di prensîbê de, ev jixwe hewce ye. Feydeya vê rêbazê ev e ku dane ji her navberê carekê têne çêkirin. Ewan. her roj tenê 24 tomar ji bo nexşeyek demjimêr.
Mixabin, ev hîn jî pirsgirêka gelemperî ya bingehek mezinbûnê çareser nake. Ger ez grafikek vexwarinê ya mehane bixwazim, divê ez bi kêmî ve salek daneyan hilînim. Û ji ber ku arîkarê malê ji bo tevahiya databasê tenê yek mîhengek dirêjahiya hilanînê peyda dike, ev tê vê wateyê ku HEMÛ daneyên di pergalê de dê salek tevahî werin hilanîn. Mînak, di salekê de ez 200 metrekup av vedixwim, ev tê wê wateyê ku ev tê wateya 200000 navnîşan di databasê de. Û heke hûn senzorên din jî bihesibînin, wê hingê jimar bi gelemperî bêrûmet dibe.
Nêzîkbûn 3
Xwezî, mirovên jîr jixwe ev pirsgirêk bi nivîsandina databasa InfluxDB çareser kirine. Ev databas bi taybetî ji bo hilanîna daneya-based-demê xweşbîn e û ji bo hilanîna nirxên senzorên cihêreng îdeal e. Pergal di heman demê de zimanek pirsê ya mîna SQL peyda dike ku dihêle hûn nirxan ji databasê derxînin û dûv re wan bi awayên cihêreng berhev bikin. Di dawiyê de, daneyên cûda dikarin ji bo demên cûda werin hilanîn. Mînakî, xwendinên ku pir caran diguhezin mîna germahî an şilbûnê dikare tenê çend hefte were hilanîn, dema ku xwendina rojane ya vexwarina avê dikare ji bo salek tevahî were hilanîn.
Ji bilî InfluxDB, mirovên jîr jî Grafana, pergalek ji bo xêzkirina grafikên li ser bingeha daneyên InfluxDB îcad kirin. Grafana dikare cûrbecûr grafikan xêz bike, wan bi hûrgulî xweş bike, û ya herî girîng, van grafîkan dikarin li ser arîkarê malê lovelace-UI-ê "pêç bikin".
Îlhama xwe bigirin и . Gotar bi hûrgulî pêvajoya sazkirin û girêdana InfluxDB û Grafana bi arîkarê malê re vedibêje. Ez ê li ser çareserkirina pirsgirêka xwe ya taybetî bisekinim.
Ji ber vê yekê, berî her tiştî, em dest bi lêzêdekirina nirxa dijber li influxDB bikin. Parçeyek ji veavakirina arîkarê malê (di vê nimûneyê de ez ê ne tenê bi ava sar, lê di heman demê de bi ava germ jî kêfê bikim):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldWerin em hilanîna heman daneyê li databasa arîkarê malê ya navxweyî neçalak bikin da ku ew careke din bişewitin:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldKa em naha biçin konsolê InfluxDB û databasa xwe mîheng bikin. Bi taybetî, hûn hewce ne ku hûn mîheng bikin ka dê çend daneyan werin hilanîn. Ev bi navê tê tertîb kirin. Siyaseta ragirtinê - ev dişibihe databasên di nav databasek sereke de ye, digel ku her databasa hundurîn mîhengên xwe hene. Ji hêla xwerû ve, hemî daneyên di polîtîkaya ragirtinê de ku jê re dibêjin autogen têne hilanîn; Ez dixwazim ku daneyên saetê mehekê, daneyên heftane salekê bên parastin û daneyên mehane qet jê nebin. Ka em polîtîkaya ragirtinê ya guncan biafirînin
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 1Naha, bi rastî, xapandina bingehîn berhevkirina daneyan e ku bi karanîna lêpirsîna domdar tê bikar anîn. Ev mekanîzmayek e ku bixweber pirsek di navberên diyarkirî de dimeşîne, daneyên ji bo vê pirsê berhev dike, û encamê di nirxek nû de zêde dike. Ka em li mînakekê binihêrin (ez ji bo xwendinê di stûnekê de dinivîsim, lê di rastiyê de min neçar ma ku vê fermanê di yek rêzê de binivîsim)
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)
ENDEv ferman:
- Di databasa homeassistant de pirsek domdar bi navê cq_water_cold_hourly diafirîne
- Daxwaz dê her demjimêr (demjimêr (1h)) were bicîh kirin
- Daxwaz dê hemî daneyên ji pîvana 'homeassistant.autogen.l (lître), tevî xwendinên ava sar û germ
- Daneyên berhevkirî dê ji hêla entity_id ve werin kom kirin, ku dê ji bo ava sar û germ nirxên cihêreng bide me.
- Ji ber ku jimarvana lîtreyê di nav her saetekê de rêzek monotonî ye ku zêde dibe, pêdivî ye ku meriv nirxa herî zêde bigire, ji ber vê yekê kombûn dê ji hêla fonksiyona max (nirx) ve were kirin.
- Nirxa nû dê ji bo homeassistant.month.water_meter_hour were nivîsandin, ku meh navê polîtîkaya ragirtinê ye bi heyama ragirtinê ya mehekê. Digel vê yekê, daneyên li ser ava sar û germ dê bi navgîniya entity_id û nirxa têkildar di qada nirxê de di tomarên cihêreng de bêne belav kirin.
Bi şev an dema ku kes ne li malê ye, vexwarina avê tune, û ji ber vê yekê di homeassistant.autogen.l de têketinên nû tune. Ji bo ku hûn di pirsên birêkûpêk de nirxên winda nebin, hûn dikarin dagirtin (berê) bikar bînin. Ev ê zorê bide InfluxDB ku nirxa demjimêra paşîn bikar bîne.
Mixabin, lêpirsîna domdar taybetmendiyek heye: fêlbaziya dagirtî (berê) naxebite û tomar bi tenê nayên afirandin. Wekî din, ev pirsgirêkek pirsgirêkek bêserûber e . Em ê paşê bi vê pirsgirêkê re mijûl bibin, lê bila tije (berê) di lêpirsîna domdar de be - ew destwerdanê nake.
Ka em kontrol bikin ka çi qewimî (bê guman, hûn hewce ne ku çend demjimêran bisekinin):
> 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
Têbînî ku nirxên di databasê de li UTC têne hilanîn, ji ber vê yekê ev navnîş bi 3 demjimêran cûda dibe - nirxên 7am di derana InfluxDB de bi nirxên 10am ên di grafikên jorîn de têkildar in. Di heman demê de bala xwe bidin ku di navbera 2 û 5 danê sibê de tenê tomar tune - ev heman taybetmendiya lêpirsîna domdar e.
Wekî ku hûn dikarin bibînin, nirxa berhevkirî di heman demê de rêzek monotonîk zêde dibe, tenê navnîşan kêm caran diqewime - demjimêr carekê. Lê ev ne pirsgirêkek e - em dikarin pirsek din binivîsin ku dê daneyên rast ji bo grafîkê bistîne.
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)Ez ê deşîfre bikim:
- Ji databasa homeassistant.month.water_meter_hour em ê daneyan ji bo entity_id='water_meter_cold' ji bo roja dawî derxînin (dema >= niha() -24h).
- Wekî ku min berê jî behs kir, dibe ku hin navnîşan di rêzika homeassistant.month.water_meter_hour de winda bibin. Em ê van daneyan bi xebitandina pirsekê bi GROUP BY time(1h) ji nû ve biafirînin. Vê carê dagirtin (berê) dê wekî ku tê hêvî kirin bixebite, daneyên winda biafirîne (fonksiyonê dê nirxa berê bigire)
- Di vê daxwazê de ya herî girîng fonksiyona cûdahiyê ye, ku dê cûdahiya di navbera nîşaneyên demjimêr de hesab bike. Ew bi serê xwe naxebite û fonksiyonek berhevkirinê hewce dike. Bila ev max() ya ku berê hatî bikar anîn be.
Encama darvekirinê wiha xuya dike
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 72Ji 2 heta 5 danê sibê (UTC) vexwarin tune bû. Lêbelê, pirs dê bi saya dagirtina (berê) heman nirxa vexwarinê vegerîne, û fonksiyona cûdahiyê dê vê nirxê ji xwe kêm bike û encam dê bibe 0, ya ku bi rastî hewce ye.
Tiştê ku dimîne ev e ku meriv grafikek ava bike. Ji bo kirina vê yekê, Grafana vekin, hin panelek heyî (an jî nû) vekin, û panelek nû biafirînin. Mîhengên nexşeyê dê bi vî rengî be.
Ez ê daneyên ava sar û germ li ser heman grafîkê nîşan bidim. Daxwaz tam heman e ku min li jor diyar kir.
Parametreyên xuyangê wekî jêrîn têne danîn. Ji bo min ew ê bibe grafiyek bi rêzan, ku bi gavan (derenceyan) diçe. Ez ê pîvana Stackê li jêr rave bikim. Li jêr çend vebijarkên pêşandanê yên din hene, lê ew ne ew qas balkêş in.
Ji bo ku nexşeya encam li arîkarê malê zêde bikin, hûn hewce ne:
- ji moda guherandina nexşeyê derkeve. Ji ber hin sedeman, mîhengên parvekirina nexşeya rast tenê ji rûpela dashboardê têne pêşkêş kirin
- Li ser sêgoşeya li kêleka navê nexşeyê bikirtînin û ji pêşekê parvekirinê hilbijêrin
- Di pencereya ku vedibe, biçin tabloya embed
- Rêzeya demjimêra heyî rakin - em ê bi navgîniya URL-ê rêza demê destnîşan bikin
- Mijara pêwîst hilbijêrin. Di doza min de ew sivik e
- URL-ya encam li qerta mîhengên lovelace-UI kopî bikin
- 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"
Ji kerema xwe bala xwe bidin ku qada demê (2 rojên dawî) li vir hatî danîn, û ne di mîhengên dashboardê de.
Graf bi vî rengî xuya dike. Min di van 2 rojên dawî de ava germ bikar neaniye, ji ber vê yekê tenê grafiya ava sar tê kişandin.
Min hîn jî ji bo xwe biryar nedaye ku ez ji kîjan grafîkê çêtir hez dikim, xêzek-gavek, an barikên rastîn. Ji ber vê yekê, ez ê tenê mînakek nexşeyek vexwarinê ya rojane bidim, tenê vê carê di baran de. Pirs bi heman rengî yên ku li jor hatine destnîşan kirin têne çêkirin. Vebijarkên pêşandanê ev in:
Ev graf wiha xuya dike:
Ji ber vê yekê di derbarê parametreya Stack de. Di vê grafîkê de, stûnek ava sar li ser stûnek ava germ tê kişandin. Bilindahiya giştî bi vexwarina giştî ya ava sar û germ a heyamê re têkildar e.
Hemî grafikên ku têne xuyang kirin dînamîk in. Hûn dikarin mişka xwe li ser xala balkêş bihêlin û hûrgulî û nirxê li xalek taybetî bibînin.
Mixabin di nav melhemê de çend fîşek hebûn. Li ser nexşeyek barek (bervajî nexşeyek bi rêzikên gavê), nîvê bar ne di nîvê rojê de, lê di demjimêr 00:00 de ye. Ewan. nîvê çepê yê stûnê li şûna roja berê hatiye kişandin. Ji ber vê yekê grafikên Şemî û Yekşemê hinekî ber bi çepê devera şîn têne kişandin. Heya ku min fêm kir ku meriv wê çawa têk bibe.
Pirsgirêkek din nekarbûna bi rêkûpêk di navberên mehane de ye. Rastî ev e ku dirêjahiya saet/roj/heftê sabit e, lê dirêjahiya mehê her carê cûda ye. InfluxDB tenê dikare di navberên wekhev de bixebite. Heya nuha mêjiyên min têra danîna navberek diyarkirî ya 30 rojan e. Erê, graf dê di seranserê salê de piçekî biherike û bar dê tam li gorî mehan nebin. Lê ji ber ku ez bi vî tiştî bi tenê wekî metreyek xuyangê eleqedar im, ez jê re baş im.
Ez herî kêm du çareseriyê dibînim:
- Dev ji nexşeyên mehane berdin û xwe bi yên hefteyî sînordar bikin. 52 barên heftane yên salê pir xweş xuya dikin
- Vexwarina mehane bixwe wekî rêbaza No. 2 bihesibînin, û grafana tenê ji bo grafikên xweşik bikar bînin. Ew ê çareseriyek pir rast be. Tewra hûn dikarin ji bo berhevdanê grafikên sala çûyî li ser bikin - grafana jî dikare wiya bike.
encamê
Nizanim çima, lê ez bi van cure grafîkan ve mijûl im. Ew nîşan didin ku jiyan di herikîna xwe de ye û her tişt diguhere. Duh pir bû, îro hindik e, sibe dê tiştekî din be. Tiştê ku dimîne ev e ku meriv bi endamên malbatê re li ser mijara vexwarinê bixebite. Lê tewra digel dilxwazên heyî, tenê jimareyek mezin û nefêmkirî ya li ser dravê dravdanê jixwe vediguhere wêneyek têgihîştî ya vexwarinê.
Tevî kariyera min a hema hema 20-salî wekî bernamesaz, min hema hema ti têkiliya min bi databasan re tune bû. Ji ber vê yekê, sazkirina databasek derveyî mîna tiştek wusa nebaş û nefêm xuya bû. Her tişt guhert - Derket holê ku pêvekirina amûrek maqûl di çend klîk de tête kirin, û bi amûrek pispor re, karê xêzkirina nexşeyan hinekî hêsantir dibe.
Di sernavê de min behsa xerckirina elektrîkê kir. Mixabin, niha ez nikarim ti grafikan pêşkêş bikim. Metreyek SDM120 ji bo min mir, û ya din dema ku bi Modbus ve tê gihîştinê dişewite. Lêbelê, ev bi ti awayî bandorê li ser mijara vê gotarê nake - grafîk dê bi heman awayê ku ji bo avê têne çêkirin.
Di vê gotarê de min nêzîkatiyên ku min bi xwe ceriband pêşkêş kir. Bê guman hin awayên din ên organîzekirina berhevkirina daneyan û dîtinê hene ku ez pê nizanim. Di şîroveyan de ji min re bêje, ez ê pir eleqedar bim. Ez ê bi rexneyên çêker û ramanên nû kêfxweş bibim. Ez hêvî dikim ku materyalê pêşkêşkirî jî dê alîkariya kesek bike.
Source: www.habr.com
