સ્માર્ટ હોમ: હોમ આસિસ્ટન્ટમાં પાણી અને વીજળીનો વપરાશ ચાર્ટિંગ

જ્યારે પણ મને વીજળી અને પાણી માટે ચૂકવણી મળે છે, ત્યારે મને આશ્ચર્ય થાય છે - શું મારું કુટુંબ ખરેખર આટલું બધું વાપરે છે? ઠીક છે, હા, બાથરૂમમાં ગરમ ​​​​ફ્લોર અને બોઈલર છે, પરંતુ તે હંમેશાં આગ સળગાવતા નથી. અમે પણ પાણીની બચત કરી રહ્યા હોવાનું જણાય છે (જોકે અમને બાથરૂમમાં છાંટા મારવાનું પણ ગમે છે). ઘણા વર્ષો પહેલા હું પહેલેથી જ કનેક્ટેડ વોટર મીટર и વીજળી સ્માર્ટ હોમ માટે, પરંતુ ત્યાં જ વસ્તુઓ અટકી ગઈ. આપણે હવે માત્ર વપરાશનું પૃથ્થકરણ કરવા માટે જ પહોંચી ગયા છીએ, જેના વિશે આ લેખ વાસ્તવમાં છે.

મેં તાજેતરમાં જ મારી સ્માર્ટ હોમ સિસ્ટમ તરીકે હોમ આસિસ્ટન્ટ પર સ્વિચ કર્યું છે. વિવિધ પ્રકારના આલેખને અનુકૂળ રીતે બાંધવાની ક્ષમતા સાથે મોટી માત્રામાં ડેટાના સંગ્રહને ગોઠવવાની ચોક્કસ તક એ એક કારણ હતું.

આ લેખમાં વર્ણવેલ માહિતી નવી નથી; વિવિધ ચટણીઓ હેઠળની આ બધી વસ્તુઓ ઇન્ટરનેટ પર પહેલેથી જ વર્ણવવામાં આવી છે. પરંતુ દરેક લેખ સામાન્ય રીતે માત્ર એક અભિગમ અથવા પાસાને વર્ણવે છે. મારે આ બધા અભિગમોની તુલના કરવી પડી અને મારી જાતે સૌથી યોગ્ય એક પસંદ કરવો પડ્યો. લેખ હજી પણ ડેટા સંગ્રહ પર વ્યાપક માહિતી પ્રદાન કરતું નથી, પરંતુ મેં તે કેવી રીતે કર્યું તેનો એક પ્રકારનો સારાંશ છે. તેથી રચનાત્મક ટીકા અને સુધારા માટેના સૂચનો આવકાર્ય છે.

સમસ્યાની રચના

તેથી, આજની કવાયતનો ધ્યેય પાણી અને વીજળીના વપરાશના સુંદર આલેખ મેળવવાનો છે:

• 2 દિવસ માટે કલાકદીઠ
• 2 અઠવાડિયા માટે દરરોજ
• (વૈકલ્પિક) સાપ્તાહિક અને માસિક

આમાં કેટલીક મુશ્કેલીઓ છે:

• માનક ચાર્ટ ઘટકો સામાન્ય રીતે ખૂબ નબળા હોય છે. શ્રેષ્ઠ રીતે, તમે બિંદુ દ્વારા રેખા ગ્રાફ બિંદુ બનાવી શકો છો.

  જો તમે સખત રીતે જોશો, તો તમે તૃતીય-પક્ષ ઘટકો શોધી શકો છો જે પ્રમાણભૂત ચાર્ટની ક્ષમતાઓને વિસ્તૃત કરે છે. ઘર સહાયક માટે, સૈદ્ધાંતિક રીતે, આ એક સારો અને સુંદર ઘટક છે મીની-ગ્રાફ કાર્ડ, પરંતુ તે અંશે મર્યાદિત પણ છે:

  • મોટા અંતરાલો પર બાર ચાર્ટના પરિમાણોને સેટ કરવું મુશ્કેલ છે (બારની પહોળાઈ એક કલાકના અપૂર્ણાંકમાં સેટ કરવામાં આવે છે, જેનો અર્થ છે કે એક કલાક કરતાં વધુ સમયના અંતરાલને અપૂર્ણાંક સંખ્યામાં સેટ કરવામાં આવશે)
  • તમે એક ગ્રાફમાં વિવિધ એન્ટિટી ઉમેરી શકતા નથી (ઉદાહરણ તરીકે, તાપમાન અને ભેજ, અથવા એક રેખા સાથે બાર ગ્રાફને જોડી શકો છો)
• માત્ર હોમ આસિસ્ટન્ટ ડિફોલ્ટ રૂપે સૌથી પ્રાચીન SQLite ડેટાબેઝનો ઉપયોગ કરતું નથી (અને હું, એક હેન્ડીમેન, MySQL અથવા Postgres ઇન્સ્ટોલ કરવાનું હેન્ડલ કરી શક્યો નથી), પરંતુ ડેટા સૌથી શ્રેષ્ઠ રીતે સંગ્રહિત થતો નથી. તેથી, ઉદાહરણ તરીકે, જ્યારે પણ તમે પેરામીટરના નાનામાં નાના ડિજીટલ પેરામીટરને પણ બદલો છો, ત્યારે ડેટાબેઝમાં લગભગ એક કિલોબાઈટનું વિશાળ json લખવામાં આવે છે.

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

  મારી પાસે ઘણા બધા સેન્સર છે (દરેક રૂમમાં તાપમાન સેન્સર, પાણી અને વીજળી મીટર), અને કેટલાક ઘણા બધા ડેટા પણ જનરેટ કરે છે. ઉદાહરણ તરીકે, એકલા SDM220 વીજળી મીટર દર 10-15 સેકન્ડમાં લગભગ એક ડઝન મૂલ્યો જનરેટ કરે છે, અને હું આવા લગભગ 8 મીટર ઇન્સ્ટોલ કરવા માંગુ છું. ત્યાં પણ પરિમાણોનો સંપૂર્ણ સમૂહ છે જેની ગણતરી અન્ય સેન્સરના આધારે કરવામાં આવે છે. તે. આ તમામ મૂલ્યો ડેટાબેઝને દરરોજ 100-200 MB દ્વારા સરળતાથી વધારી શકે છે. એક અઠવાડિયામાં સિસ્ટમ ભાગ્યે જ આગળ વધશે, અને એક મહિનામાં ફ્લેશ ડ્રાઇવ મરી જશે (રાસ્પબેરી પીઆઈ પર સામાન્ય હોમ આસિસ્ટન્ટ ઇન્સ્ટોલેશનના કિસ્સામાં), અને આખા વર્ષ માટે ડેટા સ્ટોર કરવાનો પ્રશ્ન નથી.

• જો તમે નસીબદાર છો, તો તમારું મીટર વપરાશની ગણતરી કરી શકે છે. તમે કોઈપણ સમયે મીટર તરફ વળી શકો છો અને પૂછી શકો છો કે સંચિત વપરાશ મૂલ્ય કયા સમયે છે. નિયમ પ્રમાણે, ડિજિટલ ઇન્ટરફેસ (RS232/RS485/Modbus/Zigbee) ધરાવતા તમામ વીજળી મીટર આ તક પૂરી પાડે છે.

  તે વધુ ખરાબ છે જો ઉપકરણ ફક્ત કેટલાક તાત્કાલિક પરિમાણને માપી શકે (ઉદાહરણ તરીકે, તાત્કાલિક પાવર અથવા વર્તમાન), અથવા ફક્ત દર X વોટ-કલાક અથવા લિટરે પલ્સ જનરેટ કરે. પછી તમારે તેને કેવી રીતે અને શું સાથે એકીકૃત કરવું અને મૂલ્ય ક્યાં એકઠા કરવું તે વિશે વિચારવાની જરૂર છે. કોઈપણ કારણોસર આગળનો રિપોર્ટ ગુમ થવાનું જોખમ રહેલું છે, અને એકંદરે સિસ્ટમની ચોકસાઈ પર પ્રશ્નો ઉભા થાય છે. તમે, અલબત્ત, હોમ આસિસ્ટન્ટ જેવી સ્માર્ટ હોમ સિસ્ટમને આ બધું સોંપી શકો છો, પરંતુ ડેટાબેઝમાં રેકોર્ડ્સની સંખ્યા વિશેના મુદ્દાને કોઈએ રદ કર્યો નથી, અને સેન્સર્સને એક સેકન્ડમાં એક કરતા વધુ વખત મતદાન કરવું શક્ય બનશે નહીં (એ. હોમ આસિસ્ટન્ટ આર્કિટેક્ચરની મર્યાદા).

અભિગમ 1

પ્રથમ, ચાલો જોઈએ કે ઘર સહાયક બૉક્સની બહાર શું પ્રદાન કરે છે. સમયગાળા દરમિયાન વપરાશને માપવા એ ખૂબ જ ઇચ્છિત કાર્યક્ષમતા છે. અલબત્ત, તે એક વિશિષ્ટ ઘટક - ઉપયોગિતા_મીટરના રૂપમાં લાંબા સમય પહેલા લાગુ કરવામાં આવ્યું હતું.

ઘટકનો સાર એ છે કે તે આંતરિક રીતે એક ચલ વર્તમાન_સંચિત_મૂલ્ય બનાવે છે અને તેને ચોક્કસ સમયગાળા (કલાક/અઠવાડિયું/મહિનો) પછી ફરીથી સેટ કરે છે. ઘટક પોતે ઇનપુટ વેરીએબલ (કેટલાક સેન્સરનું મૂલ્ય) નું નિરીક્ષણ કરે છે, મૂલ્યમાં ફેરફારો માટે પોતાને સબ્સ્ક્રાઇબ કરે છે - તમને ફક્ત સમાપ્ત પરિણામ મળે છે. આ વસ્તુ રૂપરેખાંકન ફાઈલમાં માત્ર થોડી લીટીઓમાં વર્ણવેલ છે

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

અહીં sensor.water_meter_cold એ લિટરમાં વર્તમાન મીટર મૂલ્ય છે જે મને મળે છે સીધા લોખંડના ટુકડામાંથી mqtt દ્વારા. આ ડિઝાઇન 2 નવા સેન્સર water_cold_hour_um અને water_cod_day_um બનાવે છે, જે કલાકદીઠ અને દૈનિક રીડિંગ એકઠા કરે છે, સમયગાળો સમાપ્ત થયા પછી તેને શૂન્ય પર ફરીથી સેટ કરે છે. અહીં અડધા દિવસ માટે કલાકદીઠ બેટરીનો ગ્રાફ છે.

લવલેસ-UI માટે કલાકદીઠ અને દૈનિક ચાર્ટ માટેનો કોડ આના જેવો દેખાય છે:

      - 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

વાસ્તવમાં, આ અભિગમની સમસ્યા આ અલ્ગોરિધમમાં રહેલી છે. મેં પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, દરેક ઇનપુટ મૂલ્ય (દરેક આગલા લિટર માટે વર્તમાન મીટર રીડિંગ) માટે ડેટાબેઝમાં 1kb રેકોર્ડ જનરેટ થાય છે. દરેક યુટિલિટી મીટર એક નવું મૂલ્ય પણ જનરેટ કરે છે, જે આધારમાં પણ ઉમેરવામાં આવે છે. જો હું કલાકદીઠ/દૈનિક/સાપ્તાહિક/માસિક રીડિંગ્સ એકત્રિત કરવા માંગુ છું, અને કેટલાક વોટર રાઈઝર માટે, અને ઇલેક્ટ્રિક મીટરનો પેક ઉમેરવા માંગુ છું, તો તે ઘણો ડેટા હશે. સારું, વધુ સ્પષ્ટ રીતે, ત્યાં ઘણો ડેટા નથી, પરંતુ હોમ આસિસ્ટન્ટ ડેટાબેઝમાં બિનજરૂરી માહિતીનો સમૂહ લખે છે, તેથી ડેટાબેઝનું કદ કૂદકે ને ભૂસકે વધશે. મને સાપ્તાહિક અને માસિક ચાર્ટ માટે આધારના કદનો અંદાજ કાઢવામાં પણ ડર લાગે છે.

વધુમાં, ઉપયોગિતા મીટર પોતે જ સમસ્યા હલ કરતું નથી. યુટિલિટી મીટર દ્વારા ઉત્પાદિત મૂલ્યોનો ગ્રાફ એ એકવિધ રીતે વધતું કાર્ય છે જે દર કલાકે 0 પર ફરીથી સેટ થાય છે. અમને વપરાશના ચાર્ટની જરૂર છે જે વપરાશકર્તાને સમજી શકાય, તે દર્શાવે છે કે સમયગાળા દરમિયાન કેટલા લિટરનો વપરાશ થયો હતો. પ્રમાણભૂત ઇતિહાસ-ગ્રાફ ઘટક આ કરી શકતું નથી, પરંતુ મીની-ગ્રાફ-કાર્ડ બાહ્ય ઘટક અમને મદદ કરી શકે છે.

આ લવલેસ-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'

સેન્સરનું નામ, ગ્રાફનો પ્રકાર, રંગ (મને પ્રમાણભૂત નારંગી પસંદ નથી) જેવી માનક સેટિંગ્સ ઉપરાંત, 3 સેટિંગ્સની નોંધ લેવી મહત્વપૂર્ણ છે:

• group_by:hour — કલાકની શરૂઆતમાં સંરેખિત બાર સાથે ગ્રાફ જનરેટ થશે
• પોઈન્ટ્સ_પર_કલાક: 1 - દરેક કલાક માટે એક બાર
• અને સૌથી અગત્યનું, aggregate_func: max - દરેક કલાકની અંદર મહત્તમ મૂલ્ય લો. તે આ પરિમાણ છે જે લાકડાંઈ નો વહેર ગ્રાફને બારમાં ફેરવે છે

ડાબી બાજુના કૉલમની પંક્તિ પર ધ્યાન આપશો નહીં - જો કોઈ ડેટા ન હોય તો આ ઘટકનું પ્રમાણભૂત વર્તન છે. પરંતુ ત્યાં કોઈ ડેટા ન હતો - મેં આ લેખ ખાતર થોડા કલાકો પહેલાં જ યુટિલિટી મીટર ડેટા સંગ્રહ ચાલુ કર્યો હતો (હું નીચે મારા વર્તમાન અભિગમનું વર્ણન કરીશ).

આ ચિત્રમાં હું બતાવવા માંગતો હતો કે કેટલીકવાર ડેટા ડિસ્પ્લે પણ કામ કરે છે અને બાર ખરેખર સાચા મૂલ્યોને પ્રતિબિંબિત કરે છે. પરંતુ તે બધુ જ નથી. કેટલાક કારણોસર, 11 થી 12 વાગ્યા સુધીના સમયગાળા માટે પસંદ કરેલ કૉલમ 19 લિટર દર્શાવે છે, જો કે સમાન સેન્સરથી સમાન સમયગાળા માટે દાંતના ગ્રાફ પર આપણે 62 લિટરનો વપરાશ જોઈએ છીએ. કાં તો બગ છે અથવા હાથ વાંકા છે. પરંતુ હું હજી પણ સમજી શકતો નથી કે જમણી બાજુનો ડેટા કેમ તૂટી ગયો - ત્યાં વપરાશ સામાન્ય હતો, જે દાંતના ગ્રાફમાંથી પણ દેખાય છે.

સામાન્ય રીતે, હું આ અભિગમની બુદ્ધિગમ્યતા પ્રાપ્ત કરવામાં અસમર્થ હતો - આલેખ લગભગ હંમેશા અમુક પ્રકારની પાખંડ દર્શાવે છે.

દિવસના સેન્સર માટે સમાન કોડ.

      - aggregate_func: max
        entities:
          - color: var(--primary-color)
            entity: sensor.water_cold_day_um
        group_by: interval
        hours_to_show: 360
        name: "Daily water consumption aggregated by utility meter"
        points_per_hour: 0.0416666666
        show:
          graph: bar
        type: 'custom:mini-graph-card'

મહેરબાની કરીને નોંધ કરો કે ગ્રુપ_બાય પેરામીટર અંતરાલ પર સેટ છે, અને પોઈન્ટ_પર_કલાક પરિમાણ દરેક વસ્તુનું નિયમન કરે છે. અને તેમાં આ ઘટક સાથે બીજી સમસ્યા છે - પોઈન્ટ્સ_પર_કલાક એક કલાક કે તેથી ઓછા સમયના ચાર્ટ પર સારી રીતે કામ કરે છે, પરંતુ તે મોટા અંતરાલોમાં અયોગ્ય છે. તેથી એક દિવસમાં એક કૉલમ મેળવવા માટે, મારે મૂલ્ય 1/24=0.04166666 દાખલ કરવું પડશે. હું સાપ્તાહિક અને માસિક ચાર્ટ વિશે પણ વાત કરતો નથી.

અભિગમ 2

હજુ પણ હોમ આસિસ્ટન્ટને સમજતી વખતે, મને આ વિડિયો મળ્યો:

એક મિત્ર ઘણા પ્રકારના Xiaomi સોકેટ્સમાંથી વપરાશ ડેટા એકત્રિત કરે છે. તેમનું કાર્ય થોડું સરળ છે - ફક્ત આજે, ગઈકાલ અને મહિના માટે વપરાશ મૂલ્ય દર્શાવો. કોઈ સમયપત્રક જરૂરી નથી.

ચાલો તાત્કાલિક પાવર મૂલ્યોના મેન્યુઅલ એકીકરણ વિશેની ચર્ચાઓને બાજુએ રાખીએ - મેં આ અભિગમની "ચોકસાઈ" વિશે પહેલેથી જ ઉપર લખ્યું છે. તે સ્પષ્ટ નથી કે તેણે સંચિત વપરાશ મૂલ્યોનો ઉપયોગ શા માટે કર્યો નથી, જે પહેલાથી સમાન આઉટલેટ દ્વારા એકત્રિત કરવામાં આવે છે. મારા મતે, હાર્ડવેરની અંદર એકીકરણ વધુ સારું કામ કરશે.

વિડિયોમાંથી આપણે સમયાંતરે વપરાશને મેન્યુઅલી ગણવાનો વિચાર લઈશું. વ્યક્તિ ફક્ત આજ અને ગઈકાલના મૂલ્યોની ગણતરી કરે છે, પરંતુ અમે આગળ જઈશું અને ગ્રાફ દોરવાનો પ્રયાસ કરીશું. મારા કિસ્સામાં સૂચિત પદ્ધતિનો સાર નીચે મુજબ છે.

ચાલો એક ચલ મૂલ્ય બનાવીએ_at_the_beginning_of_hour, જેમાં આપણે વર્તમાન મીટર રીડિંગ્સ રેકોર્ડ કરીશું
ટાઈમરનો ઉપયોગ કરીને, કલાકના અંતે (અથવા પછીની શરૂઆતમાં) અમે વર્તમાન વાંચન અને કલાકની શરૂઆતમાં સંગ્રહિત વચ્ચેના તફાવતની ગણતરી કરીએ છીએ. આ તફાવત વર્તમાન કલાક માટે વપરાશ હશે - અમે મૂલ્યને સેન્સરમાં સાચવીશું, અને ભવિષ્યમાં અમે આ મૂલ્યના આધારે ગ્રાફ બનાવીશું.
તમારે ત્યાં વર્તમાન કાઉન્ટર મૂલ્ય લખીને મૂલ્ય_at_beginning_of_hour વેરીએબલને "રીસેટ" કરવાની પણ જરૂર છે.

આ બધું હોમ આસિસ્ટન્ટ દ્વારા જ કરી શકાય છે.

તમારે અગાઉના અભિગમ કરતાં થોડો વધુ કોડ લખવો પડશે. પ્રથમ, ચાલો આ જ "ચલ" બનાવીએ. બોક્સની બહાર અમારી પાસે "ચલ" એન્ટિટી નથી, પરંતુ અમે mqtt બ્રોકરની સેવાઓનો ઉપયોગ કરી શકીએ છીએ. અમે ત્યાં retain=true ફ્લેગ સાથે મૂલ્યો મોકલીશું - આ બ્રોકરની અંદરના મૂલ્યને બચાવશે, અને તેને કોઈપણ સમયે ત્યાંથી ખેંચી શકાય છે, પછી ભલે હોમ આસિસ્ટન્ટ રીબૂટ થાય. મેં એક સાથે કલાકદીઠ અને દૈનિક કાઉન્ટર બનાવ્યા.

- platform: mqtt
  state_topic: "test/water/hour"
  name: water_hour
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/hour_begin"
  name: water_hour_begin
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day"
  name: water_day
  unit_of_measurement: l

- platform: mqtt
  state_topic: "test/water/day_begin"
  name: water_day_begin
  unit_of_measurement: l

તમામ જાદુ ઓટોમેશનમાં થાય છે, જે અનુક્રમે દર કલાકે અને દરેક રાત્રે ચાલે છે.

- id: water_new_hour
  alias: water_new_hour
  initial_state: true
  trigger:
    - platform: time_pattern
      minutes: 0
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/hour"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_hour_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/hour_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

- id: water_new_day
  alias: water_new_day
  initial_state: true
  trigger:
    - platform: time
      at: "00:00:00"
  action:
    - service: mqtt.publish
      data:
        topic: "test/water/day"
        payload_template: >
          {{ (states.sensor.water_meter_cold.state|int) - (states.sensor.water_day_begin.state|int) }}
        retain: true
    - service: mqtt.publish
      data:
        topic: "test/water/day_begin"
        payload_template: >
          {{ states.sensor.water_meter_cold.state }}
        retain: true

બંને ઓટોમેશન 2 ક્રિયાઓ કરે છે:

• પ્રારંભ અને અંતિમ મૂલ્યો વચ્ચેના તફાવત તરીકે અંતરાલ માટેના મૂલ્યની ગણતરી કરો
• આગલા અંતરાલ માટે મૂળ મૂલ્ય અપડેટ કરો

આ કિસ્સામાં ગ્રાફનું નિર્માણ સામાન્ય ઇતિહાસ-ગ્રાફ દ્વારા ઉકેલવામાં આવે છે:

      - type: history-graph
        title: 'Hourly water consumption using vars'
        hours_to_show: 48
        entities:
          - sensor.water_hour

      - type: history-graph
        title: 'Daily water consumption using vars'
        hours_to_show: 360
        entities:
          - sensor.water_day

તે આના જેવું દેખાય છે:

સૈદ્ધાંતિક રીતે, આ પહેલેથી જ જરૂરી છે. આ પદ્ધતિનો ફાયદો એ છે કે દરેક અંતરાલમાં એકવાર ડેટા જનરેટ થાય છે. તે. એક કલાકના ચાર્ટ માટે દરરોજ માત્ર 24 રેકોર્ડ્સ.

કમનસીબે, આ હજુ પણ વધતા આધારની સામાન્ય સમસ્યાને હલ કરતું નથી. જો મને માસિક વપરાશનો ગ્રાફ જોઈતો હોય, તો મારે ઓછામાં ઓછા એક વર્ષ માટે ડેટા સ્ટોર કરવો પડશે. અને હોમ આસિસ્ટન્ટ સમગ્ર ડેટાબેઝ માટે માત્ર એક જ સ્ટોરેજ અવધિ સેટિંગ પ્રદાન કરે છે, આનો અર્થ એ છે કે સિસ્ટમમાંનો તમામ ડેટા આખા વર્ષ માટે સંગ્રહિત કરવો પડશે. ઉદાહરણ તરીકે, એક વર્ષમાં હું 200 ક્યુબિક મીટર પાણીનો વપરાશ કરું છું, જેનો અર્થ છે કે ડેટાબેઝમાં આનો અર્થ 200000 એન્ટ્રીઓ છે. અને જો તમે અન્ય સેન્સર્સને ધ્યાનમાં લો, તો આકૃતિ સામાન્ય રીતે અભદ્ર બની જાય છે.

અભિગમ 3

સદભાગ્યે, સ્માર્ટ લોકોએ પહેલેથી જ InfluxDB ડેટાબેઝ લખીને આ સમસ્યા હલ કરી દીધી છે. આ ડેટાબેઝ ખાસ કરીને સમય-આધારિત ડેટા સ્ટોર કરવા માટે ઑપ્ટિમાઇઝ કરવામાં આવ્યો છે અને વિવિધ સેન્સરના મૂલ્યોને સ્ટોર કરવા માટે આદર્શ છે. સિસ્ટમ એસક્યુએલ જેવી ક્વેરી લેંગ્વેજ પણ પ્રદાન કરે છે જે તમને ડેટાબેઝમાંથી મૂલ્યો કાઢવા અને પછી તેને વિવિધ રીતે એકત્રિત કરવાની મંજૂરી આપે છે. છેલ્લે, જુદા જુદા સમય માટે અલગ અલગ ડેટા સ્ટોર કરી શકાય છે. ઉદાહરણ તરીકે, વારંવાર બદલાતા રીડિંગ્સ જેમ કે તાપમાન અથવા ભેજ માત્ર થોડા અઠવાડિયા માટે સંગ્રહિત કરી શકાય છે, જ્યારે દૈનિક પાણીના વપરાશના રીડિંગ્સને આખા વર્ષ માટે સંગ્રહિત કરી શકાય છે.

InfluxDB ઉપરાંત, સ્માર્ટ લોકોએ Grafana ની પણ શોધ કરી, જે InfluxDB ના ડેટાના આધારે ગ્રાફ દોરવા માટેની સિસ્ટમ છે. Grafana વિવિધ પ્રકારના ગ્રાફ દોરી શકે છે, તેમને વિગતવાર કસ્ટમાઇઝ કરી શકે છે અને, સૌથી અગત્યનું, આ ગ્રાફ લવલેસ-UI હોમ આસિસ્ટન્ટ પર "પ્લગ" કરી શકાય છે.

પ્રેરણા મળી અહીં и અહીં. લેખો InfluxDB અને Grafana ને હોમ આસિસ્ટન્ટને ઇન્સ્ટોલ અને કનેક્ટ કરવાની પ્રક્રિયાનું વિગતવાર વર્ણન કરે છે. હું મારી ચોક્કસ સમસ્યાને ઉકેલવા પર ધ્યાન કેન્દ્રિત કરીશ.

તો, સૌ પ્રથમ, ચાલો influxDB માં કાઉન્ટર વેલ્યુ ઉમેરવાનું શરૂ કરીએ. હોમ આસિસ્ટન્ટ રૂપરેખાંકનનો એક ભાગ (આ ઉદાહરણમાં હું માત્ર ઠંડા જ નહીં, પણ ગરમ પાણી સાથે પણ મજા કરીશ):

influxdb:
  host: localhost
  max_retries: 3
  default_measurement: state
  database: homeassistant
  include:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

ચાલો આ જ ડેટાને આંતરિક હોમ આસિસ્ટન્ટ ડેટાબેઝમાં સાચવવાનું અક્ષમ કરીએ જેથી કરીને તેને ફરીથી ખીલે નહીં:

recorder:
  purge_keep_days: 10
  purge_interval: 1
  exclude:
    entities:
      - sensor.water_meter_hot
      - sensor.water_meter_cold

ચાલો હવે InfluxDB કન્સોલ પર જઈએ અને અમારા ડેટાબેઝને ગોઠવીએ. ખાસ કરીને, તમારે ચોક્કસ ડેટા કેટલો સમય સંગ્રહિત કરવામાં આવશે તે ગોઠવવાની જરૂર છે. આ કહેવાતા દ્વારા નિયંત્રિત થાય છે. રીટેન્શન પોલિસી - આ મુખ્ય ડેટાબેઝની અંદરના ડેટાબેસેસ જેવું જ છે, જેમાં દરેક આંતરિક ડેટાબેઝની પોતાની સેટિંગ્સ હોય છે. ડિફૉલ્ટ રૂપે, તમામ ડેટા ઓટોજેન નામની રીટેન્શન પોલિસીમાં સંગ્રહિત થાય છે; આ ડેટા એક અઠવાડિયા માટે સંગ્રહિત કરવામાં આવશે. હું ઇચ્છું છું કે કલાકદીઠ ડેટા એક મહિના માટે રાખવામાં આવે, સાપ્તાહિક ડેટા એક વર્ષ માટે રાખવામાં આવે અને માસિક ડેટા ક્યારેય ડિલીટ ન થાય. ચાલો યોગ્ય રીટેન્શન પોલિસી બનાવીએ

CREATE RETENTION POLICY "month" ON "homeassistant" DURATION 30d REPLICATION 1
CREATE RETENTION POLICY "year" ON "homeassistant" DURATION 52w REPLICATION 1
CREATE RETENTION POLICY "infinite" ON "homeassistant" DURATION INF REPLICATION 1

હવે, હકીકતમાં, મુખ્ય યુક્તિ સતત ક્વેરીનો ઉપયોગ કરીને ડેટા એકત્રીકરણ છે. આ એક મિકેનિઝમ છે જે આપમેળે નિર્દિષ્ટ અંતરાલો પર ક્વેરી ચલાવે છે, આ ક્વેરી માટેના ડેટાને એકત્ર કરે છે અને પરિણામને નવા મૂલ્યમાં ઉમેરે છે. ચાલો એક ઉદાહરણ જોઈએ (હું વાંચનક્ષમતા માટે કૉલમમાં લખું છું, પરંતુ વાસ્તવમાં મારે આ આદેશ એક લીટીમાં દાખલ કરવો પડ્યો હતો)

CREATE CONTINUOUS QUERY cq_water_hourly ON homeassistant 
BEGIN 
  SELECT max(value) AS value 
  INTO homeassistant.month.water_meter_hour 
  FROM homeassistant.autogen.l 
  GROUP BY time(1h), entity_id fill(previous) 
END

આ આદેશ:

• હોમસિસ્ટન્ટ ડેટાબેઝમાં cq_water_cold_hourly નામની સતત ક્વેરી બનાવે છે
• વિનંતી દર કલાકે ચલાવવામાં આવશે (સમય(1 કલાક))
• વિનંતિ માપન' homeassistant.autogen.l (લિટર) ના તમામ ડેટાને સ્ક્રેપ કરશે, જેમાં ઠંડા અને ગરમ પાણીના રીડિંગ્સનો સમાવેશ થાય છે.
• એકીકૃત ડેટાને entity_id દ્વારા જૂથબદ્ધ કરવામાં આવશે, જે અમને ઠંડા અને ગરમ પાણી માટે અલગ-અલગ મૂલ્યો આપશે
• લિટર કાઉન્ટર દરેક કલાકમાં એકવિધ રીતે વધતો ક્રમ હોવાથી, મહત્તમ મૂલ્ય લેવું જરૂરી છે, તેથી એકત્રીકરણ કાર્ય મહત્તમ(મૂલ્ય) દ્વારા હાથ ધરવામાં આવશે.
• નવું મૂલ્ય homeassistant.month.water_meter_hour પર લખવામાં આવશે, જ્યાં મહિનો એક મહિનાના રીટેન્શન સમયગાળા સાથે રીટેન્શન પોલિસીનું નામ છે. વધુમાં, ઠંડા અને ગરમ પાણી પરના ડેટાને સંબંધિત એન્ટિટી_આઈડી અને મૂલ્ય ફીલ્ડમાં મૂલ્ય સાથે અલગ રેકોર્ડમાં વેરવિખેર કરવામાં આવશે.

રાત્રે અથવા જ્યારે કોઈ ઘરે ન હોય, ત્યારે પાણીનો વપરાશ થતો નથી, અને તેથી homeassistant.autogen.l માં કોઈ નવી એન્ટ્રીઓ નથી. નિયમિત ક્વેરીઝમાં ગુમ થયેલ મૂલ્યોને ટાળવા માટે, તમે fill(pvious) નો ઉપયોગ કરી શકો છો. આ InfluxDB ને છેલ્લા કલાકના મૂલ્યનો ઉપયોગ કરવા દબાણ કરશે.

કમનસીબે, સતત ક્વેરી એક વિશિષ્ટતા ધરાવે છે: ભરણ(અગાઉની) યુક્તિ કામ કરતી નથી અને રેકોર્ડ્સ ફક્ત બનાવવામાં આવતાં નથી. તદુપરાંત, આ એક પ્રકારની દુસ્તર સમસ્યા છે જે ઘણા વર્ષોથી ચર્ચા થઈ રહી છે. અમે પછીથી આ સમસ્યાનો સામનો કરીશું, પરંતુ સતત ક્વેરી માં fill(previous) રહેવા દો - તે દખલ કરતું નથી.

ચાલો તપાસ કરીએ કે શું થયું (અલબત્ત, તમારે થોડા કલાકો રાહ જોવી પડશે):

> 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

નોંધ કરો કે ડેટાબેઝના મૂલ્યો UTCમાં સંગ્રહિત છે, તેથી આ સૂચિ 3 કલાકથી અલગ છે - InfluxDB આઉટપુટમાં 7am ની કિંમતો ઉપરના ગ્રાફમાં 10am ની કિંમતોને અનુરૂપ છે. એ પણ નોંધ કરો કે સવારે 2 થી 5 વાગ્યાની વચ્ચે કોઈ રેકોર્ડ નથી - આ સતત ક્વેરીનું સમાન લક્ષણ છે.

જેમ તમે જોઈ શકો છો, એકીકૃત મૂલ્ય પણ એકવિધ રીતે વધતો ક્રમ છે, માત્ર એન્ટ્રીઓ ઓછી વાર થાય છે - કલાક દીઠ એકવાર. પરંતુ આ કોઈ સમસ્યા નથી - અમે બીજી ક્વેરી લખી શકીએ છીએ જે ગ્રાફ માટે યોગ્ય ડેટા પુનઃપ્રાપ્ત કરશે.

SELECT difference(max(value)) 
FROM homeassistant.month.water_meter_hour 
WHERE entity_id='water_meter_cold' and time >= now() -24h 
GROUP BY time(1h), entity_id 
fill(previous)

હું ડિસિફર કરીશ:

• homeassistant.month.water_meter_hour ડેટાબેઝમાંથી અમે છેલ્લા દિવસ માટે entity_id='water_meter_cold' માટે ડેટા કાઢીશું (સમય >= હવે() -24 કલાક).
• મેં પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, homeassistant.month.water_meter_hour ક્રમમાં કેટલીક એન્ટ્રીઓ ખૂટે છે. અમે GROUP BY time(1h) સાથે ક્વેરી ચલાવીને આ ડેટાને ફરીથી બનાવીશું. આ સમય ભરણ (અગાઉની) અપેક્ષા મુજબ કામ કરશે, ખૂટતો ડેટા જનરેટ કરશે (ફંક્શન અગાઉનું મૂલ્ય લેશે)
• આ વિનંતીમાં સૌથી મહત્વની વસ્તુ તફાવત કાર્ય છે, જે કલાકના ગુણ વચ્ચેના તફાવતની ગણતરી કરશે. તે તેના પોતાના પર કામ કરતું નથી અને એકત્રીકરણ કાર્યની જરૂર છે. આ પહેલા વપરાતો મહત્તમ() રહેવા દો.

અમલનું પરિણામ આના જેવું લાગે છે

name: water_meter_hour
tags: entity_id=water_meter_cold
time                 difference
----                 ----------
...
2020-03-08T02:00:00Z 2
2020-03-08T03:00:00Z 0
2020-03-08T04:00:00Z 0
2020-03-08T05:00:00Z 14
2020-03-08T06:00:00Z 78
2020-03-08T07:00:00Z 30
2020-03-08T08:00:00Z 64
2020-03-08T09:00:00Z 62
2020-03-08T10:00:00Z 6
2020-03-08T11:00:00Z 43
2020-03-08T12:00:00Z 8
2020-03-08T13:00:00Z 9
2020-03-08T14:00:00Z 22
2020-03-08T15:00:00Z 72

2 થી 5 am (UTC) સુધી કોઈ વપરાશ ન હતો. તેમ છતાં, ક્વેરી ફીલ(અગાઉ) માટે આભાર સમાન વપરાશ મૂલ્ય પરત કરશે, અને તફાવત કાર્ય આ મૂલ્યને પોતાનામાંથી બાદ કરશે અને આઉટપુટ 0 હશે, જે જરૂરી છે તે બરાબર છે.

જે બાકી છે તે ગ્રાફ બનાવવાનું છે. આ કરવા માટે, Grafana ખોલો, કેટલાક અસ્તિત્વમાં છે (અથવા નવું બનાવો) ડેશબોર્ડ ખોલો અને નવી પેનલ બનાવો. ચાર્ટ સેટિંગ્સ આ પ્રમાણે હશે.

હું સમાન ગ્રાફ પર ઠંડા અને ગરમ પાણીનો ડેટા પ્રદર્શિત કરીશ. વિનંતી બરાબર એ જ છે જેમ મેં ઉપર વર્ણવ્યું છે.

ડિસ્પ્લે પેરામીટર નીચે પ્રમાણે સેટ કરેલ છે. મારા માટે તે લીટીઓ સાથેનો ગ્રાફ હશે, જે પગલાઓ (સીડીઓ) માં જાય છે. હું નીચે સ્ટેક પેરામીટર સમજાવીશ. નીચે કેટલાક વધુ પ્રદર્શન વિકલ્પો છે, પરંતુ તે એટલા રસપ્રદ નથી.

હોમ આસિસ્ટન્ટમાં પરિણામી ચાર્ટ ઉમેરવા માટે તમારે આની જરૂર છે:

• ચાર્ટ સંપાદન મોડમાંથી બહાર નીકળો. કેટલાક કારણોસર, યોગ્ય ચાર્ટ શેરિંગ સેટિંગ્સ ફક્ત ડેશબોર્ડ પૃષ્ઠ પરથી જ ઓફર કરવામાં આવે છે
• ચાર્ટના નામની બાજુના ત્રિકોણ પર ક્લિક કરો અને મેનુમાંથી શેર પસંદ કરો
• ખુલતી વિંડોમાં, એમ્બેડ ટેબ પર જાઓ
• વર્તમાન સમય શ્રેણીને અનચેક કરો - અમે URL દ્વારા સમય શ્રેણી સેટ કરીશું
• જરૂરી વિષય પસંદ કરો. મારા કિસ્સામાં તે પ્રકાશ છે
• પરિણામી URL ને 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"

મહેરબાની કરીને નોંધ કરો કે સમય શ્રેણી (છેલ્લા 2 દિવસ) અહીં સેટ છે, ડેશબોર્ડ સેટિંગ્સમાં નહીં.

ગ્રાફ આના જેવો દેખાય છે. મેં છેલ્લા 2 દિવસમાં ગરમ ​​પાણીનો ઉપયોગ કર્યો નથી, તેથી માત્ર ઠંડા પાણીનો ગ્રાફ દોરવામાં આવ્યો છે.

મેં હજી પણ મારા માટે નક્કી કર્યું નથી કે મને કયો ગ્રાફ વધુ ગમે છે, લાઇન-સ્ટેપ અથવા વાસ્તવિક બાર. તેથી, હું ફક્ત આ વખતે બારમાં દૈનિક વપરાશના ચાર્ટનું ઉદાહરણ આપીશ. ક્વેરી ઉપર વર્ણવેલ સમાન રીતે બનાવવામાં આવે છે. પ્રદર્શન વિકલ્પો છે:

આ ગ્રાફ આના જેવો દેખાય છે:

તો સ્ટેક પેરામીટર વિશે. આ ગ્રાફમાં, ગરમ પાણીના સ્તંભની ટોચ પર ઠંડા પાણીનો સ્તંભ દોરવામાં આવ્યો છે. કુલ ઊંચાઈ સમયગાળા માટે ઠંડા અને ગરમ પાણીના કુલ વપરાશને અનુરૂપ છે.

બતાવેલ તમામ ગ્રાફ ડાયનેમિક છે. તમે તમારા માઉસને રુચિના બિંદુ પર ફેરવી શકો છો અને ચોક્કસ બિંદુ પર વિગતો અને મૂલ્ય જોઈ શકો છો.

કમનસીબે, મલમ માં ફ્લાય એક દંપતિ હતા. બાર ચાર્ટ પર (સ્ટેપ લાઇન સાથેના ચાર્ટથી વિપરીત), બારની મધ્ય દિવસની મધ્યમાં નથી, પરંતુ 00:00 વાગ્યે છે. તે. કૉલમનો ડાબો અડધો ભાગ પાછલા દિવસની જગ્યાએ દોરવામાં આવ્યો છે. તેથી શનિવાર અને રવિવારના ગ્રાફ બ્લુશ ઝોનની ડાબી બાજુએ સહેજ દોરવામાં આવ્યા છે. જ્યાં સુધી હું તેને કેવી રીતે હરાવવા તે સમજી શક્યો નહીં.

બીજી સમસ્યા માસિક અંતરાલો પર યોગ્ય રીતે કામ કરવામાં અસમર્થતા છે. હકીકત એ છે કે કલાક/દિવસ/સપ્તાહની લંબાઈ નિશ્ચિત છે, પરંતુ દર વખતે મહિનાની લંબાઈ અલગ-અલગ હોય છે. InfluxDB માત્ર સમાન અંતરાલો પર કામ કરી શકે છે. અત્યાર સુધી મારું મગજ 30 દિવસનું નિશ્ચિત અંતરાલ સેટ કરવા માટે પૂરતું છે. હા, ગ્રાફ આખા વર્ષ દરમિયાન થોડો તરતો રહેશે અને બાર મહિનાઓ સાથે બરાબર અનુરૂપ રહેશે નહીં. પરંતુ મને આ વસ્તુમાં ફક્ત ડિસ્પ્લે મીટર તરીકે રસ હોવાથી, હું તેની સાથે ઠીક છું.

હું ઓછામાં ઓછા બે ઉકેલો જોઉં છું:

• માસિક ચાર્ટ્સ છોડી દો અને તમારી જાતને સાપ્તાહિક સુધી મર્યાદિત કરો. વર્ષ માટે 52 સાપ્તાહિક બાર ખૂબ સારા લાગે છે
• માસિક વપરાશને જ પદ્ધતિ નંબર 2 તરીકે ધ્યાનમાં લો અને માત્ર સુંદર આલેખ માટે ગ્રાફનાનો ઉપયોગ કરો. તે એકદમ સચોટ ઉકેલ હશે. તમે સરખામણી માટે પાછલા વર્ષના ગ્રાફને પણ ઓવરલે કરી શકો છો - ગ્રાફના તે પણ કરી શકે છે.

નિષ્કર્ષ

મને ખબર નથી કે શા માટે, પરંતુ હું આ પ્રકારના ગ્રાફ્સથી ભ્રમિત છું. તેઓ દર્શાવે છે કે જીવન પૂરજોશમાં છે અને બધું બદલાઈ રહ્યું છે. ગઈકાલે ઘણું હતું, આજે થોડું છે, કાલે કંઈક બીજું હશે. જે બાકી છે તે વપરાશના વિષય પર ઘરના સભ્યો સાથે કામ કરવાનું છે. પરંતુ વર્તમાન ભૂખ સાથે પણ, ચુકવણી સ્લિપ પર માત્ર એક મોટો અને અગમ્ય આંકડો પહેલેથી જ વપરાશના એકદમ સમજી શકાય તેવા ચિત્રમાં ફેરવાઈ રહ્યો છે.

પ્રોગ્રામર તરીકે મારી લગભગ 20 વર્ષની કારકિર્દી હોવા છતાં, ડેટાબેઝ સાથે મારો વર્ચ્યુઅલ રીતે કોઈ સંપર્ક નહોતો. તેથી, બાહ્ય ડેટાબેઝ ઇન્સ્ટોલ કરવું કંઈક અસ્પષ્ટ અને અગમ્ય જેવું લાગતું હતું. બધું બદલી નાખ્યું ઉપરનો લેખ - તે બહાર આવ્યું છે કે યોગ્ય ટૂલને જોડવાનું થોડા ક્લિક્સમાં કરવામાં આવે છે, અને વિશિષ્ટ સાધન સાથે, ચાર્ટ બનાવવાનું કાર્ય થોડું સરળ બને છે.

શીર્ષકમાં મેં વીજળીના વપરાશનો ઉલ્લેખ કર્યો છે. કમનસીબે, આ ક્ષણે હું કોઈ ગ્રાફ આપી શકતો નથી. એક SDM120 મીટર મારા માટે મૃત્યુ પામ્યો, અને જ્યારે Modbus દ્વારા એક્સેસ કરવામાં આવે ત્યારે બીજું ગ્લીચી છે. જો કે, આ આ લેખના વિષયને કોઈપણ રીતે અસર કરતું નથી - આલેખ પાણી માટે તે જ રીતે બનાવવામાં આવશે.

આ લેખમાં મેં તે અભિગમો રજૂ કર્યા જે મેં મારી જાતે અજમાવ્યાં. ચોક્કસ ડેટા સંગ્રહ અને વિઝ્યુલાઇઝેશનને ગોઠવવાની કેટલીક અન્ય રીતો છે જેના વિશે હું જાણતો નથી. ટિપ્પણીઓમાં મને તેના વિશે કહો, મને ખૂબ જ રસ હશે. રચનાત્મક ટીકા અને નવા વિચારોથી મને આનંદ થશે. મને આશા છે કે પ્રસ્તુત સામગ્રી પણ કોઈને મદદ કરશે.

સોર્સ: www.habr.com