Add EV charger sensor support

[Copilot]

The SEMS power station API already returns isEvCharge + evCharge fields but the integration ignores them. This adds sensor entities for GoodWe EV chargers (wallboxes) using that existing data — no extra API calls required.

Data flow

_async_update_data() now reads evCharge from the power station response (handles both list and dict) and populates a new SemsData.ev_chargers: dict[str, dict] keyed by charger SN, mirroring the existing inverters pattern.

New sensors (per charger SN)

Unique ID	Value	Unit
{sn}-ev-status	Charging / Standby / Offline / Unknown	—
{sn}-ev-power	power field	kW
{sn}-ev-current	current field	A
{sn}-ev-charge-energy	chargeEnergy field	kWh
{sn}-ev-soc	soc field	%

Key design notes

• SemsEVChargerSensor overrides native_value to skip the base-class string-cleaning regex (which strips non-numeric strings), needed because the status field is a raw API string like "EVDetail_Status_Title_Charging". convert_ev_charger_status() maps these to human-readable labels.
• GOODWE_SPELLING.firmware = "fireware" added to const.py to document the API's misspelling in EV charger responses, consistent with the existing convention.
• device_info_for_ev_charger() added to device.py following the same pattern as device_info_for_inverter().

# Example coordinator data shape with an EV charger present
SemsData(
    inverters={"GW1234...": {...}},
    ev_chargers={"GW5678...": {"status": "EVDetail_Status_Title_Charging", "power": 7.5, ...}},
)

When isEvCharge=False or evCharge is null, ev_chargers is None and no EV charger entities are created.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull request overview

This PR adds EV charger (wallbox) entity support to the SEMS Home Assistant integration by extracting evCharge data from the existing power station getData() response and exposing it via new per-charger sensor entities (no additional API calls).

Changes:

• Extend the coordinator data model to include SemsData.ev_chargers populated from isEvCharge/evCharge.
• Add EV charger device info + sensor definitions (status, power, current, charge energy, SOC) driven by the coordinator data.
• Add fixtures and integration-style tests to validate EV charger entity creation and absence when EV data is not present.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
custom_components/sems/__init__.py	Extracts evCharge from the station payload and stores it in SemsData.ev_chargers.
custom_components/sems/sensor.py	Adds EV charger sensor types/entities and status mapping.
custom_components/sems/device.py	Adds device_info_for_ev_charger() to group EV charger entities under a device.
custom_components/sems/const.py	Documents the EV charger API misspelling for firmware (fireware).
tests/fixtures.py	Adds EV charger fixture payload + anonymized charger SN.
tests/test_sensor_entities.py	Adds tests asserting EV charger sensors are created (and not created when absent).

[Copilot]

SemsEVChargerSensor.native_value bypasses the base class string cleaning for all EV charger sensors. If the SEMS API returns numeric fields like power/current/soc as strings with units (similar to powerflow values like "2337(W)"), those values will no longer be parsed into numbers and may end up as raw strings in sensor state. Consider limiting the bypass to the status sensor only (e.g., a dedicated SemsEVChargerStatusSensor / flag on SemsSensorType), or reusing the base string-cleaning behavior for non-status EV sensors while still preserving non-numeric status strings.

[Copilot]

device_info_for_ev_charger() uses identifiers={(DOMAIN, serial_number)}, which is the same identifier scheme used for inverters. If an EV charger SN ever overlaps with an inverter SN, Home Assistant will merge them into a single device in the device registry. Consider namespacing the identifier (e.g., prefixing with ev- or using a distinct identifier tuple) to guarantee uniqueness across device types.