Open chickenandpork opened 1 year ago
Researching this further, I find that my HomeAssistant now has typeguard-3.0.2
which is accepted by compatibility but unfortunately metadata includes this:
(https://github.com/agronholm/typeguard/blob/master/docs/versionhistory.rst)
3.0.0 (2023-03-15)
BACKWARD INCOMPATIBLE Dropped the argname, memo, globals and locals arguments from check_type()
Smells like a "smoking gun" there but I'm unsure which project ultimately uses typeguard
and causes it to be brought in.
I'm unsure which project ultimately uses
typeguard
and causes it to be brought in.
I think it's this: https://github.com/lovasoa/marshmallow_dataclass/blob/d6396c18470582a4fe5f0f2bd29ac012da4f0f1f/setup.py#L25
Upstream seems to be stuffing a human-readable comment where a date is expected (and, you know, that date has a format)
(confirmed: no pre-existing issue)
On configuration of a new install of 2023.1.7 HA with Integration 2023.1.0, victor-smart-kill==1.1.1
I've confirmed credentials, they do work.
Version of Home Assistant
2023.1.7
Version of the custom_component
2023.1.0 with "victor-smart-kill==1.1.1" in requirements
Describe the bug
On configuration, and the authentication is accepted, the configuration integration periodically shows "Retrying setup: None" and seems to keep reconnecting. The remote service is online, as a manual connection does connect, and the App connects.
It seems to be that the fetched data is doing that old "we'll just record a human-readable comment there, because schema doesn't matter?" Yeah, I hate sloppy schema, totally blame the upstream:
I mean, hey, "No maintenance records exist", you mean that's not ISO8601? :-/ grrr
I do see that your schema is a union, so this is probably beyond what I can figure out for why the validation is enforcing a data time schema -- it's like it's choosing the date time rather than string, then detecting that it's not a string.
Debug log