`_switch_usage` raises AssertionError on `181: Operation without permission` when Smart Circuit / V2L not installed

[bharat]

Thanks for maintaining this library. Sharing a failure pattern in case it's useful.

Setup

• HA 2026.5.1 in Docker, latest franklinwh via homeassistant-franklinwh
• aGate + aPower, no Smart Circuit module, no V2L

Symptom

Roughly twice in 24 hours, get_stats() throws and every FranklinWH sensor flips to unavailable for about a minute before the next poll recovers. Traceback is consistent:

File ".../franklinwh/client.py", line 667, in _switch_usage
    data = (await self._mqtt_send(payload))["result"]["dataArea"]
File ".../franklinwh/client.py", line 776, in _mqtt_send
    assert res["code"] == 200, f"{res['code']}: {res['message']}"
AssertionError: 181: Operation without permission

What looks different from prior reports

• #43 was the same exception, resolved by fixing a device ID. Here, credentials are good: switch_1 lifetime usage keeps incrementing between failures, and battery/grid/solar data flows continuously.
• separate out switch stats #19 (closed) raised a related concern about _switch_usage polling unconditionally. The reason I'm filing separately is that the user-visible impact for me isn't extra API load, it's that one transient 181 on the Smart Circuit query tanks the entire get_stats coordinator including the calls that did succeed.

What I think is happening

switch_2_lifetime_use and v2l_export sit at sentinel 65534 continuously on my hardware. Most polls the API returns the sentinel and the parser accepts it. Occasionally the same call comes back as code: 181 / Operation without permission, and the assert res["code"] == 200 in _mqtt_send raises, killing the gather.

Possible fix shapes (offering, not prescribing)

• Treat 181 inside _switch_usage as soft, return None, and let the integration emit unknown for those entities instead of failing the whole gather
• Or convert the bare assert in _mqtt_send to a typed exception so callers can decide which codes are recoverable

Happy to test a patch or capture more API traces if useful. Thanks again.

[richo]

Hey thanks for the report. In fairness I am definitely not fully crushing it on the maintenance front, but I am trying.

This is a great report. Thankyou for sharing it. I agree with your ideas for fixing it. Do you know offhand how long this condition lasts for? At face value this doesn't really make any sense (why would your permissions change at the same time every day). My guess is that they have some cronjob that runs then.

to that end, yeah I think it's worth catching this condition, throwing an exception which can be caught here and then tolerate_stale_data will get you through it.