Migrate fully to pydantic 2

[steinmn]

Fixes #267

There were a couple of attributes that were commented out for some reason. Have set these as optional (type | None = None) for the time being, though I'm not sure why these were commented out in the first place.

Should we make these attributes (and/or others) required in addition to the ones we already require, or should we leave it as-is?

[sveinse]

I don't remember clearly, but I wonder if that was because v1 had some limitations. I'm not sure, thou. But please do the modifications which you think makes sense.

BTW! There is a feature we don't support at all, and that's pagination

[steinmn]

I've added some more values, though I think maybe we should branch out a separate issue on what to do with validation going forward. Key questions (off the top of my head):

• Do we want the models to be complete enough that we can turn off extra="allow"?
• The docs appear to set most values as optional, do we want to do the same on our side, or will certain values missing make the system unusable anyway?
• Should we support pagination? (not sure what this entails, so a what/how/why explanation would be nice)

[sveinse]

The purpose of protocol validation is only to check the data so that api.py doesn't crash if given incorrect data. Obviously we don't control the protocol and exclusively in Zaptec hands, so it might change without our notice. If we make the net too tight, it'll end up unexpected on our table as a non-working integration if and when that happens.

With regards to pagination its mentioned https://docs.zaptec.com/docs/api-usage-guidelines#5-real-time-updates-and-efficiency and https://docs.zaptec.com/page/api-changes-what-you-need-to-know#2-updated-pagination-limits-for-better-performance. I know of no HA user with more than 50 chargers, but it only takes a decision by Zaptec to lower this to levels where its important to consider....but we can chose to be reactive to a change like that. I think I'm happy with how it is for now, but we shouldn't forget.

[sveinse]

A general comment: How much should be included into the validation? Should we validate the fields that are being used in the code, or should we list everything that's returned from Zaptec?

For the current implementation, the goal has been the former: Only validate the fields which are necessary for using the api, and ignore the rest.

If the latter is chosen, do we have a reliable source for the schema we can use? I think it would be a pity if Zaptec updates their schema and we did not, and the integration fails for users on a field that we're not even using. But I'm kind of opinionated here, so I'd like to hear your opinion.

[steinmn]

Should we validate the fields that are being used in the code, or should we list everything that's returned from Zaptec?

I agree that we should stick to validating the fields that are necessary for the integration to work properly. As long as Zaptec doesn't change something we rely on, the integration shouldn't fail.

Sidenote: I think #283 is severe enough that we should move this PR and several other topics that are still open from the v0.8.2-milestone to the next, and get 0.8.2(beta?) out asap.

[sveinse]

Should we bump hacs.json here so it matches the HA version? And update the README telling that the minimum HA version is now 2025.* ?

[steinmn]

Sure, thoughts on how restrictive we want to be?

[sveinse]

I think your proposal of pydantic>=2.11.7,<2.12 and HA>=2025.7.0 is good as proposed in #293. We would be deviating from what seems to be the practice in the community. It seems the common policy seems to be pinned and strict dependencies, but we are free to make our choices.

[sveinse]

LGTM.

We need to remember to include a comment in the next release notes that the minimum HA version has been increased.