Looking at HA documentation, I supposed Tapo Plug P110 should be supported by TP-Link integration using authentication.
Still then, no matter how much I tried, I always get error message 'Failed to connect' after entering user + password (which I already checked to be working properly while logging directly into Tapo Cloud website or Tapo app).
Activating the HA logger level DEBUG, I got the following message which seems related:
[kasa.smartprotocol] Unable to query the device: 172.16.23.73, not retrying: Error querying device: 172.16.23.73: UNKNOWN_METHOD_ERROR(-1002) for method: get_current_power
Running kasa directly in HA docker:
kasa --host 172.16.23.73 --device-family SMART.TAPOPLUG --encrypt-type AES --username my-email@email.com --password my password
I get the following output:
Got error: SmartDeviceException('Error querying device: 172.16.23.73: UNKNOWN_METHOD_ERROR(-1002) for method:
get_current_power')
ERROR Unclosed client session base_events.py:1805
client_session: <aiohttp.client.ClientSession object at 0x7faa3ac3b0>
ERROR Unclosed connector base_events.py:1805
connections: ['[(<aiohttp.client_proto.ResponseHandler object at 0x7faa3b42f0>,
1816182.71097043)]']
connector: <aiohttp.connector.TCPConnector object at 0x7faa3ac170>
It is worth mentioning that the plug is currently with firmware version 1.0.7 (update to 1.3.0 is currently proposed via Tapo app), it works properly via Tapo app and it also works in another HA instance using a custom component.
For all this, it seems to me that this may be an issue in the integration.
Can anyone help further? If you need any further logs or additional info, please let me know.
changed the title [-]Cannot add Tapo Plug P110 to Home Assistant 2024.2.4 - Error in debug mode[/-][+]Cannot add Tapo Plug P110 to Home Assistant 2024.2.3 - Error in debug mode[/+]on Feb 26, 2024
Your error messages are definitely related, the device is reporting that it doesn't support that command which is used to query the energy meter information. Would you mind trying if it works with the current git master branch? I also have a P110 that I have been using for development, and it is working just fine.
You could also try to run the dump_devinfo devtools script (python -m devtools.dump_devinfo --host 172.16.23.73 inside the checkout directory) to see how it differs from the output from mine which has this method supported - for the release that is used by homeassistant, we used the existence of energy_monitoring to decide if we perform that request.
Was yours marketed with energy monitoring, and is it also working? Do you have a different hw or sw version reported by the cli tool?
Would you mind trying if it works with the current git master branch? I also have a P110 that I have been using for development, and it is working just fine.
Running the same command under current git master branch (installed with poetry), I get no error anymore, but instead (redacted personal information):
== Mosquitos Diogo - P110 ==
Host: 172.16.23.73
Port: 80
Device state: False
== Generic information ==
Time: 2024-02-26 23:39:44+00:00 (tz: {'timezone': 'Europe/Lisbon'}
Hardware: 1.0
Software: 1.0.7 Build 210629 Rel.174901
MAC (rssi): AA:BB:CC:DD:EE:FF (-56)
Location: {'latitude': 0.0, 'longitude': 0.0}
== Device specific information ==
overheated: False
signal_level: 2
SSID: MY_SSID
== Features ==
Device ID (device_id): MY_DEVICE_ID
State (state): False
Signal Level (signal_level): 2
RSSI (rssi): -56
SSID (ssid): MY_SSID
Overheated (overheated): False
Overheated (overheated): False
On since (on_since): None
Cloud connection (cloud_connection): True
Current consumption (current_consumption): 0.0
Today's consumption (today's_consumption): 0
This month's consumption (this_month's_consumption): 0
Auto update enabled (auto_update_enabled): False
Update available (update_available): True
LED (led): False
Time (time): 2024-02-26 23:39:44+00:00
== Current State ==
<EmeterStatus power=0.0 voltage=None current=None total=0>
== Modules ==
+ <Module CloudModule (cloud_connect) for 172.16.23.73>
+ <Module DeviceModule (device) for 172.16.23.73>
+ <Module EnergyModule (energy_monitoring) for 172.16.23.73>
+ <Module Firmware (firmware) for 172.16.23.73>
+ <Module LedModule (led) for 172.16.23.73>
+ <Module TimeModule (time) for 172.16.23.73>
You could also try to run the dump_devinfo devtools script (python -m devtools.dump_devinfo --host 172.16.23.73 inside the checkout directory) to see how it differs from the output from mine which has this method supported - for the release that is used by homeassistant, we used the existence of energy_monitoring to decide if we perform that request.
There are definitely quite some differences, some eventually caused by the fw version in each? If needed, I have a spare (another) P110, which I can upgrade to latest fw version (1.3.0), to check if it works better.
Was yours marketed with energy monitoring, and is it also working? Do you have a different hw or sw version reported by the cli tool?
Yes, definitely supporting energy monitoring, and data is showing in Tapo app (even though 0).
Hardware and Software versions in Tapo app fit exactly what is reported (above) by cli
get_current_power is supported by the power_protection component rather than the energy_monitoring component so we shouldn't be calling it in the energy module.
The latest master version of the library is a bit more robust than 0.6.2.1 so it doesn't completely fail if one query fails. However the device stops responding to requests that come after errors, so I'm not sure how the cli output above was achieved at all. When I tested my P110 with an invalid method name the cli failed because the time component had not been initialised.
@pplucky are you querying the actual energy results in the cli vs the Tapo app? They look the same to me as I think the app just display zeros as <1 in the energy usage and current power columns.
Thanks for the fixture file, @pplucky, that's really helpful, and we should add it to our fixture collection! You could definitely try to perform a firmware update, that should fix it for you, but we should also fix this in the library.
get_current_power is supported by the power_protection component rather than the energy_monitoring component so we shouldn't be calling it in the energy module.
I think get_max_power and get_protection_power are likely for power_protection, no? Looking at the diff (diff P110.EU._1.0_1.0.7.json P110\(EU\)_1.0_1.2.3.json), the older firmware has energy_monitoring version 1 where-as the newer reports 2, so maybe we should just check for the version like we are doing for gradual on/off?
The latest master version of the library is a bit more robust than 0.6.2.1 so it doesn't completely fail if one query fails. However the device stops responding to requests that come after errors, so I'm not sure how the cli output above was achieved at all. When I tested my P110 with an invalid method name the cli failed because the time component had not been initialised.
Beats me, also. The fact is that when using kasa from the latest master (installed via poetry after git clone), I managed to get that output.
@pplucky are you querying the actual energy results in the cli vs the Tapo app? They look the same to me as I think the app just display zeros as <1 in the energy usage and current power columns.
I plugged something that would actually consume energy and here is output from Tapo app:
and the cli output:
Current consumption (current_consumption): 0.0
Today's consumption (today's_consumption): 0.387
This month's consumption (this_month's_consumption): 0.387
or when calling emeter command:
== Emeter ==
Current: None A
Voltage: None V
Power: 0.0 W
Total consumption: 0.387 kWh
Today: 0.387 kWh
This month: 0.387 kWh
Btw, is it normal that the Current and Voltage are both None?
This also seems to happen for the other P110 plug I have (which is in 1.1.5 and had no issues in being added to HA). In HA, no current and voltage sensors exist.
Now that I notice, I also didn't have these in the previous Tapo custom component, but just out of curiosity, I had 2 additional sensors:
These were probably obtained from device info properties overheated and rssi.
Please let me know if there's anything else you need/want me to check for this 1.0.7 plug before I upgrade its firmware ;-).
Btw, is it normal that the Current and Voltage are both None?
Yes, the device doesn't report this information. We are moving to a more dynamic approach for presenting the available information (see below) so this can be ignored for now.
These were probably obtained from device info properties overheated and rssi.
Activity
rytilahti commented on Feb 26, 2024
Hi,
Your error messages are definitely related, the device is reporting that it doesn't support that command which is used to query the energy meter information. Would you mind trying if it works with the current git master branch? I also have a P110 that I have been using for development, and it is working just fine.
You could also try to run the dump_devinfo devtools script (python -m devtools.dump_devinfo --host 172.16.23.73 inside the checkout directory) to see how it differs from the output from mine which has this method supported - for the release that is used by homeassistant, we used the existence of energy_monitoring to decide if we perform that request.
Was yours marketed with energy monitoring, and is it also working? Do you have a different hw or sw version reported by the cli tool?
pplucky commented on Feb 27, 2024
Hi there.
Running the same command under current git master branch (installed with poetry), I get no error anymore, but instead (redacted personal information):
== Mosquitos Diogo - P110 == Host: 172.16.23.73 Port: 80 Device state: False == Generic information == Time: 2024-02-26 23:39:44+00:00 (tz: {'timezone': 'Europe/Lisbon'} Hardware: 1.0 Software: 1.0.7 Build 210629 Rel.174901 MAC (rssi): AA:BB:CC:DD:EE:FF (-56) Location: {'latitude': 0.0, 'longitude': 0.0} == Device specific information == overheated: False signal_level: 2 SSID: MY_SSID == Features == Device ID (device_id): MY_DEVICE_ID State (state): False Signal Level (signal_level): 2 RSSI (rssi): -56 SSID (ssid): MY_SSID Overheated (overheated): False Overheated (overheated): False On since (on_since): None Cloud connection (cloud_connection): True Current consumption (current_consumption): 0.0 Today's consumption (today's_consumption): 0 This month's consumption (this_month's_consumption): 0 Auto update enabled (auto_update_enabled): False Update available (update_available): True LED (led): False Time (time): 2024-02-26 23:39:44+00:00 == Current State == <EmeterStatus power=0.0 voltage=None current=None total=0> == Modules == + <Module CloudModule (cloud_connect) for 172.16.23.73> + <Module DeviceModule (device) for 172.16.23.73> + <Module EnergyModule (energy_monitoring) for 172.16.23.73> + <Module Firmware (firmware) for 172.16.23.73> + <Module LedModule (led) for 172.16.23.73> + <Module TimeModule (time) for 172.16.23.73>Here is mine:
P110(EU)_1.0_1.0.7.json
There are definitely quite some differences, some eventually caused by the fw version in each? If needed, I have a spare (another) P110, which I can upgrade to latest fw version (1.3.0), to check if it works better.
Yes, definitely supporting energy monitoring, and data is showing in Tapo app (even though 0).

Hardware and Software versions in Tapo app fit exactly what is reported (above) by cli

Please let me know if you need anything else.
sdb9696 commented on Feb 27, 2024
I think there are a couple of issues here:
rytilahti commented on Feb 27, 2024
Thanks for the fixture file, @pplucky, that's really helpful, and we should add it to our fixture collection! You could definitely try to perform a firmware update, that should fix it for you, but we should also fix this in the library.
@sdb9696
I think get_max_power and get_protection_power are likely for power_protection, no? Looking at the diff (diff P110.EU._1.0_1.0.7.json P110\(EU\)_1.0_1.2.3.json), the older firmware has energy_monitoring version 1 where-as the newer reports 2, so maybe we should just check for the version like we are doing for gradual on/off?
Add fixture for P110 sw 1.0.7 (#801)
pplucky commented on Feb 27, 2024
Beats me, also. The fact is that when using kasa from the latest master (installed via poetry after git clone), I managed to get that output.
I plugged something that would actually consume energy and here is output from Tapo app:

and the cli output:
or when calling emeter command:
Btw, is it normal that the Current and Voltage are both None?
This also seems to happen for the other P110 plug I have (which is in 1.1.5 and had no issues in being added to HA). In HA, no current and voltage sensors exist.
Now that I notice, I also didn't have these in the previous Tapo custom component, but just out of curiosity, I had 2 additional sensors:

These were probably obtained from device info properties overheated and rssi.
Please let me know if there's anything else you need/want me to check for this 1.0.7 plug before I upgrade its firmware ;-).
rytilahti commented on Feb 28, 2024
Yes, the device doesn't report this information. We are moving to a more dynamic approach for presenting the available information (see below) so this can be ignored for now.
Yes they are. We are moving towards supporting more devices and more features directly out-of-the-box but it involves lots of changes, targeting currently homeassistant 2024.4.
Add fixture for P110 sw 1.0.7 (python-kasa#801)