Raggiunta la VERSIONE 6.5

NEW VIDEO: https://www.youtube.com/watch?v=KuQIP6OYA7g
- Aggiunto miglioramento per la visualizzazione su tablet. L'interfaccia utente per la visualizzazione su tablet è stata migliorata. I vari pulsanti attivano e disattivano la visualizzazione delle colonne per la programmazione.
- Aggiunta sull'evento corrente: sia il giorno corrente che il periodo di tempo sono ora evidenziati.
- Risolto un errore minore sul file python su LowSetpoint
Raggiunta la VERSIONE 6.0

video: https://youtu.be/yEF4qnM_ENA
Dopo aver creato le zone, perchè non considerare le temperature di riferimento per ogni zona?
Da qui si è partito per l'ennesimo aggiornamento del package.
Il funzionamento del termostato si basava su tre variabili:
- orario di accensione della caldaia
- orario di spegnimento
- zona di riferimento, così da poter scegliere il target della zona
A queste tre variabili è stata aggiunta una quarta: la temperatura di riferimento.
Si pensa così di poter gestire il termostato in ogni sua parte e per ogni necessità soggettiva.
Alcuni "orpelli" utilizzati fino alla versione 5.0, sono stati tolti, rendendo il codice più snello.
Il boost mode è stato eliminato. Adesso non serve più, basta impostare la temperatura nel periodo desiderato.
E' stato rivisto il codice della parte telegram, ripulito completamente di inutili riferimenti, richiami e parti ridondanti e aggiornato ai nuovi sensori.
Le temperature HIGH, una delle due termerature di riferimento insieme alla LOW, si è trasformata nella temperatura di setpoint che viene impostata ad ogni periodo.
la LOW è rimasta inalterata.
Risistemate le tre modalità AUTO, MANUAL e AWAY in moda da avere tutte lo stesso comportamento.
La modalità AWAY è una modalità MANUAL con zona e setpoint fissati.
Stravolgimento della GUI.
Il calendar mode è stato eliminato.
Sia la picture-entity che la multi-row card sono state sostituite da una griglia di button card, con tutta la gamma di impostazioni che tale card mette a disposizione.
Il numero dei periodi da poter utilizzare sono stati portati a 5, per aumentare il numero delle combinazioni durante la giornata.
Nulla vieta di aggiungere altri periodi a seconda delle necessità.
Ogni riga è riferita al giorno della settimana.
Nella colonna "dey week" i bottoni attivano e disattivano la programmazione per l'intera giornata, tenendo traccia del giorno attuale per una migliore visualizzazione.
Ogni variabile riferita al periodo (orario di accensione, orario di spegnimento, zona termica, temperatura di riferimento) si attiva quando viene valorizzata. Se lasciata senza valore si disabilita.
Se avete suggerimenti per l'interfaccia grafica, non esitate a contattarmi...sono sempre disponibile a trovare soluzioni migliori! 😉
Raggiunta la VERSIONE 5.0

Lo sviluppo del package è sempre stato legato alle necessità familiari che possono variare.
Nello specifico il cambiare casa comporta caratteristiche climatiche differenti rispetto la precedente.
Si è dovuto gestire il "target_sensor" dell'entità "climate" non più come prima, unico e fisso (la media tra due temperatura ben precise), bensì a zona (per esempio giorno e notte) proprio per la caratteristica del nuovo appartamento.
Non avendo a disposizione teste termostatiche ai termosifoni (vedi anche il costo per ogni valvola), si è pensato di utilizzare solo i sensori di temperatura per creare zone termiche.
Questo nuovo packege introduce la scelta della zona, tra le tante definite a priori.
Ad ogni zona è associata una media di temperautre (per esempio la zona BedRooms avrà come "target_sensor" la media delle temperature delle due camere da letto). Scegliendo quindi quella zona la caldaia lavorerà unicamente per quella zona, ovvero riscalderà finquando la temperatura corrente (il "target_sensor, ovvero la temperatura della zona scelta) non eguaglierà la temperatura di riferimento (per esempio impostata a 20°C).
Nell'utilizzare questo modo di operare, nelle altre zone, molto probabilmente, la temperatura media andrà al di sopra o al di sotto del "target_sensor" dell'entità "climate" (per esempio, essendo le camere più fredde della zona giorno, quest'ultima sarà riscaldata maggiormente, oltre la temperatura di riferimento impostata). Le differenza di temperatura tra le zone impostate, però, si aggirano sul singolo grado, quindi ben accetta questa approsimazione a zone.
Entrando nel dettaglio, si è voluto lasciare tutte le funzioni introdotte nelle versioni precedenti, tra cui AUTO e MANUAL mode.
Preferendo l'una o l'altra si ha l'opportunità di impostare la zona di riferimento.
Nel caso della modalità MANUAL, gli unici parametri sono la zona termica e la temperatura di riferimento.
Nel caso della modalità AUTO, la scelta della zona è legata alla fascia oraria di interesse. Il package è stato progettato per gestire fino a 4 intervalli orari, nei quali si imposta l'orario di accensione e quello di spegnimento della caldaia. A questi orari si è aggiunto anche l'impostazione della zona termica, così da concentrare il calore nella zona e nella fascia orari interessata.
Introducendo il concetto di zone, nella precedente interfaccia YAML si è aggiunto la scelta della zona termica, a seguire la fascia oraria.
Per una migliore visualizzazione si è introdotta una card "picture-elements" che rappresenta l'intera settimana con le varie fasce orarie e le relative zone termiche.
Con una input_boolean si può optare tra le due card lovelace.
Infine, per completezza, si è inserito nel package direttamente i sensori avgtemp (medie temperature delle zone) e l'indice termoigrometrico.
Raggiunta la VERSIONE 4.0
Data la permanenza forzata in casa, la UI è sempre più utilizzata rispetto i semplici messaggi/bottoni telegram.
Questo ha portato a curare ancor più l'aspetto del package del termostato.
Mancava infatti una programmazione "visuale", uno scheduler da poter modificare direttamente dalla UI, senza mettere mano al file .py.
Si è quindi pensato di mettere su uno scheduler per la programmazione settimanale della caldaia.

Requisito necessario:
La programmazione giornaliera è stata fissata in 4 stati (on e off per ogni stato), quindi in totale 8 stati, per ogni giorno della settimana.
Si è deciso di utilizzare input_text al posto di input_datetime per poter inserire una qualsiasi dicitura (un qualsiasi testo, per esempio "null") che "annulla" l'orario in quello stato.
Non solo vi è un pattern da seguire nella dichiarazione dell'input_text, ma nel file .py c'è un controllo sul testo proveniente dalla UI.
Inoltre è stato aggiunto per ogni giorno un input_boolean chiamato switch, che definisce l'attivazione o disattivazione nella programmazione del giorno.
La variabile input_boolean per confermare la presenza o meno durante il weekend in casa, è stata adesso "agganciata" agli switch descritti sopra del sabato e della domenica.
Una nota per il file .py.
Purtroppo la funzione "datetime.strptime()" presente e molto utile in python, nella istanza python lanciata in hassio non è presente, non è possibile neanhce importarla.
Quindi si è riscritto tale funzione per trafsormare gli input_text in variabili tempo vere e proprio.
La funzione schedule(), invece, crea il "current_schedule" in base alle informazioni che arrivano dalla UI.
Il resto dello script non varia nella sostanza rispetto alla precedente versione.
Quindi, lo scheduler definito prima nel file .py, adesso, invece, deriva direttamente dalla UI.
Ma perchè fermarsi alla programmaizone della caldaia?
Notando meglio lo script python, viene richiamato il servizio "climate.set_temperature". Infatti:
"hass.services.call( 'climate', 'set_temperature',..."
Quindi si potrebbe pensare di utilizzare un altro servizio, per esempio "remote.turn_on", così da utilizzare il Broadlink per programmare l'accensione di qualsiasi cosa (cliamtizzatore, robottino...).
Il limite come sempre dipende da tutti noi!
Risultato finale:

Raggiunta la VERSIONE 3.6
Aggiunte due automazioni quando Hassio restart utili per la memoria del sistema climate.
Nelle condizioni se la modalità AUTO è ON allora si attiva l'automazione AUTO.
In maniera duale, la condizione della seconda automazione riguarda la modalità MANUAL.
Corretto anche l'azione di impostazione dell'automazione MANUAL, utilizzando il template della variaible "input_number.setpoint"
Raggiunta la VERSIONE 3.5
Principalmente bug fixes!!
Ho voluto sistemare qualche difetto:
inizializzazione delle input_boolean (auto_mode e weekend_on).
Questo comportava ad ogni riavvio l'accensione automatica della caldaia, se hassio era in modalità MANUAL.
Riavviato in modalità AUTO non accadeva.
Nella definizione dell'entità climate ho eliminato target_temp.
Nel caso di sopra imponeva la sua temperatura di inizializzazione, "disturbando" la modalità MANUAL.
Nessun problema poichè nella scelta di una modalità la temperatura di riferimento verrà impostata direttamente dalla modalità stessa.
automation alias: Thermo Start
Ho eliminato la prima automazione, quella che imponeva all'avvio di Hassio input_boolean.auto_mode="ON".
Adesso il sistema riparte lasciando la modalità scelta precedentemente inalterata
automation alias: Thermo AUTO Mode
A differnza di prima adesso lo stato iniziale è OFF.
Nel trigger non c'è più l'opzione "homeassistant start"
automation Thermo MANUAL Mode
Rimane lo stato iniziale OFF
Nel trigger l'input_boolean.auto_mode OFF è stato eliminato
Non viene più lanciato il python_script.scheduler_manual, ma nell'azione si imposta direttamente la temperatura di riferimento, quindi uno script in meno!!!
Del resto era inutile poichè riassumendo lo script impostava solo la temperatura dell'entità climate, a differenza dello script AUTO che aveva giorni e orari impostati.
automation alias: Thermo AUTO Mode, alias: Thermo AWAY Mode, alias: Thermo MANUAL Mode
Nelle precedenti versioni ho privileggiato l'interfaccia dei bottoni di Telegram.
In questa verisone mi sono dedicato all'interfacci proprio di Lovelace.
Con queste 3 automazioni indico cosa attivare e cosa disattivare tra input_boolean e automazioni quando attivo o disattivo dalla UI gli switch delle modalità.
automation alias: BoostSetPoint
Mi sono accorto che le automazioni di BoostSetPoint avevano lo stesso alias.
Adesso si chiamano "BoostSetPointIncrement" e "BoostSetPointDecrement"
Raggiunta la VERSIONE 3.0.
Salve a tutti.
Date le domande e i suggerimenti nei commenti dell'articolo del termostato programmabile ( Articolo Termostato ), vorrei utilizzare il forum per gestire e tenere traccia di tutte le modifiche del package che spero avverranno attraverso suggerimenti di altri utenti.
Innanzi tutto una correzione del file scheduler_auto.py
Nel primo ciclo if (controllo di quale programma utilizzare), ho scoperto di aver copiato male il file python.
Nel controllo dello stato di "input_boolean.weekend_on" non avevo copiato ".state", non potendo mai utilizzare la programmazione del "weekend at home"!!!
Di seguito la correzione:
now = datetime.datetime.now().time()
if datetime.datetime.now().date().weekday() < 5:
current_schedule = WEEK_SCHEDULE
elif WEEKEND_ON.state == 'on':
current_schedule = WEEKEND_ON_SCHEDULE
else:
current_schedule = WEEKEND_OFF_SCHEDULE
Inoltre non lo avevo scritto nell'articolo, ma sicuramente sottinteso, potete modificare voi stessi gli orari dei giorni degli schedule.
Non solo, potete anche creare tanti schedule per ogni giorno della settimana.
Per esempio:
monday = [
[datetime.time( 0, 0), datetime.time( 7, 30)], # dalle 00:00 alle 07:30
]
tuesday = [
[datetime.time( 0, 0), datetime.time( 23, 59,59)]
]
wednesday = [
[datetime.time( 0, 0), datetime.time( 10, 30)]
]
thursday = [
[datetime.time( 0, 0), datetime.time( 10, 30)]
]
friday = [
[datetime.time( 0, 0), datetime.time( 10, 30)]
]
saturday = [
[datetime.time( 0, 0), datetime.time( 10, 30)]
]
sunday = [
[datetime.time( 0, 0), datetime.time( 10, 30)]
]
now = datetime.datetime.now().time()
if datetime.datetime.now().date().weekday() = 0: #l'array della settimana parte da 0
current_schedule = monday
elif datetime.datetime.now().date().weekday() = 1:
current_schedule = tuesday
elif datetime.datetime.now().date().weekday() = 2:
current_schedule = wednesday
elif datetime.datetime.now().date().weekday() = 3:
current_schedule = thursday
elif datetime.datetime.now().date().weekday() = 4:
current_schedule = friday
elif datetime.datetime.now().date().weekday() = 5:
current_schedule = saturday
else:
current_schedule = sunday
Rispondo, infine, ai suggerimenti dei commenti scritti nell'articolo.
Per il problema suggerito da Alberto sull'isteresi del sistema, può leggersi la risposta dell'articolo sul cronotermostato ( Articolo ) uscito in questi giorni.
Circa il suggerimento di Gabriele Giavatto su racchiudere le prime due automazioni in una sola, beh sinceramente non ho provato, ma se funziona ben venga!
Di seguito il suggerimento di Gabriele:
- alias: Thermo AUTO Mode
initial_state: True
trigger:
- platform: time_pattern
minutes: '/5' # ogni 5 minuti
- platform: homeassistant
event: start
action:
service_template: >-
{% if is_states ('input_boolean.auto_mode', 'on') %}
python_script.scheduler_auto
{% else %}
python_script.scheduler_manual
{% endif %}
Attendo le vostre correzioni e i vostri suggerimenti per migliorare il package. 🙂
Grazie del vostro aiuto e grazie ad HassioHelp che ci regala questo spazio per crescere insieme! 😉