Fix daily battery energy counters corrupting long-term statistics

[FrancescoFdd5]

Closes #59.

Summary

Two independent bugs, each in its own commit, both affecting the energy data
this integration feeds into Home Assistant's long-term statistics.

1. tot_pBatteria and tot_pBatteriaB are declared state_class: TOTAL but
   never publish a last_reset attribute, so their daily midnight reset is
   never recognised and their long-term statistics are corrupted every day.
2. The get_energy.php request builds its date from the operating system's
   timezone rather than the one configured in Home Assistant.

---

1. Battery energy counters corrupt long-term statistics

tot_pBatteria ("Battery charged energy") and tot_pBatteriaB ("Battery
discharged energy") are daily counters: the endpoint is queried with
intervallo=d, and the plant resets them to 0 at midnight.

They are declared state_class=SensorStateClass.TOTAL and never set
last_reset. That combination is the problem. In
homeassistant/components/sensor/recorder.py, the reset branch for TOTAL
requires a last_reset that is both present and changed:

if (
    state_class != SensorStateClass.TOTAL_INCREASING
    and (last_reset := _last_reset_as_utc_isoformat(...)) != old_last_reset
    and last_reset is not None      # never true for these sensors
):

last_reset is always None, so None != None is false and the branch is never
taken. The TOTAL_INCREASING branch below it is not taken either. The reset is
therefore never detected, and the midnight drop back to 0 falls through to the
ordinary accumulation at the end of the loop:

_sum += new_state - old_state

So a full day's worth of energy is subtracted from the cumulative sum in one
step at midnight, and each day is booked as today's total minus yesterday's
total instead of today's total.

Example from my own plant, running 1.0.9. The first column is what the plant
reports, the second is what the above arithmetic books into statistics:

Day	Daily total reported by the plant	Booked into statistics
20 Aug	10.2 kWh	—
21 Aug	5.8 kWh	5.8 - 10.2 = -4.4 kWh
22 Aug	12.7 kWh (reading at 18:00)	12.7 - 5.8 = +6.9 kWh

The same spurious midnight step is what produces the anomalous first hourly
bucket of each day reported in #59.

One clarification on that issue, now that the cause is understood: I originally
attributed it to the sensor resetting a couple of seconds after midnight rather
than exactly at midnight. That offset turns out to be irrelevant.
reset_detected() does not look at timing at all, so the reset would have gone
undetected regardless of when it happened.

Fix

Switch both sensors to TOTAL_INCREASING. reset_detected() then recognises
the drop on its own — any value below 90% of the previous reading — and opens a
new cycle at zero, with no last_reset required.

This also makes the two sensors consistent with every other daily counter in the
integration, all of which already use TOTAL_INCREASING: tot_pReteIn,
tot_pReteOut, ePannelli, eBatteria and eConsumed.

Both sensors have behaved this way since they were introduced in e45cf80 (#55).

---

2. Energy endpoint queried with the OS timezone

The get_energy.php URL was built from three separate datetime.now() calls:

year=datetime.now().year,
month=datetime.now().month,
day=datetime.now().day,

Two problems. datetime.now() returns the operating system's local time, not
the timezone configured in Home Assistant, so on a host whose clock is set to a
different zone the integration asks for the wrong day around midnight. And
because the three calls are independent, they can straddle midnight and build a
date whose year, month and day come from different days — on 31 December that
yields a date a full year off.

Fix

Read the clock once, through homeassistant.util.dt.now(), which returns the
current time in Home Assistant's configured timezone.

---

Note for users upgrading

The fix only corrects statistics going forward. Statistics already recorded
under TOTAL stay wrong and have to be corrected by hand in
Developer Tools -> Statistics, oldest day first, since adjustments propagate
forward through the cumulative sum. The affected days are easy to spot: they are
negative or implausibly low.

Testing

Running on my production Home Assistant instance since 22 Aug 2026. The daily
counters now reset cleanly at midnight, the anomalous first-hour bucket from #59
is gone, and the recorded statistics match the figures reported by the plant.

Note on the version bump

The third commit bumps manifest.json to 1.0.10 for easy test with HA. Happy to drop it if you would
rather handle versioning and releases yourself.