SCOPI DEL PROGETTO:
CONCETTI AFFRONTATI:
|
COMPONENTI SOFTWARE UTILIZZATE:
PREREQUISITI:
DISPOSITIVI FISICI UTILIZZATI:
|
GUIDA INDICATA A UTENTI CON ISTALLAZIONE: |
|
NOTE E DISCLAIMER
|
|
Revisione progetto: 1.3 |
Abstract
Uno degli aspetti più affascinanti della domotica personale è quello di dotarsi di innumerevoli sensori in grado di rilevare lo stato istantaneo del nostro ambiente. Sensori termici, di presenza e movimento, di allagamento, di presenza fumi, di apertura varchi: chi più ne ha, più ne metta. Senza considerare poi quelli virtuali, come quelli legati al meteo, alla qualità dell’aria e molto altro.
Home Assistant, in questo, ci supporta pienamente tramite il componente “Sensor“, il quale, tramite le piattaforme ad esso collegate, ci permette di definire entità di diversa natura a partire dall’integrazione di componenti fisiche o virtuali. Alcune di queste entità possono fornirci le letture istantanee relative ad assorbimenti di varia natura: assorbimenti elettrici, di gas, acqua e molto altro ancora.
In termini di potenza ed energia, parliamo genericamente di tutti gli interruttori intelligenti dotati di lettura istantanea di assorbimento elettrico e che siano integrabili a Home Assistant – vedi lista. In tale ambito, un componente di Home Assistant torna particolarmente utile nella gestione della contabilizzazione di energia: si tratta del componente “Utility Meter“, componete concepito esplicitamente per generare una tipologia specifica di entità sensore, ovvero “i contatori di consumo”.
Esattamente come un contatore elettrico, del gas, dell’acqua o di altra natura misura un dato consumo, queste entità tengono traccia degli assorbimenti segnalati da sensori (numerici) pre-esistenti. Basterà infatti definire un’entità di tipo “Utility Meter”, indicandogli quale sensore monitorare, per tenere sotto controllo i consumi da esso comunicati.
Questo piccolo progetto, revisione del precedessore, illustra la logica di contabilizzazione, specie in presenza, per esempio, di tariffe a fasce biorarie o triorarie, consentendo all’utente di monitorare gli assorbimenti per le varie fasce di costo e fatturazione tramite l’HUB personale Home Assistant. Ovviamente, il progetto è valevole anche per le tariffazioni monorarie.
Si parte
Sensori
Va da sé che il sensore da contabilizzare debba essere un sensore numerico (è indifferente che sia a valore intero o decimale): sensori di altro tipo (ad esempio un sensore che riporti stringhe nel proprio stato) non possono essere “contabilizzati” per ovvi motivi.
Inoltre è necessario che il sensore scelto fornisca dati incrementali: l’entità contabilizzatrice che andremo a definire considererà infatti solo valori a crescere, e non valori altalenanti. Un sensore termico, che fornisce dati appunto variabili, non è indicato per la contabilizzazione.
Immaginiamo dunque di avere su Home Assistant un sensore di energia (espresso in kWh) chiamato “sensor.assorbimento_oggi“, magari ottenuto tramite l’integrazione di un misuratore a monte dell’impianto (come per esempio uno Shelly EM, oppure uno PZEM).
Riassumendo:
- i sensori di potenza danno indicazione di potenza istantanea in Watt;
- i sensori di energia danno indicazione di assorbimento su lasso di tempo (eg. kWh) limitato (solitamente giornaliero). Tali sensori possono essere realizzati utilizzando il component “Integration – Riemann sum integral” il quale, alimentato dal sensore di potenza, calcola tramite integrale l’assorbimento su lasso di tempo. Talvolta, invece, tali sensori sono disponibili direttamente tramite l’integrazione dei componenti domotici;
- i sensori di contabilizzazione generati con “Utility Meter” (oggetto del presente progetto) danno indicazione di consumo su lassi di tempo lunghi e su diverse fasce di fatturazione/costo).
N.b. Per lo più alcune integrazioni forniscono automaticamente sia sensori di potenza (in watt) che di energia (kWh). Il presente progetto assume che l’utente disponga dei sensori di energia necessari alla contabilizzazione; qualora così non fosse – perché la propria integrazione non li metta a disposizione – ecco spiegato un modo per definirne in proprio partendo dai “semplici” sensori di potenza. |
Come funziona “Utility Meter”
“Utility Meter” è un componente di Home Assistant dal funzionamento un po’ particolare, talvolta ostico da esser capito al volo in quanto abbastanza diverso dal solito comportamento degli altri componenti. Cercheremo di spiegarci in parole povere ma il più possibile chiare.
L’adozione di tale componente prevede una configurazione manuale sul file YAML di Home Assistant tale da:
- creare (sempre) tante entità di tipo “Sensor”, quante sono le fasce di fatturazione/contabilizzazione (una sola, se è fascia unica), contenenti nel proprio stato il montante di consumo;
- in caso siano presenti più fasce, anche una entità di tipo “Utility Meter” che riporti, nel suo stato, la fascia di fatturazione/contabilizzazione in essere. Diversamente, tale entità non viene creata.
“Utility Meter” prevede, inoltre, la possibilità di definire “il ciclo”, ovvero ogni quanto la contabilizzazione viene azzerata per essere fatta ripartire. Nei nostri esempi assumeremo che sia mensile (monthly), quando comunque il parametro cycle che definisce il ciclo può essere valorizzato a:
- quarter-hourly
- hourly
- daily
- weekly
- monthly
- bimonthly
- quarterly
- yearly
Al termine del ciclo di contabilizzazione (indipendentemente dalla durata impostata) il valore dell’entità “Utility Meter” viene azzerato e il valore totale del ciclo terminato viene salvato nell’attributo “last_period“, permettendoci di effettuare eventuali calcoli di comparazione, andamento e previsione, conto economico (ad esempio tramite l’implementazione della piattaforma “Trend“).
Ovviamente l’utente ha la libertà di scegliere di implementare uno o più “Utility Meter” configurati con cicli diversi. Tutti i parametri disponibili per la configurazione sono elencati e descritti sulla pagina dedicata al componente.
Configurazione
Ipotizziamo quindi. una configurazione base, senza fasce orarie:
utility_meter:
montly_energy:
source: sensor.assorbimento_oggi
cycle: monthly
Nel caso dell’esempio sopra, la configurazione definisce un sensore contabilizzatore su singola fascia di costo (in quanto non ne sono state precisate altre) chiamato sensor.montly_energy.
Questo sensore si resetterà una volta al mese (alla mezzanotte del primo giorno, a meno di usare il parametro offset per scegliere un altro giorno arbitrario) e andrà a contabilizzare i consumi provenienti dal sensore indicato (ovvero sensor.assorbimento_oggi).
Ipotizziamo invece la presenza di tre fasce, le classiche F1, F2 ed F3 presenti in bolletta:
utility_meter: montly_energy: source: sensor.assorbimento_oggi cycle: monthly tariffs: - F1 - F2 - F3
Questa configurazione genera quattro entità:
- utility_meter.montly_energy
- sensor.montly_energy_F1
- sensor.montly_energy_F2
- sensor.montly_energy_F3
La prima entità riporterà nel proprio stato la fascia oraria in corso (come fa a saperlo? Lo scopriremo a breve), mentre i tre sensori i consumi suddivisi per fascia. Anche questi tre sensori si resetteranno una volta al mese (alla mezzanotte del primo giorno, a meno di usare il parametro offset per scegliere un altro giorno arbitrario) e andrà a contabilizzare i consumi provenienti dal sensore indicato (ovvero sensor.assorbimento_oggi).
Quando lo stato di utility_meter.montly_energy è valorizzato a “F1“, a fronte di consumi rilevati da sensor.assorbimento_oggi a incrementarsi è il sensore sensor.montly_energy_F1; quando è “F2, il sensore sensor.montly_energy_F2, infine quando è “F3“, sensor.montly_energy_F3.
Gestione delle fasce
In caso si sian configurate delle fasce orarie è necessario attuare anche un’altra configurazione di gestione automatica.
L’entità utility_meter.montly_energy, infatti, non “sa” quando una fascia oraria sia in corso. Ecco perché per far sì che questa si sposti nel tempo è necessaria un’automazione specifica. Ipotizziamo che le fasce contrattualizzate col nostro fornitore di servizio siano le seguenti:
- Fascia 1: lun-ven h8-19
- Fascia 2: lun-ven h7-8, h19-23. sab h8-23
- Fascia 3: lun-sab h00-07, h23-24. dom h00-24
Assumiamo che la F1 sia la più cara e la F3 la più economica.
IMPORTANTE: l’automazione che segue utilizza anche un’entità genericamente chiamata input_boolean.holiday la quale, se “ON“, indica un giorno festivo per il quale la fascia debba necessariamente essere forzata a F3. Per gestire tale entità è possibile utilizzare, per esempio, un calendario che contenga gli all-day da considerarsi festività (Natale, Pasqua eccetera), il quale è possibile realizzare applicando quest’altra guida, nella quale abbiamo anche spiegato come gestire questa entità di servizio (in fondo, paragrafo “Uso”). |
L’automazione che fa sì che la fascia corretta venga attribuita allo stato di utility_meter.montly_energy è:
automation: - alias: "Tariffe energetiche" id: "tariffe_energetiche" initial_state: true trigger: - platform: state entity_id: input_boolean.holiday id: "holiday" to: "on" variables: tariff: "F3" - platform: time id: "7" at: "07:00:00" variables: tariff: "F2" - platform: time id: "8" at: "08:00:00" variables: tariff: "F1" - platform: time id: "19" at: "19:00:00" variables: tariff: "F2" - platform: time id: "23" at: "23:00:00" variables: tariff: "F3" condition: [] action: - choose: - conditions: - condition: trigger id: "holiday" sequence: - service: select.select_option target: entity_id: select.home_monthly_consumption_tariff data: option: "{{ tariff }}" - conditions: - condition: trigger id: "7" sequence: - condition: and conditions: - condition: state entity_id: input_boolean.holiday state: "off" - condition: time weekday: - mon - tue - wed - thu - fri - sat - service: select.select_option target: entity_id: select.home_monthly_consumption_tariff data: option: "{{ tariff }}" - conditions: - condition: trigger id: "8" sequence: - condition: and conditions: - condition: state entity_id: input_boolean.holiday state: "off" - condition: time weekday: - mon - tue - wed - thu - fri - service: select.select_option target: entity_id: select.home_monthly_consumption_tariff data: option: "{{ tariff }}" - conditions: - condition: trigger id: "19" sequence: - condition: and conditions: - condition: state entity_id: input_boolean.holiday state: "off" - condition: time weekday: - mon - tue - wed - thu - fri - service: select.select_option target: entity_id: select.home_monthly_consumption_tariff data: option: "{{ tariff }}" - conditions: - condition: trigger id: "23" sequence: - condition: state entity_id: input_boolean.holiday state: "off" - service: select.select_option target: entity_id: select.home_monthly_consumption_tariff data: option: "{{ tariff }}"
L’automazione fa sì che la tariffa corretta (e quindi la contabilizzazione sui sensori) venga attuata automaticamente man mano col trascorrere del tempo.
Sensori di contabilizzazione
I tre sensori (o quanti siano in base alle fasce configurate) possono essere utilizzati come comuni sensori per i propri scopi.
Interessante è la visualizzazione utilizzando una card dell’interfaccia di Home Assistant che visualizzi l’andamento storico:
Trend
Il trend delle letture relative al consumo di un dato periodo di monitoraggio possono essere valutate tramite la piattaforma “Trend“, la quale appunto permette di creare ulteriori sensori virtuali (binari) capaci di indicare l’andamento in crescita o in diminuzione di una misura, in questo caso la contabilizzazione sul periodo.
Altri articoli sul tema consumi:
- Integrare Shelly Pro 4PM a Home Assistant via MQTT
- Stimare assorbimenti e consumi elettrici sulla domotica Home Assistant, con PowerCalc
- PUN: integrare il prezzo unico nazionale dell’energia sulla domotica Home Assistant
- Integrare e contabilizzare un pannello solare fotovoltaico “plug & play” su Home Assistant
- Contabilizzare i consumi d’acqua e rilevare perdite con la domotica Home Assistant (via flussostato ed ESPHome)
- Rendere no-frost un frigorifero tradizionale con Home Assistant
- Calcolare il consumo di energia (in kWh) a partire dalla potenza istantanea (in Watt) con Home Assistant
- Configurare dei contabilizzatori di consumo energetico su Home Assistant e relative fasce orarie (v2)
- Realizzare una sonda di assorbimento elettrico domotica tramite PZEM, ESP8266 ed ESPHome
- Sonoff POW: calibrare la rilevazione d’assorbimento con Tasmota
- Integrare Shelly Dimmer 2 a Home Assistant via MQTT
- Integrare Shelly Plug S a Home Assistant via MQTT
- Integrare Shelly EM a Home Assistant via MQTT
- Integrare potenza ed energia da PZEM su Home Assistant via MQTT
- Realizzare una sonda di assorbimento elettrico domotica tramite PZEM, ESP8266 e Tasmota
- Integrare Shelly Dimmer / Dimmer SL a Home Assistant via MQTT
- Integrare Shelly 1PM a Home Assistant via MQTT
- Integrare Shelly 2.5 a Home Assistant via MQTT
- Contabilizzare i consumi gas sulla domotica Home Assistant (via contatore predisposto e lanciaimpulsi)
- Assorbimenti elettrici sotto controllo tramite la domotica Home Assistant
- Integrare FIBARO Wall Plug (in versione Apple HomeKit) a Home Assistant
- Configurare dei contabilizzatori di consumo energetico su Home Assistant
- Dedurre lo stato di un elettrodomestico non-domotico con Home Assistant (tramite assorbimento elettrico)
- Integrare potenza ed energia da Sonoff POW su Home Assistant via MQTT
- Uso della modalità “DYNAMIC SLEEP” di Tasmota per ridurre l’assorbimento di un Sonoff
- Riprogrammare un ITEAD Sonoff POW usando firmware Tasmota
- Rendere domotico uno scaldabagno elettrico tramite Sonoff Basic (o altri)
- Uso del comando “SLEEP” di Tasmota per ridurre l’assorbimento di un Sonoff
⚠️ Se di Home Assistant ne sai poco ma sei interessato a capirne di più, ti suggeriamo di partire da qui. |
Questa pagina è redatta, manutenuta e aggiornata dallo staff di inDomus, un gruppo di persone molto diverse tra loro che trovi, per domande e supporto, sul forum e sulla chat del sito. Alcuni link sono taggati in qualità di affiliati Amazon e riceviamo un compenso dagli acquisti idonei, utile al sostenimento del sito, ma le nostre recensioni sono tutte indipendenti e non sponsorizzate. Se ti sei perso, a tua disposizione c'è la mappa. |