Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (d3c2861) 82.24% compared to head (d0e4cc5) 82.27%.

@@            Coverage Diff             @@
##           master     #551      +/-   ##
==========================================
+ Coverage   82.24%   82.27%   +0.03%     
==========================================
  Files          30       30              
  Lines        2461     2466       +5     
  Branches      692      694       +2     
==========================================
+ Hits         2024     2029       +5     
  Misses        379      379              
  Partials       58       58              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Hi, could you merge this please @rytilahti? Are you going to publish a release soon?

Ok fair enough. I was thinking about how this would be stored in and re-used in HA. As it seems to be the discovery info that determines the protocol, one approach could be to create a protocol factory (either in it's own module or as part of the discovery module). This could take a parameter of the pydantic DiscoveryResult we created which can then be serialized and stored in HA. Similar to the storing of the DeviceType this could then be used to pass the protocol class to connect()

What do you think? ping @bdraco, for context here it seems that some kasa EP25 devices are starting to use the TAPO protocol

Ok fair enough. I was thinking about how this would be stored in and re-used in HA. As it seems to be the discovery info that determines the protocol, one approach could be to create a protocol factory (either in it's own module or as part of the discovery module). This could take a parameter of the pydantic DiscoveryResult we created which can then be serialized and stored in HA. Similar to the storing of the DeviceType this could then be used to pass the protocol class to connect()

What do you think? ping @bdraco, for context here it seems that some kasa EP25 devices are starting to use the TAPO protocol

I think its a good idea to store the discovery results in some way in HA so we can reconnect easily, but I would be very nervous about relying on pydantic to do the serialization / deserialization as I've had so many problems with pydantic changes and breakage that I no longer use it in new code.

A simple data structure that is JSON serializable would probably be the best as it would make it easy to work for most systems and HA

Hi @rytilahti, any further thoughts on whether we can merge this yet? I think we’re going to need it for the Klap HA PR to work after @bdraco moves the integration to use connect().

This looks good to me and worth merging.

My only worry is that adding such "low-level" things (like importing custom protocols / initializing them) may not be acceptable for homeassistant..

So I was thinking, maybe we could create a very simple container for all necessary connection parameters (ConnectionParameters or something like that?), and make it possible to pass only that for constructing instances. W/o pydantic if that's a deal breaker, although I doubt it should be a problem in a non-nested model).

As long as we keep this backwards compatible, we can easily extend it without needing to touch homeassistant code. Basically, SmartDevice should be able to output this json serializable object, like @bdraco mentioned, as well as accept it to re-create the instance.

What we basically need is the following information to construct a device from zero, right?

• Host
• Port
• Device type
• Protocol (legacy, klap, aes)?
• Username (if applicable)
• Password (if applicable)
• Timeout

What do you think?