Bob tro y byddaf yn derbyn taliad am drydan a dŵr, tybed - a yw fy nheulu yn bwyta cymaint? Wel, oes, mae llawr wedi'i gynhesu a boeler yn yr ystafell ymolchi, ond nid ydynt yn gweithio fel dynion tân drwy'r amser. Mae'n ymddangos ein bod ni hefyd yn arbed dŵr (er ein bod ni hefyd yn hoffi sblasio yn yr ystafell ymolchi). Ychydig flynyddoedd yn ôl yr wyf yn barod и i gartref smart, ond dyma lle aeth pethau yn sownd. Dim ond nawr y mae'r dwylo wedi cyrraedd y dadansoddiad o ddefnydd, sydd, mewn gwirionedd, yn ymwneud â'r erthygl hon.
Yn ddiweddar, fe wnes i newid i Gynorthwyydd Cartref fel fy system cartref smart. Un o'r rhesymau oedd y gallu i drefnu casglu llawer iawn o ddata gyda'r posibilrwydd o adeiladu gwahanol fathau o graffiau yn gyfleus.
Nid yw'r wybodaeth a ddisgrifir yn yr erthygl hon yn newydd, mae'r holl bethau hyn o dan wahanol sawsiau eisoes wedi'u disgrifio ar y Rhyngrwyd. Ond mae pob erthygl, fel rheol, yn disgrifio dim ond un dull neu agwedd. Roedd yn rhaid i mi gymharu'r holl ddulliau hyn a dewis yr un mwyaf addas fy hun. Nid yw'r erthygl yn darparu gwybodaeth gynhwysfawr am gasglu data o hyd, ond mae'n fath o grynodeb o sut y gwnes i hynny. Felly croesewir beirniadaeth adeiladol ac awgrymiadau ar gyfer gwella.
Datganiad o'r broblem
Felly, nod ymarfer heddiw yw cael graffiau hardd o ddefnydd dŵr a thrydan:
- Yr awr am 2 ddiwrnod
- Bob dydd am 2 wythnos
- (dewisol) wythnosol a misol
Mae rhai anawsterau yn hyn o beth:
- Mae cydrannau safonol y siart yn tueddu i fod yn eithaf gwael. Ar y gorau, gallwch chi adeiladu graff llinell fesul pwyntiau.
Os chwiliwch yn dda, gallwch ddod o hyd i gydrannau trydydd parti sy'n ymestyn galluoedd y siart safonol. Ar gyfer cynorthwy-ydd cartref, mewn egwyddor, cydran dda a hardd , ond mae hefyd braidd yn gyfyngedig:
- Mae'n anodd gosod paramedrau'r siart bar ar gyfnodau mawr (mae lled y bar wedi'i osod mewn ffracsiynau o awr, sy'n golygu y bydd cyfnodau mwy nag awr yn cael eu gosod mewn rhifau ffracsiynol)
- Ni allwch ychwanegu endidau gwahanol at un graff (er enghraifft, tymheredd a lleithder, na chyfuno graff bar â llinell)
- Nid yn unig y mae'r cynorthwyydd cartref yn defnyddio'r gronfa ddata SQLite fwyaf cyntefig yn ddiofyn (ac ni wnes i, y tasgmon, feistroli gosod MySQL neu Postgres), nid yw'r data'n cael ei storio yn y ffordd fwyaf optimaidd. Felly, er enghraifft, gyda phob newid o bob hyd yn oed y paramedr digidol lleiaf o baramedr, json enfawr tua kilobyte o ran maint yn cael ei ysgrifennu i'r gronfa ddata
{"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}}}Mae gen i dipyn o synwyryddion (synwyryddion tymheredd ym mhob ystafell, mesuryddion dŵr a thrydan), ac mae rhai hefyd yn cynhyrchu cryn dipyn o ddata. Er enghraifft, dim ond y mesurydd trydan SDM220 sy'n cynhyrchu tua dwsin o werthoedd bob 10-15 eiliad, a hoffwn osod 8 metr o'r fath.Ac mae yna hefyd griw cyfan o baramedrau sy'n cael eu cyfrifo yn seiliedig ar synwyryddion eraill. Hynny. gall yr holl werthoedd hyn chwyddo'r gronfa ddata yn hawdd 100-200 MB bob dydd. Mewn wythnos, prin y bydd y system yn taflu a throi, ac mewn mis bydd y gyriant fflach yn marw (yn achos gosodiad arferol cynorthwyydd cartref ar PI mafon), ac ni all fod unrhyw sôn am storio data am flwyddyn gyfan. .
- Os ydych chi'n lwcus, gall eich mesurydd ei hun gyfrif y defnydd. Gallwch gysylltu â'r mesurydd ar unrhyw adeg a gofyn faint o'r gloch yw'r gwerth defnydd cronedig. Fel rheol, mae pob mesurydd trydan sydd â rhyngwyneb digidol (RS232/RS485/Modbus/Zigbee) yn rhoi cyfle o'r fath.
Yn waeth, os yw'r ddyfais yn gallu mesur rhywfaint o baramedr ar unwaith (er enghraifft, pŵer neu gerrynt ar unwaith), neu gynhyrchu corbys bob X wat-awr neu litr. Yna mae angen ichi feddwl am sut a gyda beth i'w integreiddio a ble i gronni gwerth. Mae risg o golli’r adroddiad nesaf am unrhyw reswm, ac mae cywirdeb y system yn ei chyfanrwydd yn codi cwestiynau. Gallwch, wrth gwrs, ymddiried hyn i gyd i system cartref smart fel cynorthwyydd cartref, ond nid oes neb wedi canslo'r pwynt ynghylch nifer y cofnodion yn y gronfa ddata, ac ni fydd synwyryddion pleidleisio fwy nag unwaith yr eiliad yn gweithio (cyfyngiad ar y pensaernïaeth cynorthwyydd cartref).
Dull 1
Yn gyntaf, gadewch i ni weld pa gynorthwyydd cartref a ddarperir allan o'r bocs. Mae mesur defnydd dros gyfnod yn swyddogaeth y mae galw mawr amdani. Wrth gwrs, fe'i gweithredwyd amser maith yn ôl fel elfen arbenigol - utility_meter.
Hanfod y gydran yw ei fod yn cychwyn y newidyn current_accumulated_value y tu mewn ac yn ei ailosod ar ôl cyfnod penodol (awr/wythnos/mis). Mae'r gydran ei hun yn monitro'r newidyn sy'n dod i mewn (gwerth rhyw fath o synhwyrydd), yn tanysgrifio i newidiadau yn y gwerth ei hun - dim ond y canlyniad gorffenedig rydych chi'n ei gael. Disgrifir y peth hwn mewn ychydig linellau yn y ffeil ffurfweddu
utility_meter:
water_cold_hour_um:
source: sensor.water_meter_cold
cycle: hourly
water_cold_day_um:
source: sensor.water_meter_cold
cycle: daily
Yma sensor.water_meter_cold yw gwerth cerrynt y mesurydd mewn litrau a gaf gan mqtt. Mae'r dyluniad yn creu 2 synhwyrydd newydd water_cold_hour_um a water_cold_day_um, sy'n cronni darlleniadau bob awr a dyddiol, gan eu hailosod i sero ar ôl cyfnod. Dyma graff o'r batri fesul awr am hanner diwrnod.
Mae'r cod siart fesul awr a dyddiol ar gyfer lovelace-UI yn edrych fel hyn:
- 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
Mewn gwirionedd, yn yr algorithm hwn mae problem y dull hwn. Fel y soniais eisoes, ar gyfer pob gwerth sy'n dod i mewn (y darlleniad mesurydd cyfredol ar gyfer pob litr nesaf), mae 1kb o gofnod yn cael ei gynhyrchu yn y gronfa ddata. Mae pob mesurydd cyfleustodau hefyd yn cynhyrchu gwerth newydd, sydd hefyd yn cael ei ychwanegu at y sylfaen. Os ydw i eisiau casglu darlleniadau awr / dyddiol / wythnosol / misol, ie, ar gyfer sawl codwr dŵr, a hyd yn oed ychwanegu pecyn o fesuryddion trydan, bydd hyn yn llawer o ddata. Wel, yn fwy manwl gywir, nid oes llawer o ddata, ond gan fod y cynorthwyydd cartref yn ysgrifennu llawer o wybodaeth ddiangen i'r gronfa ddata, bydd maint y gronfa ddata yn cynyddu'n gyflym. Rwyf hyd yn oed yn ofni amcangyfrif maint y sylfaen ar gyfer siartiau wythnosol a misol.
Yn ogystal, nid yw'r mesurydd cyfleustodau ei hun yn datrys y broblem. Mae llain y mesurydd cyfleustodau yn swyddogaeth sy'n cynyddu'n undonog sy'n ailosod i 0 bob awr. Mae arnom hefyd angen amserlen ddefnydd hawdd ei defnyddio, faint o litrau a fwytewyd yn ystod y cyfnod. Nid yw'r gydran graff hanes safonol yn gwneud hyn, ond gall y gydran cerdyn graff bach allanol ein helpu.
Dyma'r cod cerdyn ar gyfer 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'Yn ogystal â'r gosodiadau safonol fel enw'r synhwyrydd, math o graff, lliw (doeddwn i ddim yn hoffi'r oren safonol), mae'n bwysig nodi 3 gosodiad yma:
- group_by:hour - bydd y siart yn cael ei gynhyrchu gyda cholofnau wedi'u halinio i ddechrau'r awr
- points_per_hour: 1 - un bar yr awr
- Ac yn bwysicaf oll, aggregate_func: max yw cymryd y gwerth mwyaf o fewn pob awr. Y paramedr hwn sy'n troi'r siart dant llif yn fariau.
Peidiwch â rhoi sylw i'r rhes o golofnau ar y chwith - dyma ymddygiad safonol y gydran os nad oes data. Ond nid oedd unrhyw ddata - dim ond ychydig oriau yn ôl y gwnes i droi ar gasglu data gan ddefnyddio'r mesurydd cyfleustodau er mwyn yr erthygl hon (byddaf yn disgrifio fy null presennol ychydig yn is).
Yn y llun hwn, roeddwn i eisiau dangos bod yr arddangosfa ddata weithiau hyd yn oed yn gweithio, a bod y bariau'n adlewyrchu'r gwerthoedd cywir mewn gwirionedd. Ond nid dyna'r cyfan. Am ryw reswm, mae'r golofn a amlygwyd ar gyfer y cyfnod o 11 am i 12 am yn dangos 19 litr, er ar y graff danheddog ychydig yn uwch ar gyfer yr un cyfnod o'r un synhwyrydd gwelwn ddefnydd o 62 litr. Naill ai byg neu ddwylo yn gam. Ond dwi dal ddim yn deall pam y torrodd y data ar y dde - roedd y defnydd yno'n normal, sydd hefyd yn weladwy o'r graff dannedd.
Yn gyffredinol, methais â chyflawni hygrededd y dull hwn - mae'r graff bron bob amser yn dangos rhyw fath o heresi.
Cod tebyg ar gyfer y synhwyrydd yn ystod y dydd.
- 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'
Sylwch fod y paramedr group_by wedi'i osod i gyfwng, ac mae'r paramedr points_per_hour yn rheoli popeth. Ac mae hon yn broblem arall gyda'r gydran hon - mae points_per_hour yn gweithio'n dda ar siartiau o awr neu lai, ond yn ffiaidd ar gyfnodau mwy. Felly i gael un golofn mewn un diwrnod, roedd yn rhaid i mi nodi'r gwerth 1/24=0.04166666. Dydw i ddim yn sôn am siartiau wythnosol a misol.
Dull 2
Tra'n dal i ddarganfod y cynorthwyydd cartref, deuthum ar draws y fideo hwn:
Mae'r cymrawd yn casglu data defnydd o sawl math o socedi Xiaomi. Mae ei dasg ychydig yn symlach - dangoswch werth y defnydd ar gyfer heddiw, ddoe ac am y mis. Nid oes angen siartiau.
Gadewch i ni adael y dadleuon ynghylch integreiddio gwerthoedd pŵer ar unwaith â llaw o'r neilltu - ysgrifennais eisoes am “gywirdeb” y dull hwn uchod. Nid yw'n glir pam na ddefnyddiodd y gwerthoedd defnydd cronedig, sydd eisoes yn cael eu casglu gan yr un allfa. Yn fy marn i, bydd integreiddio y tu mewn i'r darn o haearn yn gweithio'n well.
O'r fideo, byddwn yn cymryd y syniad o gyfrif defnydd â llaw am gyfnod. I ddyn, dim ond y gwerthoedd ar gyfer heddiw a ddoe sy'n cael eu hystyried, ond byddwn yn mynd ymhellach ac yn ceisio llunio graff. Mae hanfod y dull arfaethedig yn fy achos i fel a ganlyn.
Byddwn yn creu newidyn value_at_the_beginning_of_hour, lle byddwn yn ysgrifennu'r darlleniadau cownter cyfredol
Yn ôl yr amserydd ar ddiwedd yr awr (neu ar ddechrau'r nesaf), rydym yn cyfrifo'r gwahaniaeth rhwng y darlleniad cyfredol a'r un sy'n cael ei storio ar ddechrau'r awr. Y gwahaniaeth hwn fydd y defnydd ar gyfer yr awr gyfredol - byddwn yn arbed y gwerth i'r synhwyrydd, ac yn y dyfodol byddwn yn adeiladu graff yn seiliedig ar y gwerth hwn.
Mae angen i chi hefyd “ailosod” y newidyn value_at_beginning_of_hour trwy ysgrifennu gwerth cyfredol y rhifydd yno.
Gellir gwneud hyn i gyd yn dda ... trwy gyfrwng y cynorthwy-ydd cartref ei hun.
Bydd yn rhaid i chi ysgrifennu ychydig mwy o god nag yn y dull blaenorol. Gadewch i ni ddechrau gyda'r "newidynnau" hyn. Allan o'r bocs, nid oes gennym yr endid “amrywiol”, ond gallwch ddefnyddio gwasanaethau brocer mqtt. Byddwn yn anfon gwerthoedd yno gyda'r cadw = gwir faner - bydd hyn yn arbed y gwerth y tu mewn i'r brocer, a gellir ei dynnu allan ar unrhyw adeg, hyd yn oed pan fydd y cynorthwyydd cartref yn cael ei ailgychwyn. Fe wnes i gownteri bob awr a dyddiol ar unwaith.
- 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: lMae'r holl hud yn digwydd yn yr awtomeiddio, sy'n rhedeg bob awr a bob nos, yn y drefn honno.
- 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: trueMae'r ddau awtomeiddio yn gwneud 2 beth:
- Cyfrifwch y gwerth fesul cyfwng fel y gwahaniaeth rhwng y gwerth cychwyn a diwedd
- Diweddaru'r gwerth sylfaenol ar gyfer yr egwyl nesaf
Mae lluniad graffiau yn yr achos hwn yn cael ei ddatrys gan y graff hanes arferol:
- 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_dayMae'n edrych fel hyn:
Mewn egwyddor, dyma'r hyn sydd ei angen arnoch chi eisoes. Mantais y dull hwn yw bod y data yn cael ei gynhyrchu unwaith bob egwyl. Y rhai. cyfanswm o 24 cofnod y dydd ar gyfer y siart fesul awr.
Yn anffodus, nid yw hyn yn datrys y broblem gyffredinol o sylfaen gynyddol o hyd. Os ydw i eisiau graff defnydd misol, bydd yn rhaid i mi storio data am o leiaf blwyddyn. A chan fod cynorthwyydd cartref yn darparu dim ond un gosodiad hyd storio ar gyfer y gronfa ddata gyfan, mae hyn yn golygu y bydd yn rhaid storio POB data yn y system am flwyddyn gyfan. Er enghraifft, mewn blwyddyn rwy'n defnyddio 200 metr ciwbig o ddŵr, sy'n golygu 200000 o gofnodion yn y gronfa ddata. Ac os ydych chi'n ystyried synwyryddion eraill, yna mae'r ffigur yn gyffredinol yn dod yn anweddus.
Dull 3
Yn ffodus, mae pobl smart eisoes wedi datrys y broblem hon trwy ysgrifennu cronfa ddata InfluxDB. Mae'r gronfa ddata hon wedi'i optimeiddio'n arbennig ar gyfer storio data sy'n seiliedig ar amser ac mae'n ddelfrydol ar gyfer storio gwerthoedd gwahanol synwyryddion. Mae'r system hefyd yn darparu iaith ymholiad tebyg i SQL sy'n eich galluogi i dynnu gwerthoedd o'r gronfa ddata ac yna eu hagregu mewn gwahanol ffyrdd. Yn olaf, gellir storio data gwahanol ar gyfer gwahanol amseroedd. Er enghraifft, dim ond am ychydig wythnosau y gellir storio darlleniadau sy'n newid yn aml fel tymheredd neu leithder, tra gellir storio darlleniadau dyddiol o ddefnydd dŵr am flwyddyn gyfan.
Yn ogystal ag InfluxDB, dyfeisiodd pobl glyfar Grafana hefyd, system ar gyfer tynnu graffiau o ddata gan InfluxDB. Gall Grafana lunio gwahanol fathau o siartiau, eu haddasu'n fanwl, ac, yn bwysicaf oll, gellir “plygio” y siartiau hyn i'r cynorthwyydd cartref lovelace-UI.
cael eich ysbrydoli и . Mae'r erthyglau'n disgrifio'n fanwl y broses o osod a chysylltu InfluxDB a Grafana i gynorthwyydd cartref. Byddaf yn canolbwyntio ar ddatrys fy mhroblem benodol.
Felly, yn gyntaf oll, gadewch i ni ddechrau ychwanegu gwerth y cownter mewn influxDB. Darn o gyfluniad cynorthwyydd cartref (yn yr enghraifft hon, byddaf yn cael hwyl nid yn unig gydag oerfel, ond hefyd gyda dŵr poeth):
influxdb:
host: localhost
max_retries: 3
default_measurement: state
database: homeassistant
include:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldGadewch i ni analluogi arbed yr un data yng nghronfa ddata fewnol cynorthwywyr cartref, er mwyn peidio â'i chwyddo unwaith eto:
recorder:
purge_keep_days: 10
purge_interval: 1
exclude:
entities:
- sensor.water_meter_hot
- sensor.water_meter_coldGadewch i ni nawr fynd i'r consol InfluxDB a sefydlu ein cronfa ddata. Yn benodol, mae angen i chi ffurfweddu pa mor hir y bydd data penodol yn cael ei storio. Mae hyn yn cael ei reoleiddio gan yr hyn a elwir. polisi cadw - mae hwn yn debyg i gronfeydd data y tu mewn i'r brif gronfa ddata, gyda phob cronfa ddata fewnol â'i gosodiadau ei hun. Yn ddiofyn, mae'r holl ddata yn cael ei ychwanegu at y polisi cadw o'r enw autogen, bydd y data hwn yn cael ei storio am wythnos. Hoffwn i ddata fesul awr gael ei storio am fis, data wythnosol am flwyddyn, a data misol i beidio byth â chael eu dileu o gwbl. Byddwn yn creu polisïau cadw priodol
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 1Nawr, mewn gwirionedd, y prif gamp yw agregu data gan ddefnyddio ymholiad parhaus. Mae hwn yn fecanwaith sy'n lansio ymholiad yn awtomatig ar adegau penodol, yn cydgrynhoi'r data ar gyfer yr ymholiad hwn, ac yn ychwanegu'r canlyniad at werth newydd. Edrychwn ar enghraifft (rwy'n ysgrifennu mewn colofn ar gyfer darllenadwyedd, ond mewn gwirionedd roedd yn rhaid i mi nodi'r gorchymyn hwn ar un llinell)
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)
ENDMae'r gorchymyn hwn:
- Yn creu ymholiad parhaus o'r enw cq_water_cold_hourly yn y gronfa ddata cynorthwyydd cartref
- Bydd yr ymholiad yn cael ei weithredu bob awr (amser (1h))
- Bydd yr ymholiad yn tynnu allan yr holl ddata o fesur'a homeassistant.autogen.l (litr), gan gynnwys darlleniadau o ddŵr oer a dŵr poeth
- Bydd data cyfanredol yn cael ei grwpio fesul endid_id, a fydd yn creu gwerthoedd ar wahân ar gyfer dŵr oer a dŵr poeth.
- Gan fod y rhifydd litrau yn ddilyniant sy'n cynyddu'n undonog o fewn pob awr, bydd angen i chi gymryd y gwerth mwyaf, felly bydd y cydgasgliad yn cael ei wneud gan y ffwythiant uchaf (gwerth)
- Bydd y gwerth newydd yn cael ei ysgrifennu at homeassistant.month.water_meter_hour lle mis yw enw'r polisi cadw gyda chyfnod cadw o fis. Ar ben hynny, bydd data ar ddŵr oer a dŵr poeth yn cael ei wasgaru i gofnodion ar wahân gyda'r endid_id cyfatebol a'r gwerth yn y maes gwerth
Yn y nos neu pan nad oes neb gartref, nid oes unrhyw ddefnydd o ddŵr, ac yn unol â hynny nid oes cofnodion newydd yn homeassistant.autogen.l chwaith. Er mwyn osgoi gwerthoedd coll mewn ymholiadau arferol, gallwch ddefnyddio llenwi (blaenorol). Bydd hyn yn gorfodi InfluxDB i ddefnyddio'r gwerth awr ddiwethaf.
Yn anffodus, mae gan ymholiad parhaus hynodrwydd: nid yw'r tric llenwi (blaenorol) yn gweithio ac nid yw cofnodion yn cael eu creu. Ar ben hynny, mae hyn yn rhyw fath o broblem anorchfygol, sydd . Byddwn yn delio â'r broblem hon yn ddiweddarach, ac yn gadael i lenwi (blaenorol) yn ymholiad parhaus fod yno - nid yw'n ymyrryd.
Gadewch i ni wirio beth ddigwyddodd (wrth gwrs, mae angen i chi aros ychydig oriau):
> 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
Sylwch fod y gwerthoedd yn y gronfa ddata yn cael eu storio yn UTC, felly mae'r rhestr hon yn amrywio o 3 awr - mae'r gwerthoedd 7am yn allbwn InfluxDB yn cyd-fynd â'r gwerthoedd 10am yn y siartiau uchod. Sylwch hefyd nad oes unrhyw gofnodion rhwng 2 a 5 yn y bore - dyma union nodwedd ymholiad parhaus.
Fel y gwelwch, mae'r gwerth cyfanredol hefyd yn ddilyniant sy'n cynyddu'n undonog, dim ond y cofnodion sy'n llai aml - unwaith yr awr. Ond nid yw hyn yn broblem - gallwn ysgrifennu ymholiad arall a fydd yn tynnu'r data cywir ar gyfer y siart.
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)Byddaf yn dehongli:
- O'r gronfa ddata homeassistant.month.water_meter_hour, byddwn yn tynnu data ar gyfer endid_id='water_meter_cold' am y diwrnod olaf (amser >= nawr() -24h).
- Fel y soniais, efallai bod rhai cofnodion ar goll o'r dilyniant homeassistant.month.water_meter_hour. Byddwn yn adfywio'r data hwn trwy redeg yr ymholiad gyda GRWP ERBYN amser(1h). Y tro hwn, bydd llenwi (blaenorol) yn gweithio'n iawn, gan gynhyrchu'r data coll (bydd y swyddogaeth yn cymryd y gwerth blaenorol)
- Y peth pwysicaf yn yr ymholiad hwn yw'r ffwythiant gwahaniaeth, a fydd yn cyfrifo'r gwahaniaeth rhwng y marciau awr. Ar ei ben ei hun, nid yw'n gweithio ac mae angen swyddogaeth agregu. Gadewch i hwn fod yr uchafswm () a ddefnyddiwyd o'r blaen.
Mae canlyniad y dienyddiad yn edrych fel hyn
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 72O 2 am i 5 am (UTC) nid oedd unrhyw ddefnydd. Serch hynny, bydd yr ymholiad yn dychwelyd yr un gwerth defnydd diolch i lenwi (blaenorol), a bydd y swyddogaeth gwahaniaeth yn tynnu'r gwerth hwn ohono'i hun ac yn cael 0 ar yr allbwn, sydd ei angen mewn gwirionedd.
Yr unig beth sydd ar ôl i'w wneud yw adeiladu graff. I wneud hyn, agor Grafana, agor dangosfwrdd sy'n bodoli eisoes (neu greu dangosfwrdd newydd), creu panel newydd. Bydd gosodiadau'r siart fel a ganlyn.
Byddaf yn dangos data dŵr oer a dŵr poeth ar yr un graff. Mae'r cais yn union yr un fath ag a ddisgrifiais uchod.
Mae paramedrau arddangos wedi'u gosod fel a ganlyn. I mi bydd yn graff gyda llinellau (llinellau), sy'n mynd mewn grisiau (grisiau). Bydd y paramedr Stack yn cael ei esbonio isod. Mae yna ychydig mwy o opsiynau arddangos isod, ond nid ydyn nhw mor ddiddorol.
I ychwanegu'r graff canlyniadol at gynorthwyydd cartref, mae angen i chi:
- gadael y modd golygu siart. Am ryw reswm, dim ond o dudalen y dangosfwrdd y cynigir y gosodiadau rhannu siart cywir
- Cliciwch ar y triongl wrth ymyl enw'r siart, dewiswch Rhannu o'r ddewislen
- Yn y ffenestr sy'n agor, ewch i'r tab embed
- Dad-diciwch yr ystod amser gyfredol - byddwn yn gosod yr ystod amser trwy URL
- Dewiswch y pwnc gofynnol. Yn fy achos i, mae'n ysgafn
- Copïwch yr URL canlyniadol i'r cerdyn gosodiadau 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"
Sylwch fod yr ystod amser (2 ddiwrnod diwethaf) wedi'i gosod yma, ac nid yng ngosodiadau'r dangosfwrdd.
Mae'r siart yn edrych fel hyn. Nid wyf wedi defnyddio dŵr poeth yn ystod y 2 ddiwrnod diwethaf, felly dim ond graff o ddŵr oer sy'n cael ei lunio.
Nid wyf wedi penderfynu drosof fy hun pa siart yr wyf yn ei hoffi orau, llinell gam, neu fariau go iawn. Felly, yn syml, rhoddaf enghraifft o amserlen defnydd dyddiol, dim ond y tro hwn mewn bariau. Mae ymholiadau'n cael eu llunio yn yr un modd ag a ddisgrifir uchod. Yr opsiynau arddangos yw:
Mae'r siart hwn yn edrych fel hyn:
Felly, am y paramedr Stack. Yn y graff hwn, llunnir bar dŵr oer ar ben bar poeth. Mae cyfanswm yr uchder yn cyfateb i gyfanswm y defnydd o ddŵr oer a poeth ar gyfer y cyfnod.
Mae pob graff a ddangosir yn ddeinamig. Gallwch symud y llygoden dros y pwynt o ddiddordeb a gweld y manylion a'r gwerth ar bwynt penodol.
Yn anffodus, nid oedd heb gwpl o bryf yn yr eli. Ar siart bar (yn wahanol i'r graff gyda llinellau cam), nid yw canol y bar yng nghanol y dydd, ond ar 00:00. Y rhai. mae hanner chwith y bar yn cael ei dynnu yn lle'r diwrnod blaenorol. Felly mae'r siartiau ar gyfer dydd Sadwrn a dydd Sul yn cael eu tynnu ychydig i'r chwith o'r parth glasaidd. Nes i mi ddarganfod sut i'w hennill.
Problem arall yw'r anallu i weithio'n gywir gyda chyfnodau misol. Y ffaith yw bod hyd yr awr / diwrnod / wythnos yn sefydlog, ond mae hyd y mis yn wahanol bob tro. Dim ond gyda chyfnodau cyfartal y gall InfluxDB weithio. Hyd yn hyn, mae fy ymennydd wedi bod yn ddigon i osod egwyl sefydlog o 30 diwrnod. Bydd, bydd y siart yn arnofio ychydig yn ystod y flwyddyn ac ni fydd y bariau yn cyfateb yn union i'r misoedd. Ond gan fod y peth hwn yn ddiddorol i mi fel mesurydd arddangos, rwy'n iawn gyda hyn.
Rwy'n gweld o leiaf ddau ateb:
- I sgorio ar siartiau misol a chyfyngwch eich hun i rai wythnosol. Mae 52 bar wythnosol mewn blwyddyn yn edrych yn eithaf da
- Ystyriwch y defnydd misol ei hun fel dull Rhif 2, a defnyddiwch y grafana yn unig ar gyfer graffiau hardd. Mae'n ateb eithaf cywir. Gallwch hyd yn oed droshaenu siartiau ar gyfer y flwyddyn ddiwethaf er mwyn cymharu - gall grafana wneud hynny.
Casgliad
Nid wyf yn gwybod pam, ond rwyf wrth fy modd â'r mathau hyn o siartiau. Maent yn dangos bod bywyd yn ei anterth a phopeth yn newid. Ddoe roedd llawer, heddiw nid oes llawer, yfory bydd rhywbeth arall. Mae'n dal i fod i weithio gyda chartrefi ar y pwnc defnydd. Ond hyd yn oed gyda'r archwaeth gyfredol, dim ond ffigwr mawr ac annealladwy yn y bil sydd eisoes yn troi'n ddarlun eithaf dealladwy o ddefnydd.
Er gwaethaf fy ngyrfa bron i 20 mlynedd fel rhaglennydd, yn ymarferol nid oeddwn yn croestorri â chronfeydd data. Felly, roedd gosod cronfa ddata allanol yn ymddangos fel rhywbeth mor astrus ac annealladwy. Mae popeth wedi newid - mae'n troi allan bod sgriwio teclyn addas yn cael ei wneud mewn cwpl o gliciau, a chyda theclyn arbenigol, mae'r dasg o blotio yn dod ychydig yn haws.
Yn y teitl, soniais am y defnydd o drydan. Yn anffodus, ar hyn o bryd ni allaf ddarparu unrhyw graff. Mae un metr SDM120 wedi marw, a'r llall yn bygi pan gyrchir ato trwy Modbus. Fodd bynnag, nid yw hyn yn effeithio ar bwnc yr erthygl hon mewn unrhyw ffordd - bydd y graffiau'n cael eu hadeiladu yn yr un ffordd ag ar gyfer dŵr.
Yn yr erthygl hon, rwyf wedi rhoi'r dulliau hynny yr wyf wedi rhoi cynnig arnynt fy hun. Siawns nad oes rhai ffyrdd eraill o drefnu casglu a delweddu data nad wyf yn gwybod amdanynt. Dywedwch wrthyf amdano yn y sylwadau, bydd gennyf ddiddordeb mawr. Byddaf yn falch o gael beirniadaeth adeiladol a syniadau newydd. Rwy'n gobeithio y bydd y deunydd uchod yn helpu rhywun hefyd.
Ffynhonnell: hab.com