Arlec/Deta EV200D-HA EV charger (22kW/32A) - currently matches tera_w01_evcharger but is missing several DPs and has a wrong current range

[kbinish-ship-it]

Log message

This device already matches tera_w01_evcharger.yaml well enough that it was usable, so the config flow never showed the "no match" warning with the DPS dump. Instead here are two real local DPS captures from custom_components.tuya_local debug logging (not the config-flow warning, but the same underlying data):

Idle, plugged in, current limit set to 6A (charger_end):
{"1": 238433, "3": "charger_end", "4": 6, "5": 0, "9": 0, "10": 0, "13": "controlpi_9v", "14": "charge_now", "16": false, "18": false, "22": "3091002509060039", "23": "H0_ARLEC-V1.0.6", "24": 35, "25": 1830, "101": false, "102": 10, "103": "Disable", "104": 6, "105": 60}

Actively charging single-phase at 6A:
{"1": 238435, "3": "charger_charging", "4": 6, "5": 1397, "9": 1397, "10": 0, "13": "controlpi_6v_pwm", "14": "charge_now", "16": false, "18": true, "22": "3091002509060039", "23": "H0_ARLEC-V1.0.6", "24": 36, "25": 1, "101": false, "102": 10, "103": "Disable", "104": 6, "105": 60}

DPs 6/7/8 (the phase_a/b/c raw voltage+current+power blobs) are pushed on a slower, separate cadence than the rest and were captured separately, e.g. phase_a = "CT4AFwwAAdE=" (decodes cleanly as voltage/current/power using the exact same mask layout as tera_w01_evcharger's L1/L2/L3 entries).

Product ID

svufayckw5hozqbz

Product Name

Deta EV200D-HA (7/22kW wall-mount Grid Connect smart EV charger, 5m cable). Firmware self-identifies as "H0_ARLEC-V1.0.6" - looks to be the same hardware rebadged as Arlec in the Australian Grid Connect range.

DPS information

Not the dedicated Query Things Data Model function (no iot.tuya.com account), but the device owner pulled the cloud "thing" info and current properties directly:

GET https://openapi.tuyaeu.com/v2.0/cloud/thing/bfd5b45e6c1199b68dmnok
{
  "result": {
    "category": "qccdz",
    "custom_name": "EV Charger",
    "model": "EV200DHA",
    "name": "EV200D-HA",
    "product_id": "svufayckw5hozqbz",
    "product_name": "EV200D-HA"
  }
}

Properties (current values, from the cloud "properties" endpoint - so types are Tuya's own but ranges below are inferred, not authoritative):
| dp_id | code | type | value (sample) |
|---|---|---|---|
| 1 | forward_energy_total | value | 77428 |
| 3 | work_state | enum | charger_charging |
| 4 | charge_cur_set | value | 32 (device also accepts and echoes back 6 locally - see below) |
| 5 | sigle_phase_power [sic, Tuya's own typo] | value | 6782 |
| 6 | phase_a | raw | CK0Ad0wACNQ= |
| 7 | phase_b | raw | CSUAAAAACPM= |
| 8 | phase_c | raw | CUYAAAAACPM= |
| 9 | power_total | value | 6873 |
| 10 | fault | bitmap | 0 |
| 11 | alarm_set_1 | raw | AQIAIAMCCeIEAggWBQL//wcC//8= |
| 12 | alarm_set_2 | raw | AQIACQIC//8DAv//CAL//w== |
| 13 | connection_state | enum | controlpi_6v_pwm |
| 14 | work_mode | enum | charge_now |
| 15 | balance_energy | value | 200 |
| 16 | clear_energy | bool | true |
| 17 | energy_charge | value | 200 |
| 18 | switch | bool | true |
| 19 | local_timer | raw | AQA= |
| 22 | meter_id | string | 3091002509060039 |
| 23 | system_version | string | H0_ARLEC-V1.0.6 |
| 24 | temp_current | value | 54 |
| 25 | charge_energy_once | value | 780 |
| 27 | online_state | enum | online |
| 33 | mode_set | raw | AQABAQAAAAA= |
| 101 | dlm_switch | bool | false |
| 102 | home_max_current | value | 10 |
| 103 | solar_mode | enum | Disable |
| 104 | solar_current_from_grid | value | 6 |
| 105 | solar_stable_time | value | 60 |

Notes on what's confirmed locally vs still guesswork:
- DPs 1,3,4,6,7,8,9,10,13,14,18,23,24 are already covered by tera_w01_evcharger.yaml and confirmed working locally (identical dp ids/format to Tera's own device).
- DP 4's range in tera_w01_evcharger.yaml is min 8, max 32. This hardware accepts and echoes back 6A locally (confirmed by setting it and reading it back), and 6A is the IEC 61851/J1772 minimum, so 8A looks like it may be Tera-specific rather than universal to this dp.
- DPs 5, 22, 25, 101, 102, 104, 105 were confirmed present and sane locally (see the two captures above). 103 (solar_mode) was seen locally too but only ever as "Disable" - full enum set unconfirmed.
- DPs 11, 12, 15, 16, 17, 19, 27, 33 come only from the cloud properties dump above; not yet confirmed to be readable over the local protocol (tera_w01_evcharger.yaml doesn't declare them, so they've never been requested locally).
- DP 28 (timer_on / "Delay charge" in tera_w01_evcharger.yaml) does NOT appear in this product's DP list at all - it looks like a Tera-only feature.

Would be happy to run a local capture with 11/12/15/17/19/27/33 explicitly requested if that's useful for confirming which are actually exposed locally, and/or to get proper QueryThingsDataModel ranges if someone can point me to a way to do that without iot.tuya.com access (Tuya's trial access to that function is apparently now capped at one month, refreshable every 6 months).

Information about how the device functions

Australian market, IEC 61851/J1772 Type 2, 22kW 3-phase (32A per phase), sold both as "Arlec" (Bunnings' house brand) and "Deta" (also an AU electrical brand) - the firmware itself self-identifies as ARLEC regardless of which retail name it's sold under, so these are very likely identical hardware.

I've built and tested a full local device config against the real hardware (all 19 dps tera_w01_evcharger.yaml already handles, plus the additional ones listed above, decoded and sane, current min lowered to 6A and confirmed). I know from the note above that PRs are currently paused, so I'm not opening one - happy to share the yaml here or via a gist if it's useful reference material once someone has bandwidth, otherwise I'm also happy to just leave this as a device report for whenever it's picked up.

Product page: https://www.arlec.com.au/collections/ev-charging (no exact model number listed publicly that I could find matching EV200D-HA - it may be discontinued/OEM-only under that code).