#Thanks, I think I understand re: the

1 messages · Page 1 of 1 (latest)

strange raptor
#

So I don't know how the tapo cameras custom integration works, but the core tplink one uses only local communications. It supports several different communication protocols used by tplink devices, and it is pretty lax when it comes to models as long as a known protocol is used. Maybe that's the reason why you are seeing some sensors from it?

I don't know about the C100 either, but its failure to communicate could be a bug in our implementation. It would be great, if you could create fixture files for those devices (see https://python-kasa.readthedocs.io/en/stable/contribute.html#contributing-fixture-files) and either send them to me in private or create a PR to the python-kasa repository.

#

https://github.com/home-assistant/core/pull/129180/ is a WIP PR to for the initial tapocam support to the core integration, adding the video feed. But I'm wondering what sensors / how does the device look like in homeassistant at the moment, mind posting a screenshot of those 3 sensors or at least describing what they are?

pastel nymph
#

I don't know about the fixture files but Ill give it a go. The rest I'll happily provide, I've been following that PR and the motion ADC for switches PR for a short while now. It's late here now and I just got back from a show and I've had a few beer. I'll get you some feedback tomorrow and look into fixture files.

strange raptor
#

No worries! What we call fixture files are just JSON files that contain responses for a commands the device responded successfully. This will help us to know which devices are responding to which commands, and to avoid breaking functionality when we do changes in our code base. Oh, and we also use these files to maintain the list of supported devices to keep track on what are known to work with the library.

What the script basically does is sending known commands to the device and capturing the response, and finally saving the responses from successful calls into a JSON file. These commands are selected so that they won't change the device state or anything like that, but they simply collect data.

pastel nymph
#

Ok only took me 2 days to figure out how to get all the pieces in place to produce a fixture file 🙄 . To avoid the risk of getting my info to the wrong places, which I'm likely to, where would you like the info?

  1. Fixture file for the C520WS
  2. Error message when trying to generate a fixture file for the C100
  3. Sensors added and what they do when the C520WS is added to HAOS
  4. Error message when trying to add the C100 to HAOS
  5. Warning message from components/tplink/coordinator.py that's come up in my 2024.12 beta

I think that covers it.

strange raptor
#

Ohh, sorry about that! If you don't mind telling me, what were the issues with getting a fixture file generated? We should improve the instructions as the idea is to be as straightforward as possible.

To your specific questions:

  1. If you are familiar and comfortable with git, you could create a PR to the newly generated fixture file. If you don't want to do that yourself, you could also send the file to me and I can do that.
  2. If you get a file at the end of the run, all the errors (which probably should be marked as warnings) are irrelevant. The script tries to find out which commands the device supports, so many may fail and it's ok. We do this and collect these files to get an understanding of what devices are supported & what features could be exposed to homeassistant, all while making sure we don't break the library code and create bugs in future releases.
  3. No need for that, the library is designed in a way that it will expose all relevant sensors the library and the device supports.
  4. This is not relevant yet, as there's no support for any cameras at the moment. There is an open PR that aims to bring basic support for all cameras the backend library supports (https://github.com/home-assistant/core/pull/129180/), which we hope to finish for the 2025.1.
  5. This depends on the error messages, so if you copy&paste the error here, I can let you know if it makes sense to report it somewhere.

Thanks a bunch already!

pastel nymph
#
  1. Hope I did that right.
  2. It does not get to that point, with either the camera credentials or my TP-Link credentials I get this:
    (python-kasa) root@ubuntu:~/python-kasa# python -m devtools.dump_devinfo --username Redacted --password Redacted --host 192.168.0.225
    Host given, performing discovery on 192.168.0.225.
    Testing component_nego call ..Unable to query component_nego call at once: ("Device connection error: 192.168.0.225: Cannot connect to host 192.168.0.225:4433 ssl:False [Connect call failed ('192.168.0.225', 4433)]", ClientConnectorError(ConnectionKey(host='192.168.0.225', port=4433, is_ssl=True, ssl=False, proxy=None, proxy_auth=None, proxy_headers_hash=None), ConnectionRefusedError(111, "Connect call failed ('192.168.0.225', 4433)")))
  3. Gotcha.
  4. Nice!
  5. I brought this up in the Tapo Cameras Control and JurajNyiri's response was "Do not use both integrations at the same time, choose one.", this is what character limits allow me to.

2024-12-02 13:44:54.934 ERROR (MainThread) [kasa.smart.smartdevice] Error querying 192.168.0.107 individually for module query 'getLensMaskConfig' after first update: Invalid password hash in handshake2 for 192.168.0.107
2024-12-02 13:44:55.442 WARNING (MainThread) [kasa.smart.smartdevice] Error processing Camera for device 192.168.0.107, module will be unavailable: Error accessing module data in Camera (error_code=INTERNAL_QUERY_ERROR)
2024-12-02 13:44:55.443 WARNING (MainThread) [homeassistant.components.tplink.entity] Unable to read data for <DeviceType.Camera at 192.168.0.107 - TT-8L_Gatekeeper (C520WS)> switch.tt_8l_gatekeeper: Error accessing module data in Camera (error_code=INTERNAL_QUERY_ERROR)
2024-12-02 13:48:24.637 WARNING (MainThread) [kasa.transports.sslaestransport] Device 192.168.0.107 received unknown error code: -40214

pastel nymph
#

As to the documentation issue, not sure that you can do much about that other than to let potential testers know that they need to be running in an environment that has python, git, and uv installed (beyond the scope of your docs). I understood this, but didn't have that environment set up and it wasn't even on my todo list. But I'm glad I did so regardless.

#

Ok my PR failed because I must be a contributor(?), how do I send the file to you directly.

strange raptor
#
  1. I'm not seeing any PR, so maybe you tried to commit directly to the repository instead of your own forked copy? https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request describes the process of making PRs, but feel free to let me know if you need any help with it!
  2. Hmm, so basically this says that the device does not have that port open. The port 4433 feels odd, as that's the one used by kasa cameras that use another protocol. Support for those is WIP (https://github.com/python-kasa/python-kasa/pull/1270)
  3. 👍
  4. 👍
  5. Okay, yeah, it might be the having two separate "camera" integrations could interfere with each other, but But it's rather odd that these errors and warnings are coming from python-kasa (the one backing the core integration), but I thought we do not try to initialize cameras. @mossy siren any ideas here?
pastel nymph
#
  1. Ah ok, I'll work on that.
  2. I'll have a look at that.
  3. Both integrations are giving their own versions of the same error.
strange raptor
#

On 3. If you have the github cli installed on your desktop, you could try https://github.com/python-kasa/python-kasa/pull/1270 by checking out the branch of that pull request (gh pr checkout 1270) and run the dump devinfo again. Or alternatively, just kasa --host <ip> to see if it'll now show some information.

#

The tapo-controller support only tapo cameras, afaik, and the port 4433 uses a completely different communication protocol, which is not currently supported by any library I know about, probably as it is not so widely used 🙂

mossy siren
#
  1. We haven't currently implemented the transport for older firmware but we can do relatively easily if we have a device available to test against. Could you run uvx kasa --username <username> --password <password> and paste the "== Discovery Result ==" for the C100?
  2. I don't know for certain whether the integrations would interfere with each other. The custom component does not perform discovery afaik and that is where there usually could be interference. Regarding the error message I think the problem is that the camera might not support privacy mode and hence is getting this error. Once we have the fixture we can confirm.

As this channel will be closed once the beta is released should we start a group chat to continue the discussion?

pastel nymph
#

All that I got from running that from the C100 was:
Raised error: ("Device connection error: 192.168.0.225: Cannot connect to host 192.168.0.225:4433 ssl:False [Connect call
failed ('192.168.0.225', 4433)]", ClientConnectorError(ConnectionKey(host='192.168.0.225', port=4433, is_ssl=True, ssl=False,
proxy=None, proxy_auth=None, proxy_headers_hash=None), ConnectionRefusedError(111, "Connect call failed ('192.168.0.225',
4433)")))
Run with --debug enabled to see stacktrace

strange raptor
#

Do you see the discovery result in the console, @pastel nymph ?