#Indevolt second opinion
1 messages ยท Page 1 of 1 (latest)
The discussion you're referring is not auto-linked. Do you want a general second opinion or is it related to a comment/discussion? ๐
its related to a comment. its on the link, but github is dumb and does not jump to it apparently because its resolved. I've unresolved it for now so the link works
Xirt owns the library, so this is an opportunity to extend pyindevolt with API business logic that rightfully belongs there rather than in the integration layer. I'm also a bit worried about the slippery slope: if we accept this now, it sets a precedent. On later iterations we'll inevitably hear "well, we already have quite some indevolt logic in the integration, so why are you holding back *this *change?"; and each of those is harder to push back on than the first one.
Not the most popular take to give back, I understand, but on separation of concerns I think you're right here, @opal thicket. The power/SOC rules are device properties, not HA properties; if you'd ask me. ๐
My two cents... for what's it worth ๐
yeah, I agree @lone mulch . I was wondering if I was being too strict tbh eheh
I think it's ok to do validation of user input in Home Assistant but the knowledge about what are allowed limits should come from the library API somehow. If it's a value that is documented as max, that could eg be a constant or part of an enum, in a 3rd party library.