#Indevolt second opinion

1 messages ยท Page 1 of 1 (latest)

lone mulch
#

The discussion you're referring is not auto-linked. Do you want a general second opinion or is it related to a comment/discussion? ๐Ÿ™‚

opal thicket
#

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

lone mulch
#

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 ๐Ÿ˜„

opal thicket
#

yeah, I agree @lone mulch . I was wondering if I was being too strict tbh eheh

proud coyote
#

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.