[TapoControl] - Control Tapo Smart WiFi-Devices with Openhab - Official Support Thread

Unfortunately, still the same:

14:42:31.544 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:5dd2373e6f' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
14:42:31.810 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:5dd2373e6f' changed from INITIALIZING to UNKNOWN
14:42:31.828 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:P110:779a193b58' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
14:42:31.837 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:P110:779a193b58' changed from INITIALIZING to OFFLINE (CONFIGURATION_ERROR): no bridge configured
14:42:33.009 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:5dd2373e6f' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): API rate limit exceeded (-20004)

But the issue is not that the configuration is rejected because of an invalid format, but no bridge is configured. Did you configure a bridge for that thing?

@J-N-K Bridge is probalby not created because of the config error.
Testet it wir Snapshot #3103 ant the issue is still there.
See [tapocontrol] Add support for P115 smart-socket by wildcs · Pull Request #13225 · openhab/openhab-addons · GitHub

But it does not say “Bridge offline”, it says “no bridge configured”. Looking at the code this means that the bridge is not set. The bridge is offline because of “API rate limit exceeded”. This has nothing to do with config validation in core.

You have to configure the bridge on the plug thing and check why your API rate limit is exceeded.

Okay the API-Rate exceeded is new. but is nothing to do with the configuration issue.
Got ist at the moment still on the old versions. Mabybe it could be that the bridge tries to connect too much time because of the configuration error.

Fair point and sorry for the confusion, for testing purposes I tried to use the thing without a bridge (had the hope that it could directly connect to the IP without cloud). So with the bridge configured I’m back to the API rate limit:

09:22:21.947 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:5dd2373e6f' changed from UNINITIALIZED (DISABLED) to INITIALIZING
09:22:22.234 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:5dd2373e6f' changed from INITIALIZING to UNKNOWN
09:22:22.243 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:P110:779a193b58' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
09:22:22.249 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:P110:779a193b58' changed from INITIALIZING to UNKNOWN
09:22:23.404 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:5dd2373e6f' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): API rate limit exceeded (-20004)
09:22:23.408 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:P110:779a193b58' changed from UNKNOWN to OFFLINE (BRIDGE_OFFLINE)
09:22:26.255 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:P110:779a193b58' changed from OFFLINE (BRIDGE_OFFLINE) to OFFLINE (COMMUNICATION_ERROR): Device Offline

I don‘t know the reason for that, but it‘s inside the binding, not a core issue. Sorry.

Just to add, I’m also seeing the API rate limit exceeded (-20004) when setting up the bridge, even with the configuration issues fixed using the snapshot jar. Any guidance on how we can narrow down what’s going wrong? The Tapo app is working fine with the same account details and inside the same network, so I don’t think it’s blocking at an account or IP level.

I think that we have two different problems:

  1. error reading device-configuration: 'For input string: "30.0"'
  2. API rate limit exceeded (-20004)

So I’ve decided to go back to 3.3.0 and the API rate limit exceeded (-20004) exists. I’m sure that 2 months ago it did not exist on 3.3.0, so I believe that something has changed in the Tapo Cloud and @Bigdesaster needs to investigate it further, otherwise pairing new devices with OH may be at risk.

I don’t know if error reading device-configuration: 'For input string: "30.0"' has any consequence, but in my opinion it is not causing the API rate limit exceeded (-20004) problem. I had error reading device-configuration: 'For input string: "30.0"' during several weeks (including weeks where I was using 3.4.0.M2) and only recently (maybe 3 days ago) I’ve started having the API rate limit exceeded (-20004) problem.

Now I’m back to 3.4.0.M2 but if further tests are necessary with 3.3.0 pls let me know.

I have the same issue, I installed tapocontrol 3.4.0.M2 (from the jar in GH here: https://github.com/wildcs/oh3_tapocontrol/blob/main/org.openhab.binding.tapocontrol-3.4.0-SNAPSHOT.jar) I have just the cloud binding and nothing else. Fresh install of openhab 3.3.0

UID: tapocontrol:bridge:f38aa99189
label: Cloud-Login
thingTypeUID: tapocontrol:bridge
configuration:
  password: REDACTED
  cloudDiscovery: false
  cloudReconnect: 1440
  discoveryInterval: 60
  username: REDACTED

With trace logs on, when I enable the module I get this:

12:06:07.966 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:f38aa99189' changed from OFFLINE (COMMUNICATION_ERROR): API rate limit exceeded (-20004) to UNINITIALIZED
12:06:08.029 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:f38aa99189' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
12:06:09.624 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:f38aa99189' changed from UNINITIALIZED (DISABLED) to INITIALIZING
12:06:09.660 [TRACE] [trol.internal.helpers.TapoCredentials] - encrypt credentials for 'REDACTED'
12:06:09.669 [TRACE] [trol.internal.helpers.TapoCredentials] - generating new keypair
12:06:10.277 [TRACE] [trol.internal.helpers.TapoCredentials] - new privateKey: REDACTED'
12:06:10.289 [TRACE] [trol.internal.helpers.TapoCredentials] - new ublicKey: REDACTED
12:06:10.305 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:f38aa99189' changed from INITIALIZING to UNKNOWN
12:06:11.302 [DEBUG] [rol.internal.device.TapoBridgeHandler] - tapocontrol:bridge:f38aa99189 login with user REDACTED
12:06:11.389 [TRACE] [ntrol.internal.api.TapoCloudConnector] - cloud returns error: '{"error_code":-20004,"msg":"API rate limit exceeded"}'
12:06:11.404 [TRACE] [rol.internal.device.TapoBridgeHandler] - tapocontrol:bridge:f38aa99189 starting bridge cloud sheduler
12:06:11.408 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'tapocontrol:bridge:f38aa99189' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): API rate limit exceeded (-20004)

Yes youre right @moody_blue
This are two different problems

  1. error reading device-configuration: 'For input string: "30.0"' is core problem @J-N-K
  2. API rate limit exceeded (-20004) is a binding problem. Seems Tapo chanced sth with his cloud communication. I have to check this.

Again: the core issue is fixed. If you use latest snapshots, it‘ll not occur. Since it was present in 3.3 release any new install of 3.3 will of course show the same problem.

@JNK since which build is it fixed? Testet it with actual latest snapshot from openhab site (3103) and the error is still there.

You use the latest snapshot and get the error reading device-configuration: 'For input string: "30.0"' error?

As i postet above i downloaded the latest snapshot and still got this error yes.
Look also here [tapocontrol] Add support for P115 smart-socket by wildcs · Pull Request #13225 · openhab/openhab-addons · GitHub

Please show the yaml (code-view) of the bridge thing. I’ll check that. If there is a username/password, just exchange it with username/password. For checking initialization it doesn’t matter if the login succeeds.

UID: tapocontrol:bridge:40c0159c96
label: Cloud-Login
thingTypeUID: tapocontrol:bridge
configuration:
  password: xxxxxx
  cloudDiscovery: false
  discoveryInterval: 60
  username: xxxxxx

Login is actually not working cause of the other issue. But the things will work even if bridge (cloud) is offline.
Issue is not only in bridge. Same issue with thing configuration:

UID: tapocontrol:P100:40c0159c96:C0C9E3Axxxx
label: Tapo P100 SmartPlug
thingTypeUID: tapocontrol:P100
configuration:
  ipAddress: 192.168.xxxx
  pollingInterval: 30
bridgeUID: tapocontrol:bridge:40c0159c96

I can’t reproduce that. I have downloaded latest snapshot (which is #3106, I’m not sure which build date #3103 has, the PR was merged 9 days ago and usually a build is done every night), installed the TapoControl binding and created a bridge. The JSON db looks like that:

{
  "tapocontrol:bridge:78f0d84e00": {
    "class": "org.openhab.core.thing.internal.ThingStorageEntity",
    "value": {
      "isBridge": true,
      "channels": [],
      "label": "Cloud-Login",
      "configuration": {
        "cloudDiscovery": false,
        "discoveryInterval": 60,
        "password": "yxc",
        "username": "ydxc"
      },
      "properties": {},
      "UID": "tapocontrol:bridge:78f0d84e00",
      "thingTypeUID": "tapocontrol:bridge"
    }
  }
}

which should not create any issues. I then edited it to provide a double (which may be the case in older installations)

{
  "tapocontrol:bridge:78f0d84e00": {
    "class": "org.openhab.core.thing.internal.ThingStorageEntity",
    "value": {
      "isBridge": true,
      "channels": [],
      "label": "Cloud-Login",
      "configuration": {
        "cloudDiscovery": false,
        "discoveryInterval": 60.0,
        "password": "yxc",
        "username": "ydxc"
      },
      "properties": {},
      "UID": "tapocontrol:bridge:78f0d84e00",
      "thingTypeUID": "tapocontrol:bridge"
    }
  }
}

and tried again and there is still no error.

I’ve only been using OpenHAB for a few days and I’m impacted by the “API rate limit” issue. After some debugging, it seems like the plugin is hard-coded to use the terminal UUID 0A950402-7224-46EB-A450-7362CDB902A2, which results in {"error_code":-20004,"msg":"API rate limit exceeded"} being returned by the API no matter what username/password you specify. I imagine this is because everyone’s TapoBridge plugin is using the same value.

If I change the UUID to something else, it succeeds:

I’ll see if I can come up with a PR to fix this, although if anyone else more familiar with the codebase wants to try, I’m happy to let them.

1 Like

@J-N-K
Every night could not be, cause i downloaded 3103 two or three days ago.
Then it could be that the core fix was merged after 3103 snapshot. let us review in a few days. :crazy_face:

@Poggs
Thank you for hour hint. :+1: .
I think that should be the reason. If yo are on the way to fix it you can do. Otherwise i can fix it tomorrow or the day after.

1 Like