1.4.1 Dyness API Fehler (Code 401): ACCESS_DENIED – deviceSn=None

[chepreronius]

after update to 1.4.1 .

Dyness API Fehler (Code 401): ACCESS_DENIED – deviceSn=None

I have 2 towers on cloud.

[shopf]

Hi, thanks for the report!

The error deviceSn=None means the automatic device discovery couldn't find your Tower on your API account. This likely happens because you have 2 towers and the API returns them in a format i haven't seen yet.

A few questions to help me fix this:

1. Did you use v1.3.0 or earlier before updating? If yes, did it work correctly with your Towers?
2. Do you still know the serial numbers (BMS SN) of your two Towers? They should be visible in the Dyness app under Device Management.
3. Could you run tools/dyness_test.py with your API credentials and share the output? I especially interested in the result of /v1/device/storage/list.

This will help me understand why the discovery fails for your setup and fix it properly.

Thanks for your patience!

[chepreronius]

Hi, thanks for the quick response!

To answer your questions:

Previous versions: I was using v1.3.0 (or older) before, and it was working, but only for one Tower. After the update, the discovery fails entirely with deviceSn=None.

Serial Numbers: Yes, I have both BMS SNs from the Dyness App.

Tower 1: R07E7C466819006D-BDU

Tower 2: R07E944668120020-BDU

I ran the tools/dyness_test.py as requested. Interestingly, the behavior differs between the two towers on the same account:

Tower 1 Result:
The API returns null for the storage list, even with the correct SN.

Output: {"code": 0, "msg": "success", "data": null}

Tower 2 Result:
This one returns a full history list (snapshots every 5 minutes). Here is a snippet of the /v1/device/storage/list output:

JSON
[
    {
      "realTimeCurrent": -9.3,
      "realTimePower": -5432.13,
      "realTimeCurrent2": null,
      "realTimePower2": null,
      "realTimeVoltage": null,
      "inverterTotalPower": null,
      "soc": "40",
      "createTime": "2026-03-23 18:05:00"
    },
    {
      "realTimeCurrent": -9.2,
      "realTimePower": -5370.04,
      "realTimeCurrent2": null,
      "soc": "38",
      "createTime": "2026-03-23 18:10:00"
    }
]

Observations:

The soc is returned as a string (e.g., "40").

The discovery likely fails because the data structure for multiple devices is nested or formatted differently than expected in the current logic.

Let me know if you need the full debug log from the test script!

[shopf]

Thanks for the detailed response — this is very helpful and reveals two bugs:

1) Serial number suffix -BDU
Your Towers use -BDU instead of -BMS. The auto-discovery currently prefers devices ending in -BMS — it will fall back to the first device in the list, but only if the list returns data at all.
2) API response format difference
Your Tower 1 returns {"code": 0, "msg": "success", "data": null} — note code is an integer 0, not the string "200" or "0" i expect. This causes the discovery to fail entirely and deviceSn stays None.

Both bugs will be fixed in the next patch. I'am also adding a fallback in the setup flow: if auto-discovery fails, you'll be able to enter your BMS SN manually.

As a temporary workaround until the fix is released: could you try downgrading to v1.3.0 via HACS? It required manual SN entry but worked for one Tower. I'll have the fix out shortly.

Please do share the full debug log when you have a chance — it will help me verify the fix works for both Towers!

[shopf]

Hi @chepreronius, i just released v1.5.0, which includes Manual Setup Fallback. If auto-discovery fails, a second setup step now allows entering the BMS serial number manually. Let me know if you continue to experience issues. Thanks.

[chepreronius]

Auto-discovery shows me one tower, same as beforu preupdate :-]
I now trying to understand how you mind about manual setup for 2 towers.
i find
STEP_MANUAL_DATA_SCHEMA = vol.Schema({ vol.Required("api_id"): str, vol.Required("api_secret"): str, vol.Required("device_sn"): str, vol.Optional("dongle_sn", default=""): str,

i must copy it 2 times to fill it for 2 tower, or only for second what i dont see it now?
here is config, but i think i dont uderstand what you mean. Here with idbdu,iddongle and api. you can try it :-]

"""Config Flow für Dyness Battery Integration."""
import uuid
import voluptuous as vol
from homeassistant import config_entries
from homeassistant.data_entry_flow import FlowResult

from . import DOMAIN

STEP_USER_DATA_SCHEMA = vol.Schema({
    vol.Required("api_id"): str,
    vol.Required("api_secret"): str,
})

STEP_MANUAL_DATA_SCHEMA = vol.Schema({
    vol.Required("133319685586663"): str,
    vol.Required("8c2...255"): str,
    vol.Required("R07E944668120020-BDU"): str,
    vol.Optional("R07E944668120020", default=""): str,
})


class DynessConfigFlow(config_entries.ConfigFlow, domain=DOMAIN):
    """Config Flow für Dyness Battery."""

    VERSION = 1

    def __init__(self):
        self._api_id = None
        self._api_secret = None

    async def async_step_user(self, user_input=None) -> FlowResult:
        """Schritt 1: Nur API-Zugangsdaten — Auto-Discovery."""
        if user_input is not None:
            self._api_id = user_input["api_id"]
            self._api_secret = user_input["api_secret"]
            data = {
                "api_id": self._api_id,
                "api_secret": self._api_secret,
                "api_base": "https://open-api.dyness.com",
            }
            await self.async_set_unique_id(str(uuid.uuid4()))
            return self.async_create_entry(title="Dyness Battery", data=data)

        return self.async_show_form(
            step_id="user",
            data_schema=STEP_USER_DATA_SCHEMA,
            description_placeholders={
                "manual_link": "manual"
            },
        )

    async def async_step_manual(self, user_input=None) -> FlowResult:
        """Schritt 2 (optional): Manuelle Eingabe der Seriennummern."""
        errors = {}

        if user_input is not None:
            data = {
                "api_id": user_input["api_id"],
                "api_secret": user_input["api_secret"],
                "api_base": "https://open-api.dyness.com",
                "device_sn": user_input["device_sn"],
                "dongle_sn": user_input.get("dongle_sn") or None,
            }
            await self.async_set_unique_id(str(uuid.uuid4()))
            return self.async_create_entry(title="Dyness Battery", data=data)

        # API ID vorausfüllen falls bereits eingegeben
        schema = vol.Schema({
            vol.Required("api_id", default=self._api_id or ""): str,
            vol.Required("api_secret", default=self._api_secret or ""): str,
            vol.Required("device_sn"): str,
            vol.Optional("dongle_sn", default=""): str,
        })

        return self.async_show_form(
            step_id="manual",
            data_schema=schema,
            errors=errors,
        )

[shopf]

Hi, thanks for sharing — I can see what happened!

In the manual setup form, the field labels are on the left and you enter your values on the right. It looks like the values ended up as field names. Here is how it should look:

Field	Your value
API ID	133319685586663
API Secret	8c2...255
Battery SN	R07E944668120020-BDU
Dongle SN	R07E944668120020

For 2 Towers: Yes, you need to add the integration twice — once for each Tower. Same API credentials both times, just a different Battery SN each time:

• First entry: R07E7C466819006D-BDU
• Second entry: R07E944668120020-BDU

Automatic discovery of all batteries on one account in a single setup step is planned for a future version.

Note: You posted your full API secret, which I edited. For security reasons, I recommend creating a new API secret in the portal and starting over with that.

[shopf]

Hi @chepreronius, could you please download v1.6.0 and check if everything is working properly and if your two towers are functioning?