Have you actually downloaded and installed the custom component? There are 2 parts to this. If you’re only installing the card it will not work.
I have done both. The zha_map works from what I can see when call it and look at the logs. I probably have 3 or 4 hours dedicated exclusively to trying to get the card to work.
Trying to add a tradfri 5 button remote:
I’m using node red for my automation so I’m reading the zha_events there.
ZHA doesn’t seem to differentiate between left and right press.
Here are the mappings I found in node-red:
toggle: toggle
up: step_with_on_off
up_hold: move_with_on_off
down: step
down_hold: move
release_up/down: stop
left: press
left_hold: hold
right: press
right_hold: hold
release_left/right: release
Is there any way to rename these mapping to make a bit more sense? Also is there some way to differentiate between left and right click?
Or is there a better way to integrate zha in NR than listening to all events from “zha_events”
those mappings are the zcl command names. there are other arguments that you can use to determine which one it is.
1 Like
Hi, yeah I found more arguments which distinguish between the different directions.
I was just used to z2m where every button is one command.
@sillywalks - try the appdaemon app ControllerX. It will simplify your use of ZHA remotes 1000 fold…
1 Like
or just use device triggers in HA automations
1 Like
Added CC2531 and Hibro plug.
CC2531 - works
Hibro plug - somewhat works. Turns on and off, but the plug state is not kept.
I’ve got three Zigbee devices not working correctly in Home Assistant.
In Tuya Smart Life they worked just fine.
Two of them are battery powered “three button switches” (actually momentary push buttons).
Those two devices pair just fine to zha, but none of their buttons work.
{
"node_descriptor": "<Optional byte1=2 byte2=64 mac_capability_flags=128 manufacturer_code=4098 maximum_buffer_size=82 maximum_incoming_transfer_size=82 server_mask=11264 maximum_outgoing_transfer_size=82 descriptor_capability_field=0>",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x0000",
"in_clusters": [
"0x0000",
"0x0001",
"0x0006"
],
"out_clusters": [
"0x000a",
"0x0019"
]
},
"2": {
"profile_id": 260,
"device_type": "0x0000",
"in_clusters": [
"0x0001",
"0x0006"
],
"out_clusters": []
},
"3": {
"profile_id": 260,
"device_type": "0x0000",
"in_clusters": [
"0x0001",
"0x0006"
],
"out_clusters": []
}
},
"manufacturer": "_TZ3400_key8kk7r",
"model": "TS0043",
"class": "zigpy.device.Device"
}
{
"node_descriptor": "<NodeDescriptor byte1=2 byte2=64 mac_capability_flags=128 manufacturer_code=4098 maximum_buffer_size=82 maximum_incoming_transfer_size=82 server_mask=11264 maximum_outgoing_transfer_size=82 descriptor_capability_field=0>",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x0000",
"in_clusters": [
"0x0000",
"0x0001",
"0x0006",
"0x000a"
],
"out_clusters": [
"0x0019"
]
},
"2": {
"profile_id": 260,
"device_type": "0x0000",
"in_clusters": [
"0x0001",
"0x0006"
],
"out_clusters": []
},
"3": {
"profile_id": 260,
"device_type": "0x0000",
"in_clusters": [
"0x0001",
"0x0006"
],
"out_clusters": []
}
},
"manufacturer": "_TZ3000_a7ouggvs",
"model": "TS0043",
"class": "zigpy.device.Device"
}
Both devices are paired.
If I toggle the switch in HA, it stays at it’s position.
If I press a button on a device, the LED lights up, but HA does not seem to get anything.
In the Zigbee Integration UI, after I pressed the “+”, then “Show Logs” and then push button 1 on both switches, I get the log:
[0x5e25:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=38 command_id=253>
[0x5e25:1:0x0006] Unknown cluster-specific command 253
[0x5e25:1:0x0006] ZCL request 0x00fd: b'\x00'
[0x5e25:1:0x0006] No handler for cluster command 253
[0x5e25:1:0x0006]: received '253' command with b'\x00' args on cluster_id '6' tsn '38'
[0x8a9a:1:0x0001] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=63 command_id=Command.Report_Attributes>
[0x8a9a:1:0x0001] ZCL request 0x000a: [[<Attribute attrid=33 value=<TypeValue type=uint8_t, value=200>>]]
[0x8a9a:1:0x0001] Attribute report received: battery_percentage_remaining=200
[0x5e25:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=38 command_id=253>
[0x5e25:1:0x0006] Unknown cluster-specific command 253
[0x5e25:1:0x0006] ZCL request 0x00fd: b'\x00'
[0x5e25:1:0x0006] No handler for cluster command 253
[0x5e25:1:0x0006]: received '253' command with b'\x00' args on cluster_id '6' tsn '38'
[0x8a9a:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=64 command_id=253>
[0x8a9a:1:0x0006] Unknown cluster-specific command 253
[0x8a9a:1:0x0006] ZCL request 0x00fd: b'\x00'
[0x8a9a:1:0x0006] No handler for cluster command 253
[0x8a9a:1:0x0006]: received '253' command with b'\x00' args on cluster_id '6' tsn '64'
[0x8a9a:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=64 command_id=253>
[0x8a9a:1:0x0006] Unknown cluster-specific command 253
[0x8a9a:1:0x0006] ZCL request 0x00fd: b'\x00'
[0x8a9a:1:0x0006] No handler for cluster command 253
[0x8a9a:1:0x0006]: received '253' command with b'\x00' args on cluster_id '6' tsn '64'
Am I doing or expecting something in the wrong way here?
I’ll write about that third device in the next post because it’s mains powered and partly works.
I’ve got a mains powered “three button wall switch” that partly works.
It worked fine in Tuya Smart Life.
If I press any button on the physical switch, the state is reflected in HA.
If I toggle a switch in HA, only relay 1 (the left one) get’s toggled. Relays for buttons 2 and 3 are not switchable by HA.
{
"node_descriptor": "<NodeDescriptor byte1=1 byte2=64 mac_capability_flags=142 manufacturer_code=0 maximum_buffer_size=82 maximum_incoming_transfer_size=82 server_mask=11264 maximum_outgoing_transfer_size=82 descriptor_capability_field=0>",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x0100",
"in_clusters": [
"0x0000",
"0x0003",
"0x0004",
"0x0005",
"0x0006"
],
"out_clusters": [
"0x0019"
]
},
"2": {
"profile_id": 260,
"device_type": "0x0100",
"in_clusters": [
"0x0000",
"0x0003",
"0x0004",
"0x0005",
"0x0006"
],
"out_clusters": [
"0x0019"
]
},
"3": {
"profile_id": 260,
"device_type": "0x0100",
"in_clusters": [
"0x0000",
"0x0003",
"0x0004",
"0x0005",
"0x0006"
],
"out_clusters": [
"0x0019"
]
}
},
"manufacturer": "_TYZB01_b8cr31hp",
"model": "TS0003",
"class": "zigpy.device.Device"
}
…btw:
All my other 60 Zigbee devices work perfectly fine with HA.
You guys did a fantastic job! 
If I toggle a switch in HA, only relay 1 (the left one) get’s toggled. Relays for buttons 2 and 3 are not switchable by HA.
CC2531/zigpy-cc???
IMO Tuya is leaping ahead of xiaomi on “how not to interpret zigbee standards”
For that “device_type: 0x0000” and the actual physical devices, the “on_off” cluster should be on the “out_clusters” side and the device should generate events. This needs a quirk, but with that pace anything from Tuya would need a quirk, meh.
1 Like
CC2531/zigpy-cc???
Yes.
This needs a quirk
How can I help?
Yeah, there’s a problem with zigpy-cc. you could try switching to https://github.com/zha-ng/zigpy-znp but currently no user friendly way to do the switch.
You could try copying the zha folder from core/homeassistant/components/zha at dev · home-assistant/core · GitHub as a zha folder into /config/custom_components and then applying the following changes:
diff --git a/homeassistant/components/zha/core/const.py b/homeassistant/components/zha/core/const.py
index 63652f58f3..9248fa12eb 100644
--- a/homeassistant/components/zha/core/const.py
+++ b/homeassistant/components/zha/core/const.py
@@ -9,6 +9,7 @@ import zigpy_cc.zigbee.application
import zigpy_deconz.zigbee.application
import zigpy_xbee.zigbee.application
import zigpy_zigate.zigbee.application
+import zigpy_znp.zigbee.application
from homeassistant.components.binary_sensor import DOMAIN as BINARY_SENSOR
from homeassistant.components.climate import DOMAIN as CLIMATE
@@ -177,6 +178,10 @@ class RadioType(enum.Enum):
"deCONZ = dresden elektronik deCONZ protocol: ConBee I/II, RaspBee I/II",
zigpy_deconz.zigbee.application.ControllerApplication,
)
+ znp = (
+ "TI_ZNP = Texas Instruments Z-Stack ZNP protocol: CC253x, CC26x2, CC13x2",
+ zigpy_znp.zigbee.application.ControllerApplication,
+ )
ti_cc = (
"TI_CC = Texas Instruments Z-Stack ZNP protocol: CC253x, CC26x2, CC13x2",
zigpy_cc.zigbee.application.ControllerApplication,
diff --git a/homeassistant/components/zha/manifest.json b/homeassistant/components/zha/manifest.json
index bb5da313a5..bbe4b7e023 100644
--- a/homeassistant/components/zha/manifest.json
+++ b/homeassistant/components/zha/manifest.json
@@ -7,6 +7,7 @@
"bellows==0.18.1",
"pyserial==3.4",
"zha-quirks==0.0.43",
+ "git+https://github.com/zha-ng/zigpy-znp@dev#zigpy-znp==0.1.0",
"zigpy-cc==0.5.1",
"zigpy-deconz==0.9.2",
"zigpy==0.22.2",
and then you either have to remove the integration and configure it manually again but this time choosing ZNP radio — This would kill zha entities customizations, or you could edit .storage/core.config_entries and change the radio type to znp
FWIW - so far I’ve had pretty good luck with tuya based contact, temp/humidity, leak sensors and a valve controller. all work out of the box with no quirks. I also have a tuya based MOES power socket that works as well, but has clusters for power monitoring but doesn’t really support them, so you just need to disable the entities it creates. can’t speak to buttons/switches.
Yeah, there’s a problem with
zigpy-cc. you could try switching tohttps://github.com/zha-ng/zigpy-znpbut currently no user friendly way to do the switch.
I copied zha into the custom_components folder, patched it, and restarted HA to check if Zigbee still works.
Then I changed “radio_type”: “ti_cc” in core.config_entries to “radio_type”: “nzp” and restarted HA.
After restarting HA all Zigbee devices were offline.
I also tried rebooting the whole Raspi with or without unplugging the Zigbee USB Stick, same result.
After changing “radio_type” back to “ti_cc”, the Zigbee devices were online again.
I guess I need a different stick.
Should be znp – lowercase. not sure if you did typo here or in the config_entries file. enable debug logging to see more post issue in znp repo
Yes, it was a typo. 
My report before: “all devices are online” was wrong.
Devices show as online, but I can’t see any Zigbee status updates anymore nor can I set switches (“ti_cc” and “znp”).
Even after restoring a snapshot (made just before znp) an deleting the custom_components/zha folder.
I need to get my sensors online again before I can test further.
I guess YMMV. I have a three gang Tuya wall switch, and basic functions work fine, but:
- no group support, having each endpoint in a different group or same
- no on_off client cluster, so I can’t bind it directly to other Zigbee lights
But also based on signatures submitted for Tuya devices in zha-device-handlers seems like at least some of their devices not following any standards.
ZHA with Conbee II usb stick, running HA container.
I have sylvania zigbee bulbs in the network. I plugged one bulb at a recessed ceiling housing, but it often doesn’t work after a while, showing unavailable from the UI. The bulb itself works as I tested it in other power outlet. Tested with another bulbs and resulted same. Is this because the housing actually affect zigbee signal? The spot is much closer to the conbee ii stick. Also I noticed the bulb was hot when I took it out. Does anyone have similar experience and is there a way to fix this?
thanks.
Hi.
I’m having some instability with the ZigBee network using the Sonoff bridge with tasmota-zbbridge.bin](http://ota.tasmota.com/tasmota/release/tasmota-zbbridge.bin).
I have about 15 Zemismart switches here, the first 5 were very easy to pair, then a great instability started and the devices did not synchronize with the bridge and I don’t know why.
Here is the Logs
0xf38a:1:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=121 command_id=1>
[0xf38a:1:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0xf38a:1:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW03LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0xf38a:1:0x0019] No OTA image is available
[0x0edf:1:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=89 command_id=1>
[0x0edf:1:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0x0edf:1:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW03LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0x0edf:1:0x0019] No OTA image is available
Device 0x5479 (00:15:8d:00:04:62:6a:50) left the network
And here
Here is the Log Device 0x5479 (SECRET) joined the network Skip initialization for existing device 00:15:8d:00:04:62:6a:50 Device 0x5479 (SECRET) joined the network Skip initialization for existing device [00:15]:8d:00:04:62:6a:50 [0x5479] Cancelling old group rescan [0x5479:zdo] ZDO request ZDOCmd.Device_annce: [0x5479, SECRET, 142] [0x5479:11:0x0004] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=173 command_id=2> [0x5479:11:0x0004] ZCL request 0x0002: [16, []] [0x5479:11:0x0004] No handler for cluster command 2 [0x5479:11:0x0004] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=175 command_id=2> [0x5479:zdo] ZDO request ZDOCmd.Node_Desc_req: [0x0000] [0x5479:zdo] Unsupported ZDO request:ZDOCmd.Node_Desc_req