EX6000 support

[filmackay]

I just replaced an EX6000 with what I think was the same model as I had previously. Before I had Model being reported (via sensor) as EX 6000 iQ but now it comes through as unknown.

Is this expected? I don't see a mapping table anywhere.

[galletn]

Hi @filmackay sorry for the late reply, I'm afraid that the newer robot might not run the legacy webeservice anymore ... there is no mapping table for model number its 1 separate call to a webservice that returned the model.

could you maybe reset your pw and send you credentials over to me nicolas.gallet@skynet.be? With some luck they use a new field on the newer models.

thanks!

[galletn]

@filmackay did you resolve the issue? Again I think here its because the model api is not working for your model. Can you test with postman if I give you the details on how to do that?

Thanks!

[craigcurtin-dev]

i have the 6500 series and it is working and identified with the integration

[galletn]

@filmackay any update otherwise I close this one as @craigcurtin-dev says its working ?

[filmackay]

Still showing as unknown - if you could give me postman details I can revert.

[galletn]

Hi @filmackay — here's a 3-step Postman walkthrough that mirrors exactly what the integration does. After step 3 the response body has a model field. If it comes back missing, empty, or with modelSupported: false, that's the cloud confirming the EX6000's /features endpoint doesn't carry a model string for your device. If it comes back with "model": "..." then there's an integration-side parsing bug worth chasing.

---

Request 1 — Login (POST)

URL:    https://prod.zodiac-io.com/users/v1/login
Method: POST

Headers:

Content-Type: application/json; charset=utf-8
Accept:       */*

Body (Postman: select Body → raw → JSON):

{
  "apiKey":   "EOOEMOW4YR6QNB07",
  "email":    "your-iaqualink-email@example.com",
  "password": "your-iaqualink-password"
}

Save these three values from the response for the next steps:

• authentication_token → used as a query param in step 2
• id → used as a query param in step 2
• userPoolOAuth.IdToken → used as the Authorization header in step 3

---

Request 2 — List devices (GET)

URL:    https://r-api.iaqualink.net/devices.json?authentication_token={{authentication_token}}&user_id={{id}}&api_key=EOOEMOW4YR6QNB07
Method: GET

Headers:

Content-Type: application/json; charset=utf-8
Accept:       */*

You'll get an array of devices. Find the one whose device_type is one of i2d_robot / cyclonext / cyclobat / vr / vortrax and copy its serial_number.

---

Request 3 — Features / Model (GET) ← the one we care about

URL:    https://prod.zodiac-io.com/devices/v2/{{serial_number}}/features
Method: GET

Headers:

Authorization: {{IdToken}}
Accept:        */*

⚠️ Authorization is the raw IdToken value — no Bearer prefix (this is what the integration sends).

Three possible response shapes:

1. {"model": "EX 6000 iQ", ...} → good, model is there — means an integration-side parsing bug
2. {"model": null, "modelSupported": false, ...} → cloud knows about your device but doesn't expose a model string
3. {} or 404 → endpoint not implemented for the EX6000 path

Could you paste the raw response from step 3 (with the serial redacted)? That'll tell us whether the gap is on the cloud side or in how the integration is reading the response. Thanks!

[galletn]

Hi @filmackay — sorry for the long silence, and I have an answer for you now.

I captured payloads from several robots and found what's happening. The cloud derives the model field from a cleaner part number it stores against your device (eboxData.completeCleanerPn). On one of the robots I tested, that part number is an empty string — and for that device the cloud omits model entirely, exactly as yours does. So it isn't the endpoint being dead or a parsing bug on my side: the cloud itself has no model recorded for the device. That fits your "I just replaced an EX6000" — the new registration looks incompletely provisioned.

I checked whether it could be recovered another way, and it can't: the part number is the only key that maps to a model, and there's nothing to look up when it's blank.

What has improved in 3.0.0-rc.3: models now resolve from that part number offline (the old lookup scraped a vendor website that had silently stopped working, so it was returning "Unknown" for every robot), and an unrecognised part number now shows as Unknown (WR0xxxxx) instead of a bare Unknown — so it can simply be added to the mapping.

Could you install rc.3 (HACS → ⋮ → Redownload → enable "Show beta versions") and attach Download diagnostics from the device page? It now includes the part number, so no more Postman steps. If it comes back blank, that confirms the above and I'll document it as a cloud-side limitation. If it has a value, I can map it and your model will appear.