This is really awesome @steinmn . Thank you.

I'm all in on improving the code quality and the dev experience (including the devcontainer). However, I would prefer that we keep the PRs clean and to the point. Otherwise important logical changes can get lost in the formatting diffs. I see that some of the changes are purely formatting changes (black?). Would it be possible that we split this up into two PRs? Since we aren't exactly overflowing with contributions, I won't turn this PRs away, but I hope to sway you in the right direction.

As for the devcontainer: I've not been using the dev-container as-is for a while. I had some problems with it due to HA versioning issues. The setup I'm running is that I have a HA devcontainer, and then I've injected zaptec sources into custom_components/zaptec.

Moved library and container updates to #184

Regarding the formatting changes: I'm 99% sure these are from the formatOnSave-setting in https://github.com/custom-components/zaptec/blob/master/.devcontainer.json#L44, which I'm not particularly a fan of. Could you maybe consider changing this to false instead? I've removed the formatting-only stuff from this PR with some GitKraken-shenanigans, but this could be one of those little frustrating things that increases the threshold to contribute just enough that newer devs don't bother to try.

As far as I can tell, the dev-container is fully functional with the additions now in the other PR. If you have a different setup, maybe you could describe this in a for-devs-readme and/or include a script for it? Anything that shortens the doorstop-mile for new devs improves the chances of more contributions, right? (no idea if doorstop-mile translates to english, but I assume you get it in the original language ;) )

I think "threshold for new devs" is how its said in English. I think. Not all Norwegian expressions are translatable and the other way round.

Anyhow, I agree, the format on save should be disabled. Do you mind updating #184 while at it? In my mind it falls to somewhat the same category. Also agree about doing a writeup of the developer experience. Let's open an issue about that and continue that conversation in that, please.

I'll take a look at the PR.

At an initial read-through this looks good. I'd like to test this for a few days on my test setup. Unfortunately my car is just recently topped up, so I can't test a charge cycle just now. But I'll keep it running for the days to come and run the next charge cycle with it.

The fix seems to be working fine. Great work.

I have a UX issue that's due to how this integration is polling its data. If I set the "Charger max current" from 32A to 12A, it will jump back to 32A after a few seconds. After a minute it will jump to the final value of 12A. I did some debugging and found it to be cause by the following sequence. Logs below.

1. Value of maxChargeCurrent is set from 32A to 12A
2. Service bus immediately responds and updates the entity to 12A
3. HA polls Zaptec cloud and gets the old value of 32A
4. On next poll interval when HA polls Zaptec, it gets update back to 12A

Here we are touching a fundamental problem: Whenever a entity is updated by HA, it polls the Zaptec cloud for updates. This is necessary if changing a value or pressing a button changes other values than the button or number. However, it turns out that the Zaptec cloud is slow at updating its value, which leads to this ping-pong of value.

If one disables await self.coordinator.async_request_refresh() in number.py#L95 this issue will be reduced, as it does not initiate a cloud pull immediately after changing the value. However, if the integration is scheduled to update its value very soon after the number update, the user will see a value change back to the original value which will last the length of the poll interval.

# Setting to 12A
26:20.450 [zaptec.number] Setting ZaptecSettingNumber.charger_max_current to <float> 12.0   (in ...f40861)
26:20.451 [zaptec.api] Settings {'maxChargeCurrent': 12.0}

# Service bus immediately responds with the new value
26:21.562 [zaptec.api] ---   Subscription: {'DeviceId': 'xxx', 'DeviceType': 4, 'ChargerId': '...f40861', 'StateId': '510 (ChargerMaxCurrent)', 'Timestamp': '2025-07-06T09:26:21.065669Z', 'ValueAsString': '12.000'}
26:21.562 [zaptec.api] >>>   Updating Charger[f40861].charger_max_current (ChargerMaxCurrent)  =  <float> 12.0  (was 32.0)
26:21.563 [zaptec]     number.sol_charger_max_current  =  <float> 12.0   from Charger[f40861]
26:21.597 [zaptec.api] ---   Subscription: {'DeviceId': 'xxx', 'DeviceType': 4, 'ChargerId': '...f40861', 'StateId': '522 (ChargerOfflinePhase)', 'Timestamp': '2023-07-12T14:10:37.23', 'ValueAsString': '4'}
26:21.621 [zaptec.api] ---   Subscription: {'DeviceId': 'xxx', 'DeviceType': 4, 'ChargerId': '...f40861', 'StateId': '712 (IsStandAlone)', 'Timestamp': '2023-07-12T13:31:40.253', 'ValueAsString': '0'}

# HA polls for new updated values as a response to the setting
# -- but cloud is not updated yet so the value jumps back to 32A
26:21.664 [zaptec.api] Polling state for Installation[8a106b] (Sol Installation)
26:21.768 [zaptec.api] Polling state for Circuit[84a4e5] (Sol Circuit)
26:21.822 [zaptec.api] Polling state for Charger[f40861] (Sol)
26:21.924 [zaptec.api] >>>   Updating Charger[f40861].charger_max_current (ChargerMaxCurrent)  =  <float> 32.0  (was 12.0)
26:21.987 [zaptec] Finished fetching xxx data in 0.322 seconds (success: True)
26:21.988 [zaptec]     number.sol_charger_max_current  =  <float> 32.0   from Charger[f40861]

# In the next scheduled the poll, the value is updated to 12A
27:21.458 [zaptec.api] Polling state for Installation[8a106b] (Sol Installation)
27:21.628 [zaptec.api] Polling state for Circuit[84a4e5] (Sol Circuit)
27:21.678 [zaptec.api] Polling state for Charger[f40861] (Sol)
27:21.769 [zaptec.api] >>>   Updating Charger[f40861].charger_max_current (ChargerMaxCurrent)  =  <float> 12.0  (was 32.0)
27:21.829 [zaptec] Finished fetching xxx data in 0.372 seconds (success: True)
27:21.831 [zaptec]     number.sol_charger_max_current  =  <float> 12.0   from Charger[f40861]

Yeah, now that you mention it, I've seen similar flipflopping with the Charging switch as well.

Considering this is a more fundamental issue, should we try to do anything about it in this PR, or should it be merged as-is and open a discussion on a separate "Polling outdated data"-issue?