Auth problem

.gitignore

@@ -40,4 +40,17 @@ credentials.*
 *.key
 *.cert
 *.p12
-*.pfx
+*.pfx
+# Probe and diagnostic output (may contain device identifiers)
+/log
+*.out
+probe-*.txt
+
+# Subagent-driven development scratch
+/.superpowers/
+
+# Working rules, kept local by operator decision 2026-09-29
+/rules.md
+# Stray copies of another project's runbook have landed here at least once.
+# Ignore the dotted form too rather than relying on nobody running `git add -A`.
+/.rules.md

LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2025 andrea
+Copyright (c) 2025 Andrea Restello
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

NOTICE

@@ -0,0 +1,33 @@
+Daze Wallbox Integration for Home Assistant
+===========================================
+
+Original author
+---------------
+
+Created by Andrea Restello (@arest).
+Upstream project: https://github.com/arest/daze-addon
+
+The integration architecture, config flow, entity model, sensor catalog
+and API client are his work, including the reverse engineering of the
+Daze web API, which the vendor does not publish.
+
+This repository
+---------------
+
+A fork maintained by Pedro Tarrinho (@tarrinho) at
+https://github.com/tarrinho/daze-addon
+
+The changes in this fork are the work of Pedro Tarrinho. They are bug
+fixes found by running the integration against a DT01 charger and
+measuring the API's actual responses: authentication, payload parsing,
+charge command shape and retry behaviour, state reporting, and
+diagnostics.
+
+It is not a redesign, and it carries no claim over the original work.
+See the "Changes in this fork" section of README.md for the detail.
+
+Licence
+-------
+
+MIT, Copyright (c) 2025 Andrea Restello. See LICENSE, which is carried
+over from the upstream project unchanged.

README.md

@@ -1,21 +1,24 @@
 # Daze Wallbox
 
+[![Version](https://img.shields.io/github/v/tag/tarrinho/daze-addon?label=version&sort=semver&color=blue)](https://github.com/tarrinho/daze-addon/releases)
 [![HA Community](https://img.shields.io/badge/Home%20Assistant-2025.x-41BDF5?logo=homeassistant)](https://www.home-assistant.io/)
-[![HACS Validation](https://github.com/arest/daze-addon/actions/workflows/validate.yaml/badge.svg)](https://github.com/arest/daze-addon/actions/workflows/validate.yaml)
-[![GitHub](https://img.shields.io/github/license/arest/daze-addon)](LICENSE)
+[![HACS Validation](https://github.com/tarrinho/daze-addon/actions/workflows/validate.yaml/badge.svg)](https://github.com/tarrinho/daze-addon/actions/workflows/validate.yaml)
+[![GitHub](https://img.shields.io/github/license/tarrinho/daze-addon)](LICENSE)
 
 Home Assistant integration for **Daze WallBox EV chargers**. Monitor charging metrics in real time and control your wallbox directly from your HA dashboard — no separate app required.
 
 Daze wallboxes are managed through the [Daze web portal](https://webportal.dazeservice.com). This integration bridges the gap, bringing your wallbox into Home Assistant alongside all your other smart home devices.
 
+> **This is a fork.** The original integration was created by **Andrea Restello** ([@arest](https://github.com/arest)) at [arest/daze-addon](https://github.com/arest/daze-addon), and all of the original design and implementation is his work. This fork, maintained by **Pedro Tarrinho** ([@tarrinho](https://github.com/tarrinho)), adds fixes found while running it against a DT01 charger — see [Changes in this fork](#changes-in-this-fork).
+
 ---
 
 ## Features
 
 - **Real-time monitoring** — Power (W), delivered energy (Wh), charging current per phase (mA), AC voltage per phase (V), board and case temperatures (°C)
 - **EVSE status** — See whether the wallbox is charging, idle, paused, or in error
 - **Charge control** — Start and stop charging from HA switches, automations, or dashboards
-- **Current limit** — Set the maximum charging current as a number entity (6–32 A, 0.1 A steps)
+- **Charging limit** — Set it in amps or in watts. Both bounds come from the charger: its power floor at the measured voltage, and the installation rating
 - **Operation mode** — Switch between eco, fast, scheduled, and other modes
 - **Session history** — Track energy, duration, and cost per recharge session
 - **Lifetime totals** — Total energy delivered and session count
@@ -33,7 +36,7 @@ Daze wallboxes are managed through the [Daze web portal](https://webportal.dazes
 3. Click the three dots in the top-right corner and select **Custom repositories**
 4. Add this repository URL:
    ```
-   https://github.com/arest/daze-addon
+   https://github.com/tarrinho/daze-addon
    ```
 5. Select **Integration** as the category and click **Add**
 6. Close the dialog — the Daze Wallbox integration should now appear in HACS
@@ -84,14 +87,15 @@ If your tokens expire, the integration will automatically prompt you to re-enter
 | `sensor.daze_ac_voltage_l3` | AC Voltage L3 | `voltage` | `measurement` | V |
 | `sensor.daze_board_temperature` | Board Temperature | `temperature` | `measurement` | °C |
 | `sensor.daze_case_temperature` | Case Temperature | `temperature` | `measurement` | °C |
-| `sensor.daze_evse_status` | EVSE Status | `enum` | — | idle / charging / paused / error |
+| `sensor.daze_evse_status` | EVSE Status | `enum` | — | idle / waiting_for_ev / charging / paused / error / offline |
 | `sensor.daze_last_session_energy` | Last Session Energy | `energy` | `total_increasing` | Wh |
 | `sensor.daze_last_session_duration` | Last Session Duration | — | — | min |
 | `sensor.daze_last_session_cost` | Last Session Cost | `monetary` | — | EUR |
 | `sensor.daze_last_session_start` | Last Session Start | `timestamp` | — | |
 | `sensor.daze_last_session_end` | Last Session End | `timestamp` | — | |
 | `sensor.daze_lifetime_energy` | Lifetime Energy | `energy` | `total_increasing` | Wh |
 | `sensor.daze_total_sessions` | Total Sessions | — | `total_increasing` | sessions |
+| `sensor.daze_solar_surplus` | Solar surplus | `power` | `measurement` | W |
 
 #### Diagnostic sensors
 
@@ -107,8 +111,17 @@ If your tokens expire, the integration will automatically prompt you to re-enter
 | Platform | Entity ID | Name | Purpose |
 |----------|-----------|------|---------|
 | Switch | `switch.daze_charge_control` | Charge Control | Start / stop charging |
-| Number | `number.daze_max_charging_current` | Max Charging Current | Set charging current limit (6–32 A) |
+| Number | `number.daze_max_charging_current` | Current | Charging current limit, bounded by the charger's own floor and the installation rating |
+| Number | `number.daze_max_charging_power` | Power | The same limit in watts, bounded by the charger's 1.5 kW floor |
 | Select | `select.daze_operation_mode` | Operation Mode | Switch between eco, fast, scheduled |
+| Select | `select.daze_solar_control` | Solar control | `off` / `simulate` / `active` |
+| Number | `number.daze_solar_reserve` | Solar reserve | Watts to leave for the house before the car gets any |
+
+No entity in this integration sets an explicit name or translation
+key, so none of the IDs above are guaranteed — they follow the device
+name, and a renamed device changes the prefix. Confirm the real object
+IDs for your own install under **Settings → Devices & services →
+[your device] → entities** before using them in an automation.
 
 ---
 
@@ -148,8 +161,92 @@ data:
 
 ---
 
+## Solar control
+
+Charges the car from what the house would otherwise export, adjusting
+the limit as production and load change, and stopping when there is not
+enough surplus to charge at all.
+
+The controller itself defaults to **off**, so nothing runs before the
+entities exist. But the **Solar control** select lands on `simulate`
+the first time it is added — a fresh install never actually shows
+`off`. In `simulate` it decides and logs but sends nothing to the
+charger; nothing reaches hardware until you pick `active` yourself.
+
+1. In the integration's options, pick your **grid import** and **grid
+   export** power sensors, and answer **grid supply**: single-phase or
+   three-phase. This is a declaration, not something the integration
+   can detect — the Daze API does not report how many phases feed the
+   house — and solar control refuses to arm until it is answered. If
+   you are upgrading from an earlier version, this is the field that
+   will make solar control refuse to arm until you go and set it.
+2. Leave **Solar control** on `simulate`. The select's attributes show
+   the surplus it sees and what it would have done.
+3. Leave it for a day, then work through the validation checklist
+   below before switching to `active`.
+4. If the decisions look right, set it to `active`.
+
+It never imports to charge: the charger cannot run below 1500 W, so
+when surplus falls below that it stops rather than topping up from the
+grid.
+
+Changing the charging limit yourself — from the dashboard, or from your
+own automation — turns solar control off. Starting or stopping the
+charge by hand does the same. It does not fight you.
+
+### When the control is unavailable
+
+Solar control refuses to arm rather than guess, and says why in the
+log (`Solar control cannot run: …`). It is unavailable when:
+
+- **Both grid sensors are not set.** It has nothing to measure.
+- **The grid supply has not been declared.** The charger cannot tell
+  the integration how many phases feed the house, so you have to say
+  so yourself, and there is no default. A three-phase meter reports
+  surplus added up across all three phases; a single-phase charger can
+  only use one of them, so following that figure would load one phase
+  with all three phases' surplus. For the same reason, a **three-phase
+  supply with a single-phase charger is refused outright** — see the
+  YAML guide below if that is your setup.
+- **The charger's own eco mode is on, or it has a schedule set.**
+  Something else is already deciding when the car charges, and two
+  controllers fighting over one charger is worse than either alone.
+
+### The reserve
+
+**Solar reserve** is watts to leave for the house before the car gets
+any: set it to 500 and the car is only offered surplus above 500 W. It
+is saved with the integration's settings and survives a restart.
+
+### Before you trust it
+
+A day in `simulate` is only useful if you actually check it against
+what happened. Before switching to `active`:
+
+- **Does the surplus figure go to zero at night?** If it does not, a
+  sensor's sign convention is inverted.
+- **Does it rise when the car stops charging?** It should not — that
+  means the car's own draw is being double-counted.
+- **Set a schedule on the charger and confirm solar control refuses to
+  arm, then clear it and confirm it arms again.** This is the one guard
+  whose positive direction has never been confirmed on real hardware:
+  it reads the charger's `nextScheduleInfo` field, and all that has
+  actually been observed is that the field is null when no schedule is
+  set.
+- **Confirm a smart-tariff pause does not populate `nextScheduleInfo`**
+  and so does not falsely refuse to arm.
+- **Check the logged decisions against what actually happened** before
+  switching to `active`.
+
+For a version you build and tune yourself, see
+[docs/solar-surplus-charging.md](docs/solar-surplus-charging.md).
+
+---
+
 ## Automation Examples
 
+For charging from solar surplus, see [docs/solar-surplus-charging.md](docs/solar-surplus-charging.md) — a worked setup that follows your export, respects the charger's 1.5 kW floor, and reads its bounds from the entity rather than hardcoding them.
+
 ### Stop charging when energy price is high
 
 ```yaml
@@ -231,6 +328,76 @@ The integration is validated with:
 - `hassfest` for Home Assistant integration validation
 - HACS validation
 
+---
+
+## Credits
+
+This integration was created by **Andrea Restello** ([@arest](https://github.com/arest)).
+The upstream project is [arest/daze-addon](https://github.com/arest/daze-addon).
+
+Everything this fork does rests on his work: the integration architecture, the
+config flow, the entity model, the sensor catalog and the API client were all
+written upstream. He also reverse-engineered the Daze web API, which is not
+publicly documented — that is the hard part, and none of what follows would
+exist without it.
+
+### Changes in this fork
+
+Maintained by **Pedro Tarrinho** ([@tarrinho](https://github.com/tarrinho)).
+
+Every change below was found by running the integration against a real DT01
+wallbox and measuring the API's actual responses, rather than by reading the
+code alone.
+
+**Setup**
+
+- Authenticate through the Cognito `GetUser` operation instead of
+  `/oauth2/userInfo`. The Daze portal issues access tokens scoped
+  `aws.cognito.signin.user.admin` without `openid`, which `userInfo` rejects,
+  so setup previously failed for every user with `invalid_token`.
+
+**Reading data**
+
+- Read the live metrics from where the API actually returns them. Power,
+  energy, currents and voltages arrive nested under `chargeSession`, not at the
+  top level, so every sensor read `Unknown` with no error logged.
+- Fetch the EVSE record as well as the socket state. Temperatures, the grid
+  limit, eco mode and the configured current appear only there.
+- Derive the charger status from the integer `evseState` plus the pause and
+  error flags. The API never returns the status string the code expected.
+- Report `waiting_for_ev`, the state the charger passes through after a start
+  before the car begins drawing, and hold the charge switch on through it so it
+  does not appear to snap back.
+
+**Charge control**
+
+- Send the serial number and the session ID with `playcharge` and `stopcharge`.
+  An empty body is rejected with `ErrorWrongSessionID`, and the session ID alone
+  is accepted but does nothing.
+- Read the session ID from the charger at command time. It changes whenever a
+  session ends, so a cached copy can name one that has already closed.
+- Retry commands through the Daze RPC link, which fails intermittently with
+  HTTP 500 code 101. Delays grow from 1.5s to 6s across eight attempts, roughly
+  33 seconds in total, because a tight burst of retries does not outlast the
+  outage.
+- Re-read the charger at 3, 8, 15 and 30 seconds after a command, so a start or
+  pause shows up promptly instead of waiting for the next poll.
+
+**Robustness and diagnostics**
+
+- Treat HTTP 404 from the recharge-session endpoint as a durable condition.
+  It was retried every 30 seconds and logged a warning each time.
+- Throttle the session history fetch to once every five minutes instead of
+  requesting up to 1000 records twice a minute.
+- Log retried failures at debug and report a single warning only when a command
+  genuinely gives up, instead of one warning per attempt.
+- Add diagnostic tools under `tools/` for reproducing each API call outside
+  Home Assistant, and tests that use captured API responses as fixtures.
+
+These are bug fixes to someone else's design, not a redesign. If the upstream
+project adopts them, this fork becomes unnecessary.
+
 ### License
 
-This project is licensed under the [MIT License](LICENSE).
+This project is licensed under the [MIT License](LICENSE), Copyright (c) 2025
+Andrea Restello, carried over unchanged from the upstream project.