Device not useable after pairing (Smart Plugs) - [zigpy.appdb] Error handling '_save_attribute' event

[V4n1X]

Fist I use a conbee2 stick with ZHA (zigpy-deconz).
I have a large zigbee network, with devices from OSRAM (Ledvance), IKEA, Philips Hue and some Xiaomi / Aqara. Every device works without any problems but now I wanted a new plug with power metering. I bought a Tuya TS011F Plug, updated it to the latest firmware with zigbee2mqtt with my conbee2 in the company.

So now I would like to pair it with ZHA -> Pairing Ok -> Uncontrollable after pairing success. Tried it again and again, no success.
Then I tried it again with zigbee2mqtt, plug works without problems after pairing.

Okay maybe strange behaviour, now I bought a Aqara Smart Plug (Model: SP-EUC01)
Pairing success -> Uncontrollable after pairing.

So there must be some error. I checked the log and I see this that looks strange:

2022-08-11 16:56:33.429 DEBUG (MainThread) [zigpy.appdb] Error handling '_save_attribute' event with (54:ef:44:10:00:4d:c4:4e, 1, 0, 4, 'LUMI') params: FOREIGN KEY constraint failed

Also while pairing, device configures 2 / 3 times, that also happen with the cheap Tuya plug.

FullLog-Zigbee-Aqara-Pairing.log

[hellow554]

I may have a similar issue with the exact same plug.
Quick question: when you try to pair your device:
a) does the plug still blinks, even though HA says that pairing is done?
b) if you pair the device and you're quick enough: can you control the plug for roughly 5 to 10 seconds? (just toggle it on and off for a certain period of time)

If yes, I have the exact same issues and here's my HA community post about it which provides some more information: https://community.home-assistant.io/t/problem-pairing-with-nous-a1z-smart-plug/447400

I also tried it first with nous plugs (amazon link) and they show the same behavoir.
I ordered some from silvercrest (lidl) and try them this weekend, let's see if they work.

Another thing: I tried zigbee2mqtt which didn't work for me either (with the nous plugs), but both (nous and aqara) work with the deconz addon. Pairing is no problem there at all.

[V4n1X]

a) does the plug still blinks, even though HA says that pairing is done?
-> Yes and then reconfiguration starts 1-2 times until pairing mode is disabled.
b) if you pair the device and you're quick enough: can you control the plug for roughly 5 to 10 seconds? (just toggle it on and off for a certain period of time)
-> Yes correctly, and I guess when pairing mode stops then I loose control over it.

Same with Tuya Plug (exact model: tz3000_cehuw1lw_ts011f)

Here is a full log from the Tuya plug attached

FullLog-Zigbee-Tuya-TS011F-Pairing.log

Also I see the same error in your log:

2022-08-05 21:36:45.682 DEBUG (MainThread) [zigpy.appdb] Error handling '_save_attribute' event with (a4:c1:38:94:78:77:a1:b7, 1, 0, 4, '_TZ3000_ksw8qtmt') params: FOREIGN KEY constraint failed
2022-08-05 21:36:45.702 DEBUG (MainThread) [zigpy.appdb] Error handling '_save_attribute' event with (a4:c1:38:94:78:77:a1:b7, 1, 0, 5, 'TS011F') params: FOREIGN KEY constraint failed

Maybe this helps also to find the problem:

2022-08-12 18:27:48.755 DEBUG (MainThread) [zigpy.zdo] [0x2f2b:zdo] ZDO request ZDOCmd.Node_Desc_req: [0x0000]
2022-08-12 18:27:48.755 DEBUG (MainThread) [zigpy.zdo] [0x2f2b:zdo] No handler for ZDO request:ZDOCmd.Node_Desc_req([0x0000])

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4417, maximum_buffer_size=66, maximum_incoming_transfer_size=66, server_mask=10752, maximum_outgoing_transfer_size=66, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x010a",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0004",
        "0x0005",
        "0x0006",
        "0x0702",
        "0x0b04",
        "0xe000",
        "0xe001"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZ3000_cehuw1lw",
  "model": "TS011F",
  "class": "zhaquirks.tuya.ts011f_plug.Plug"
}

zha-diagnostics.txt

[DorianStrasser]

Now I join this club but with one additional information: All the behavior mentioned in this ticket is reproducible (blinking after pairing, shortly controllable device), BUT I do not use deconz (recently migrated to SkyConnect). It has nothing to do with that specific hardware but zigpy in general.

I would gladly provide further information if it is helpful.

[puddly]

All of these messages are logged as DEBUG because they are not errors, they're expected to happen for a device that has not finished initialization. This sounds like a Tuya problem.

[V4n1X]

I can post an update here. My plug is working fine since weeks now. What I have done is, I completely wiped all zigbee configuration, database etc and paired everything again with ZHA running HomeAssistant SkyConnect, before that I was also succesful with the deconz stick and ZHA but the trick was to clean everything zigbee related after deleting all integrations and enties from HA. So that my Zigbee setup is clean. I guess it was some database write error in a pairing procedure and this cant be fixed with deleting the device and repairing it. I also experimented with some zigbee.db database tools but that doesnt fix that problem. My plug works now fine, no disconnects, no random switch offs, everything works like a charm.

[jschaeke]

I've got the same issue also explained here: https://community.home-assistant.io/t/tuya-zigbee-ts011f-issue/507221/2 . Today I tried cleaning up the zigbee.db file (manually removing the plug from all the tables using its ieee) and even disabling the foreign keys of the offending table but nothing seems to work. Would like to avoid repairing all my zigbee devices.

[V4n1X]

Would like to avoid repairing all my zigbee devices.

Yes, I would also like to avoid that way, but that doesnt worked for me. So the only solution I found, is stop ZHA and remove the ZHA integration. Then remove all left over files like the db, from the ZHA stuff. I rebooted HA completely and do a fresh start with ZHA integration. Since that, I have not even one problem with the plug.

[puddly]

I think a few things need to be cleared up before people start destroying their networks unnecessarily.

There's no need to touch or "clean" zigbee.db: the file is checked for integrity every startup and you'd get a prominent error message telling you if it's in any way corrupted.

The specific debug log message mentioned here is completely normal: it shows up every single time you join a device. It's logged under the normally-invisible DEBUG level specifically because it's not considered an error, as it's expected that an uninitialized device won't be persisted into the database.

If the device is unusable after joining, the database has no relation with this issue because it's merely used as a cache for incoming data, and to keep track of the IEEE -> NWK mapping for individual devices. Every Zigbee device sends data periodically back to the coordinator so if its NWK address changed, zigpy would re-discover its IEEE address immediately.

What I have done is, I completely wiped all zigbee configuration, database etc and paired everything again with ZHA running HomeAssistant SkyConnect

The move away from the Conbee is likely the only change that made a difference. The Conbee is known to have weird firmware routing issues.

The alternative is because your network's channel was not 15. Re-forming a new ZHA network will do so on channel 15 instead of whatever your stick currently has (likely 11 if used with Z2M).