Aggiornamento documentazione

Author: virtualdj

DEVELOPMENT.md

@@ -24,4 +24,5 @@ Ovviamente non ho alcuna certezza che tutto questo sia la maniera giusta di proc
 - [Questa parte](https://github.com/bdraco/home-assistant/blob/4224234b7abfd1b31f75637b910f4fb89d5b4a0d/homeassistant/components/workday/__init__.py#L27-L31) di codice per effettuare il precaricamento corretto del modulo _holidays_ con `async_add_import_executor_job` senza che desse errori nel lint (si vede bene in [questa commit](https://github.com/virtualdj/pun_sensor/commit/17141bd3dd2914e6dab27c4fbe6a07c2274c29e4))... Ma come si poteva capire?
 - La [documentazione](https://developers.home-assistant.io/docs/config_entries_config_flow_handler#config-entry-migration) e [questo esempio](https://github.com/home-assistant/core/blob/2cc54867944d804f7033f0ff3f5e458ec579aabe/homeassistant/components/tuya/__init__.py#L193-L211) per capire come salvare un dato interno (il minuto di esecuzione, nello specifico) nella configurazione di Home Assistant, non mutabile, che richiede l'esecuzione di `async_update_entry` su una copia della stessa
 - Ho tentato di modificare i sensori per fare in modo che derivassero da `RestoreSensor` anziché da `RestoreEntity`, come [suggerito dalla documentazione](https://developers.home-assistant.io/docs/core/entity/sensor/?_highlight=monetary#restoring-sensor-states) ufficiale di Home Assistant, tuttavia ho dovuto desistere perché la funzione `self.async_get_last_sensor_data()` può salvare solo 2 dati, cioè `native_value` e `native_unit_of_measurement` (un esempio [qui](https://github.com/jonathan-ek/solis_modbus/blob/b768066e07d92041f8cc57e4dc6d4a67c18334ca/custom_components/solis_modbus/number.py#L251-L253) oppure [qui](https://github.com/ckarrie/ha-netgear-plus/blob/8f0aa265319cc7c4cc7100a060ab16f0858426cd/custom_components/netgear_plus/netgear_entities.py#L110-L112)). Questi però non sono sufficienti per il nostro scopo, perché serve anche sapere se il sensore è disponibile (`self._available`, che al limite si potrebbe rendere implicito con `native_value = None`) ma soprattutto il nome della fascia corrente (`self._friendly_name`) per `PrezzoFasciaPUNSensorEntity`. Quindi, in definitiva, ho lasciato tutto com'era, sfruttando `self.async_get_last_extra_data()` e il dizionario personalizzato fornito da `def extra_restore_state_data(self)` che comunque ripristina `native_value` e non lo `state` come scrive la documentazione.
-- Grazie ChatGPT ho scoperto che l'aggiunta di un `timedelta` a un `datetime` (pure _timezone-aware_) comunque "salta" le occorrenze della stessa ora locale (tipicamente le 2 di mattina) nella giornata di cambio ora. I calcoli vanno fatti sempre passando da UTC!
+- Grazie a ChatGPT ho scoperto che l'aggiunta di un `timedelta` a un `datetime` (pure _timezone-aware_) comunque "salta" le occorrenze della stessa ora locale (tipicamente le 2 di mattina) nella giornata di cambio ora. I calcoli vanno fatti sempre passando da UTC!
+- [bramstroker/homeassistant-powercalc](https://github.com/bramstroker/homeassistant-powercalc/blob/4d45885a44e05b89c51ba11c3497a41582e611fa/custom_components/powercalc/sensors/power.py#L340) per capire come applicare la procedura descritta nella [documentazione](https://developers.home-assistant.io/docs/core/entity/#excluding-state-attributes-from-recorder-history) e fare in modo di non memorizzare gli attributi nel recorder che, nel caso di questa integrazione, sarebbero la lista dei prezzi zonali e del PUN orario.