[Device Support Request] Neo/Tuya Siren without Sensors _TZE200_t1blo2bj TS0601

[jerrm]

This is a Neo/Tuya Siren without sensors.

Using Home Assistant 2022.2.8, no controls some in other than

Signature after adding:

{
  "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": "0x0051",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0xef00"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "242": {
      "profile_id": 41440,
      "device_type": "0x0061",
      "in_clusters": [],
      "out_clusters": [
        "0x0021"
      ]
    }
  },
  "manufacturer": "_TZE200_t1blo2bj",
  "model": "TS0601",
  "class": "zigpy.device.Device"
}

Logs:

[0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_rsp: [<Status.SUCCESS: 0>]
[0x0000:zdo] No handler for ZDO request:ZDOCmd.Mgmt_Permit_Joining_rsp([<Status.SUCCESS: 0>])
New device 0x517d (a4:c1:38:4c:8b:eb:9e:2b) joined the network
[0x517d] Scheduling initialization
Received frame on uninitialized device <Device model=None manuf=None nwk=0x517D ieee=a4:c1:38:4c:8b:eb:9e:2b is_initialized=False> from ep 0 to ep 0, cluster 19: b'\x00}Q+\x9e\xeb\x8bL8\xc1\xa4\x8e'
[0x517d:zdo] ZDO request ZDOCmd.Device_annce: [0x517D, a4:c1:38:4c:8b:eb:9e:2b, 142]
Tries remaining: 3
[0x517d] Requesting 'Node Descriptor'
Tries remaining: 2
[0x517d] Extending timeout for 0x1f request
Received frame on uninitialized device <Device model=None manuf=None nwk=0x517D ieee=a4:c1:38:4c:8b:eb:9e:2b is_initialized=False> from ep 0 to ep 0, cluster 32770: b'\x1f\x00}Q\x01@\x8eA\x11BB\x00\x00*B\x00\x00'
[0x517d] Got 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)
[0x517d] Discovering endpoints
Tries remaining: 3
Received frame on uninitialized device <Device model=None manuf=None nwk=0x517D ieee=a4:c1:38:4c:8b:eb:9e:2b is_initialized=False> from ep 0 to ep 0, cluster 32773: b' \x00}Q\x02\x01\xf2'
[0x517d] Discovered endpoints: [1, 242]
[0x517d] Initializing endpoints [<Endpoint id=1 in=[] out=[] status=<Status.NEW: 0>>, <Endpoint id=242 in=[] out=[] status=<Status.NEW: 0>>]
[0x517d:1] Discovering endpoint information
Tries remaining: 3
Received frame on uninitialized device <Device model=None manuf=None nwk=0x517D ieee=a4:c1:38:4c:8b:eb:9e:2b is_initialized=False> from ep 0 to ep 0, cluster 32772: b'!\x00}Q\x14\x01\x04\x01Q\x00\x01\x04\x04\x00\x05\x00\x00\xef\x00\x00\x02\x19\x00\n\x00'
[0x517d:1] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=81, device_version=1, input_clusters=[4, 5, 61184, 0], output_clusters=[25, 10])
Unknown cluster 61184
[0x517d:242] Discovering endpoint information
Tries remaining: 3
Received frame on uninitialized device <Device model=None manuf=None nwk=0x517D ieee=a4:c1:38:4c:8b:eb:9e:2b is_initialized=False> from ep 0 to ep 0, cluster 32772: b'"\x00}Q\n\xf2\xe0\xa1a\x00\x00\x00\x01!\x00'
[0x517d:242] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=242, profile=41440, device_type=97, device_version=0, input_clusters=[], output_clusters=[33])
[0x517d:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=35 command_id=Command.Read_Attributes_rsp>
[0x517d] Read model 'TS0601' and manufacturer '_TZE200_t1blo2bj' from <Endpoint id=1 in=[groups:0x0004, scenes:0x0005, None:0xEF00, basic:0x0000] out=[ota:0x0019, time:0x000A] status=<Status.ZDO_INIT: 1>>
[0x517d] Discovered basic device information for <Device model='TS0601' manuf='_TZE200_t1blo2bj' nwk=0x517D ieee=a4:c1:38:4c:8b:eb:9e:2b is_initialized=True>
Device is initialized <Device model='TS0601' manuf='_TZE200_t1blo2bj' nwk=0x517D ieee=a4:c1:38:4c:8b:eb:9e:2b is_initialized=True>
Checking quirks for _TZE200_t1blo2bj TS0601 (a4:c1:38:4c:8b:eb:9e:2b)
Considering <class 'zhaquirks.xbee.xbee_io.XBeeSensor'>
Fail because endpoint list mismatch: {232, 230} {1, 242}
Considering <class 'zhaquirks.xbee.xbee3_io.XBee3Sensor'>
Fail because endpoint list mismatch: {232, 230} {1, 242}
Considering <class 'zhaquirks.smartthings.tag_v4.SmartThingsTagV4'>
Fail because endpoint list mismatch: {1} {1, 242}
Considering <class 'zhaquirks.smartthings.multi.SmartthingsMultiPurposeSensor'>
Fail because endpoint list mismatch: {1} {1, 242}
Considering <class 'zhaquirks.netvox.z308e3ed.Z308E3ED'>
Fail because endpoint list mismatch: {1} {1, 242}
Considering <class 'zhaquirks.gledopto.soposhgu10.SoposhGU10'>
Fail because endpoint list mismatch: {11, 13} {1, 242}
Considering <class 'bellows.zigbee.application.EZSPCoordinator'>
Fail because endpoint list mismatch: {1} {1, 242}
'sensor' component -> 'RSSISensor' using ['basic']
'sensor' component -> 'LQISensor' using ['basic']
device - 0x517D:a4:c1:38:4c:8b:eb:9e:2b entering async_device_initialized - is_new_join: True
device - 0x517D:a4:c1:38:4c:8b:eb:9e:2b has joined the ZHA zigbee network
[0x517D](TS0601): started configuration
[0x517D:ZDO](TS0601): 'async_configure' stage succeeded
Error handling '_save_attribute' event with (a4:c1:38:4c:8b:eb:9e:2b, 1, 0, 4, '_TZE200_t1blo2bj') params: FOREIGN KEY constraint failed
[0x517D:1:0x0000]: finished channel configuration
[0x517D:1:0x0019]: finished channel configuration
[0x517D:1:0x0000]: 'async_configure' stage succeeded
[0x517D:1:0x0019]: 'async_configure' stage succeeded
Error handling '_save_attribute' event with (a4:c1:38:4c:8b:eb:9e:2b, 1, 0, 5, 'TS0601') params: FOREIGN KEY constraint failed
[0x517D](TS0601): completed configuration
[0x517D](TS0601): stored in registry: ZhaDeviceEntry(name='_TZE200_t1blo2bj TS0601', ieee='a4:c1:38:4c:8b:eb:9e:2b', last_seen=1645382468.5321298)
[0x517D](TS0601): started initialization
[0x517D:ZDO](TS0601): 'async_initialize' stage succeeded
[0x517D:1:0x0000]: initializing channel: from_cache: False
[0x517D:1:0x0000]: finished channel initialization
[0x517D:1:0x0019]: initializing channel: from_cache: False
[0x517D:1:0x0019]: finished channel initialization
[0x517D:1:0x0000]: 'async_initialize' stage succeeded
[0x517D:1:0x0019]: 'async_initialize' stage succeeded
[0x517D](TS0601): power source: Mains
[0x517D](TS0601): completed initialization
[0xdd45:1:0x0702] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=110 command_id=Command.Report_Attributes>
[0xdd45:1:0x0702] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=uint48_t, value=0>)]]
[0xdd45:1:0x0702] Attribute report received: current_summ_delivered=0

[jerrm]

Don't know if it helps, but looks like it may be supported in zigbee2mqtt as Neo NAS-AB02B2. https://github.com/Koenkk/zigbee2mqtt/issues/10348

I don't currently have another install to test under z2m to confirm, hopefully will get a spare usb stick this week to play with.

[javicalle]

Similar to #1236 but with a GreenPowerProxy cluster.

Can you attach the logs when poweroff&poweron the device?

[javicalle]

According to the zigbee2mqtt thread, there could be the following DPs:

    // Neo AlarmOnly
    neoAOBattPerc: 15,
    neoAOMelody: 21,
    neoAODuration: 7,
    neoAOAlarm: 13,
    neoAOVolume: 5,

[jerrm]

Can you attach the logs when poweroff&poweron the device?

Requested logs attached. I enabled logging following the HA ZHA page, and then filtered using a simple "grep -i z" to remove most non-zigbee messages. Let me know if there is a better way.

There is no power button, so "poweroff" was simply pulling power from the device. The "power" logs amount to about 1 minute of logging starting immediately before applying/removing power.

According to the zigbee2mqtt thread, there could be the following DPs:

You're above my head on what to do with the info (if anything).

This is the first device that I've had issues with, so ZHA has been firmly in the "it just works" category for me, and I'm not familiar with the underside.

Thanks...

power_down_siren.log power_up_siren.log add_siren.log

[javicalle]

I have implemented the quirk that should work but I can't validate if it works.

You can configure your local quirk in HA according to https://github.com/zigpy/zha-device-handlers/discussions/693#discussioncomment-857274 and put the attached file inside the new folder. You will need to rename the file to remove the .txt extension so that the file name becomes ts0601_siren_1.py. Restart HA and check the boot traces for possible problems.

Please validate if it works and report the logs if something is not working as it should.

ts0601_siren_1.py.txt

edit: remove bad version

[jerrm]

I will test this evening.

[jerrm]

Not much luck with the new file. After some tweaks, the new quirk gets used, but device is still not functional. The only control after adding the device is an apparently non-functional on_off control.

At first zha was broken, logs pointed to a tab in line 273 and two undefined names. I added TuyaLocalCluster & ATTR_ON_OFF to the line 31 zhaquirks.tuya import. No idea if that was anywhere close to a proper fix, but it got things running enough to get some logs (attached).

Happy to provide anything else needed.

add_siren.log power_up_siren.log

[stephenjamieson]

Seeing the same:

NameError: name 'ATTR_ON_OFF' is not defined

[jerrm]

@javicalle - I got my second zigbee stick in and set up with zigbee2mqtt. Device works in z2m, but would still prefer ZHA.

If any z2m logs or info is helpful, I will gladly provide.

[stephenjamieson]

Happy to test or provide any info as well.

[javicalle]

I'm sorry I didn't respond sooner, but lately I don't have time to dedicate myself to this. I have created a new implementation. I've checked the imports and I think I haven't missed anything. It should be compatible with HA zha-device-handlers version 2022.03. Not sure if it would be compatible with any older version.

~~Please replace the old version with this one. ts0601_siren_1.py.txt~~

The volume, alarm_duration, melody and battery will be attributes of NeoSirenManufCluster. All excepts battery should be possible to be setted.

edit: remove bad version

[stephenjamieson]

Error setting up entry /dev/controller-zigbee for zha
Traceback (most recent call last):
  File "/root/homeassistant/lib/python3.9/site-packages/homeassistant/config_entries.py", line 335, in async_setup
    result = await component.async_setup_entry(hass, self)
  File "/root/homeassistant/lib/python3.9/site-packages/homeassistant/components/zha/__init__.py", line 99, in async_setup_entry
    setup_quirks(config)
  File "/root/homeassistant/lib/python3.9/site-packages/zhaquirks/__init__.py", line 403, in setup
    importer.find_module(modname).load_module(modname)
  File "<frozen importlib._bootstrap_external>", line 529, in _check_name_wrapper
  File "<frozen importlib._bootstrap_external>", line 1034, in load_module
  File "<frozen importlib._bootstrap_external>", line 859, in load_module
  File "<frozen importlib._bootstrap>", line 274, in _load_module_shim
  File "<frozen importlib._bootstrap>", line 711, in _load
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 851, in exec_module
  File "<frozen importlib._bootstrap_external>", line 988, in get_code
  File "<frozen importlib._bootstrap_external>", line 918, in source_to_code
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/root/.homeassistant/custom_zha_quirks/ts0601_siren_1.py", line 230
    TUYA_ALARM_ATTR: ("alarm", t.uint8_t),
    ^
SyntaxError: invalid syntax

[stephenjamieson]

Ah I see the comma is missing from the previous line for the dict. Line 316 also has a tab instead of spaces, so python is crying.

I'm not so sure about the next one

  File "/root/.homeassistant/custom_zha_quirks/ts0601_siren_1.py", line 274, in <module>
    class NeoSirenManufCluster(TuyaMCUCluster):
  File "/root/.homeassistant/custom_zha_quirks/ts0601_siren_1.py", line 277, in NeoSirenManufCluster
    dp_to_attribute: Dict[int, DPToAttributeMapping] = {
NameError: name 'Dict' is not defined

edit:

imported

from typing import Dict

[stephenjamieson]

Still didn't work for me with the following changes, but I'll let @javicalle try too:

diff ts0601_siren_1.py.txt ts0601_siren_1.py
1a2,3
> from typing import Dict
>
229c231
<         TUYA_BATTERY_ATTR: ("battery", t.uint32_t)
---
>         TUYA_BATTERY_ATTR: ("battery", t.uint32_t),
316c318
<   signature = {
---
>     signature = {

[javicalle]

Which error do you have now?

[stephenjamieson]

I'm no longer seeing any code errors but the added device does not have the expected controls etc. It says it's using the Quirk: ts0601_siren_1.TuyaSirenGPP_NoSensors. Is there a guide to adding logs for a specific device?

[javicalle]

Is there a guide to adding logs for a specific device?

No, I believe it isn't. Have you checked the cluster attributes? Are there any values?

[stephenjamieson]

I see the following:

And it looks like this

Maybe I'm missing something but when I try to use the switch I get the following:

Failed to call service switch/turn_on. name 'TUYA_MCU_COMMAND' is not defined

[javicalle]

Are the volume, alarm_duration, melody and battery attributes reporting something?

Argggg! I forget another one. Please import TUYA_MCU_COMMAND from package zhaquirks.tuya.mcu.

[stephenjamieson]

Yes for all of the above attributes. Imported, however now I see this in the logs:

Mar 04 00:14:32 hass hass[917654]: 2022-03-04 00:14:32 WARNING (MainThread) [zigpy.zcl] [0x3422:1:0xef00] No cluster_dp found for 1, on_off
Mar 04 00:14:32 hass hass[917654]: 2022-03-04 00:14:32 WARNING (MainThread) [zigpy.zcl] [0x3422:1:0xef00] no MCU command for data TuyaClusterData(endpoint_id=1, cluster_attr='on_off', attr_value=1)

[javicalle]

I see where the the problem must be. If you want to try you can modify this part:

dp_to_attribute: Dict[int, DPToAttributeMapping] = {
        1: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "on_off",
            dp_type=TuyaDPType.BOOL,
        ),
        5: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "volume",
            dp_type=TuyaDPType.ENUM,
        ),
        7: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "alarm_duration",
            dp_type=TuyaDPType.VALUE,
        ),
        15: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "battery",
            dp_type=TuyaDPType.VALUE,
        ),
        21: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "melody",
            dp_type=TuyaDPType.ENUM,
        ),
    }

    data_point_handlers = {
        1: "_dp_2_attr_update",
        5: "_dp_2_attr_update",
        7: "_dp_2_attr_update",
        15: "_dp_2_attr_update",
        21: "_dp_2_attr_update",
    }

Time to rest for me. I'll continue tomorrow.

[stephenjamieson]

No problem, thank you for the help. Now the attributes are no longer reporting, but no error in the logs.

[jerrm]

Got home late, downloaded new file and made the listed changes.

I pair without apparent error, but still don't have any new entities for the device.

Let me know what I can do to help.

[javicalle]

Hi, I am going to try to explain how I think the device should work and what you can expect from the implementation.

The device have and OnOff cluster. This will be treated in HA as a switch. The switch should reflect the state of the alarm (active/not active) and should also be able to activate it by pressing the switch in HA. That should be the main objective.

But in addition, this alarm makes use of some datapoints (DPs) that allow to configure the alarm (and report the battery level). These DPs are mapped against attributes of the TuyaMCUSiren cluster. As of today, I believe that HA does not render any type of entity for these values and they can only be managed by reading and writing the attributes of the cluster. This is the way to configure the alarm from HA and is the secondary objective of the quirk.

This is the corrected version of the quirk. It has all the fixes reported by @stephenjamieson (sorry for that) and I've added a trace for when the switch is invoked from HA. ts0601_siren_1.py.txt

Enable debug log for:

logger:
  default: warning
  logs:
    .../...
    custom_zha_quirks: debug
    zigpy.zcl: debug

More info (and debug packages) in https://www.home-assistant.io/integrations/zha/#debug-logging

[jerrm]

Caught this while home for lunch.

The revised file still needs a couple of fixes to load:

--- ts0601_siren_1.py.txt   2022-03-04 13:35:50.000000000 -0500
+++ ts0601_siren_1.py   2022-03-04 14:47:56.558058360 -0500
@@ -34,7 +34,7 @@
     TuyaManufClusterAttributes,
     TuyaLocalCluster,
 )
-from zhaquirks.tuya.mcu import TuyaClusterData, DPToAttributeMapping, TuyaDPType, TuyaMCUCluster
+from zhaquirks.tuya.mcu import TuyaClusterData, DPToAttributeMapping, TuyaDPType, TuyaMCUCluster, TUYA_MCU_COMMAND

 TUYA_BATTERY_ATTR = 0x020F  # [0, 0, 0, 100] battery percentage
 TUYA_ALARM_ATTR = 0x0168  # [0]/[1] Alarm!
@@ -226,7 +226,7 @@
     }

     manufacturer_attributes = {
-        TUYA_BATTERY_ATTR: ("battery", t.uint32_t)
+        TUYA_BATTERY_ATTR: ("battery", t.uint32_t),
         TUYA_ALARM_ATTR: ("alarm", t.uint8_t),
         TUYA_TEMP_ALARM_ATTR: ("enable_temperature_alarm", t.uint8_t),
         TUYA_HUMID_ALARM_ATTR: ("enable_humidity_alarm", t.uint8_t),

After updating and re-pairing, I can set and get attributes, melody, duration, volume, etc under Manage Clusters, but the on_off switch doesn't seem to do anything.

Have to get back to the office right now. Will look closer later.

Thanks!

[javicalle]

Thanks to review. I must have confused the files when uploading it. I've corrected. My version includes (or should include) a debug trace.

[stephenjamieson]

Here's what I get when I use the on_off switch

2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0x0006] Sending Tuya Cluster Command. Cluster Command is 1, Arguments are ()
2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] tuya_mcu_command: cluster_data=TuyaClusterData(endpoint_id=1, cluster_attr='on_off', attr_value=1)
2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] get_dp_mapping --> found DP: 1
2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] from_cluster_data: 1, DPToAttributeMapping(ep_attribute='on_off', attribute_name='on_off', dp_type=<TuyaDPType.BOOL: 1>, converter=None, dp_converter=None, endpoint_id=None)
2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ztype: Bool.true
2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] from_value: [1, 1]
2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] raw: b'\x01'
2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] tuya_command: TuyaCommand(status=0, tsn=35, dp=1, data=TuyaData(dp_type=<TuyaDPType.BOOL: 1>, function=0, raw=b'\x01', *payload=<Bool.true: 1>))
2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=36 command_id=Command.Default_Response>
2022-03-04 21:11:36 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL request 0x000b: [0, <Status.UNSUP_MANUF_CLUSTER_COMMAND: 131>]

[javicalle]

Can you attach also the logs from setting a siren attribute (volume, alarm_duration, melody) Also traces from 'power on' the device (like in https://github.com/zigpy/zha-device-handlers/issues/1379#issuecomment-1048425763) can be helpfull.

Are the attribute changes updating the device? For example, after changin the volume attribute, the device updates the value?

[stephenjamieson]

Can you attach also the logs from setting a siren attribute (volume, alarm_duration, melody)

Are the attribute changes updating the device? For example, after changin the volume attribute, the device updates the value?

I can no longer GET or SET the attributes for some reason. No log entries either. see edit

2022-03-04 21:37:21 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=110 command_id=Command.Report_Attributes>
2022-03-04 21:37:21 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0x0000] ZCL request 0x000a: [[Attribute(attrid=1, value=<TypeValue type=uint8_t, value=68>), Attribute(attrid=65506, value=<TypeValue type=uint8_t, value=48>), Attribute(attrid=65508, value=<TypeValue type=uint8_t, value=1>)]]
2022-03-04 21:37:21 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0x0000] Attribute report received: app_version=68, 65506=48, 65508=1
2022-03-04 21:37:21 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=111 command_id=1>
2022-03-04 21:37:21 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL request 0x0001: [TuyaCommand(status=0, tsn=2, dp=5, data=TuyaData(dp_type=<TuyaDPType.ENUM: 4>, function=0, raw=b'\x02', *payload=<enum8.undefined_0x02: 2>))]
2022-03-04 21:37:21 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=112 command_id=1>
2022-03-04 21:37:21 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL request 0x0001: [TuyaCommand(status=0, tsn=3, dp=7, data=TuyaData(dp_type=<TuyaDPType.VALUE: 2>, function=0, raw=b'\n\x00\x00\x00', *payload=10))]
2022-03-04 21:37:22 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=113 command_id=1>
2022-03-04 21:37:22 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL request 0x0001: [TuyaCommand(status=0, tsn=4, dp=15, data=TuyaData(dp_type=<TuyaDPType.VALUE: 2>, function=0, raw=b'd\x00\x00\x00', *payload=100))]
2022-03-04 21:37:22 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=114 command_id=1>
2022-03-04 21:37:22 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL request 0x0001: [TuyaCommand(status=0, tsn=5, dp=21, data=TuyaData(dp_type=<TuyaDPType.ENUM: 4>, function=0, raw=b'\x05', *payload=<enum8.undefined_0x05: 5>))]
2022-03-04 21:37:22 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=115 command_id=17>
2022-03-04 21:37:22 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL request 0x0011: [MCUVersion(status=0, tsn=7, version_raw=66, *version='1.0.2')]
2022-03-04 21:37:22 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] MCU version: 1.0.2
2022-03-04 21:37:23 DEBUG (MainThread) [zigpy.zcl] [0xdf41:1:0x0b04] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=23 command_id=Command.Read_Attributes_rsp>
2022-03-04 21:37:32 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0x000a] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=116 command_id=Command.Read_Attributes>
2022-03-04 21:37:32 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0x000a] ZCL request 0x0000: [[7]]

edit: I reloaded the zigbee integration and I can get the attributes again.

GET Melody results in:

2022-03-04 21:43:20 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0x0006] Couldn't normalize 1126 attribute with None value
Traceback (most recent call last):
  File "/root/homeassistant/lib/python3.9/site-packages/zigpy/zcl/__init__.py", line 307, in read_attributes
    value = self.attributes[record.attrid][1](record.value.value)
  File "/root/homeassistant/lib/python3.9/site-packages/zigpy/types/basic.py", line 59, in __new__
    n = super().__new__(cls, *args, **kwargs)
ValueError: invalid literal for int() with base 10: 'None'

Set does nothing

GET Volume works and so does SET with no logs, is there another DEBUG I need to set? Getting the value again shows that it was changed as expected.

ALARM_DURATION works the same as Volume.

[javicalle]

All attribute values seems to function OK.

GET Melody results in:

Can you try to SET a melody value? I believe that 1-5 values are allowed. Perform a GET after setting to verify it works.

And for the switch, could you change the NeoSirenManufCluster with this one (just change the 1 keys for 13):

class NeoSirenManufCluster(TuyaMCUCluster):
    """Tuya with NEO Siren data points."""

    dp_to_attribute: Dict[int, DPToAttributeMapping] = {
        13: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "on_off",
            dp_type=TuyaDPType.BOOL,
        ),
        5: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "volume",
            dp_type=TuyaDPType.ENUM,
        ),
        7: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "alarm_duration",
            dp_type=TuyaDPType.VALUE,
        ),
        15: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "battery",
            dp_type=TuyaDPType.VALUE,
        ),
        21: DPToAttributeMapping(
            TuyaMCUSiren.ep_attribute,
            "melody",
            dp_type=TuyaDPType.ENUM,
        ),
    }

    data_point_handlers = {
        13: "_dp_2_attr_update",
        5: "_dp_2_attr_update",
        7: "_dp_2_attr_update",
        15: "_dp_2_attr_update",
        21: "_dp_2_attr_update",
    }

[stephenjamieson]

Can you try to SET a melody value? I believe that 1-5 values are allowed. Perform a GET after setting to verify it works.

Yep, it works after I set it

2022-03-04 22:31:17 DEBUG (MainThread) [zigpy.zcl] [0x6d04:1:0x0402] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=114 command_id=Command.Report_Attributes>
2022-03-04 22:31:17 DEBUG (MainThread) [zigpy.zcl] [0x6d04:1:0x0402] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=int16s, value=1970>)]]
2022-03-04 22:31:17 DEBUG (MainThread) [zigpy.zcl] [0x6d04:1:0x0402] Attribute report received: measured_value=1970
2022-03-04 22:31:23 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0x0006] Sending Tuya Cluster Command. Cluster Command is 1, Arguments are ()
2022-03-04 22:31:23 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] tuya_mcu_command: cluster_data=TuyaClusterData(endpoint_id=1, cluster_attr='on_off', attr_value=1)
2022-03-04 22:31:23 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] get_dp_mapping --> found DP: 13
2022-03-04 22:31:23 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] from_cluster_data: 13, DPToAttributeMapping(ep_attribute='on_off', attribute_name='on_off', dp_type=<TuyaDPType.BOOL: 1>, converter=None, dp_converter=None, endpoint_id=None)
2022-03-04 22:31:23 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ztype: Bool.true
2022-03-04 22:31:23 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] from_value: [1, 1]
2022-03-04 22:31:23 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] raw: b'\x01'
2022-03-04 22:31:23 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] tuya_command: TuyaCommand(status=0, tsn=47, dp=13, data=TuyaData(dp_type=<TuyaDPType.BOOL: 1>, function=0, raw=b'\x01', *payload=<Bool.true: 1>))
2022-03-04 22:31:23 DEBUG (MainThread) [zigpy.zcl] [0x3422:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=48 command_id=Command.Default_Response>

Nothing happening still when I use the on_off switch, logs above

[javicalle]

Can you confirm that no UNSUP_MANUF_CLUSTER_COMMAND traces now?

There is any way you can activate the siren and get the traces?

[stephenjamieson]

Yeah I do not see any UNSUP_MANUF_CLUSTER_COMMAND. AFAIK there's no way to trigger the alarm.

[javicalle]

If any z2m logs or info is helpful, I will gladly provide.

@jerrm I have no knowledge about z2m, but if you can provide traces from the working operation of the device I will take a look to see if something can be usefull. I am interested in the Zigbee message format.

[javicalle]

@stephenjamieson can you catch a trace (if there is some) when you update an attribute? I expect a trace with a tuya_mcu_command: ... message.

[jerrm]

@javicalle, will see what I can get from z2m.

Meanwhile, I was preparing logs from zha (attached). Included is the exact version of the quirk file in use. It should be your last version with the 1->13 edits.

neo.get_volume.log neo.join.log neo.on_from_device_page.log neo.powerup.log neo.set_alarm_duration_to_5.log neo.set_melody_to_2.log neo.set_volume_to_1.log ts0601_siren_1.py.log neo.get_alarm_duration.log neo.get_melody.log

[javicalle]

@jerrm Sorry, but these logs doesn't seem to be from the same device.

This tupla [0x4edd:1:0x0406] are [device:endpoint:cluster] values. The expected traces must be something like [0x3422:1:0xef00]. The device part can (and will) be diferent. But the endpoint:cluster will not, must be :1:0xef00 (for this device).

[javicalle]

Maybe more traces are needed. Can you enable also the zhaquirks.tuya.mcu: debug) level?

I am not sure why you don't get traces from attribute update. There must be something that I can't see.

Time to rest here. I will continue tomorrow.

[jerrm]

See if the attached z2m log helps at all: neo.z2m.set_alarm_true.log.

The log covers the time immediately before toggling the "alarm" boolean through the completion of the 5 second duration.

Will make zha debug log changes and post as well.

For reference, the device presents in z2m as:

And in HA as:

I was controlling directly from the z2m page.

Additional logs for other settings: neo.z2m.set_melody_to_6.log neo.z2m.set_volume_to_medium.log neo.z2m.set_duration_to_20.log

[jerrm]

@javicalle & @stephenjamieson:

I'm still not getting any zha logging for the device when setting/getting attributes from the "manage clusters" page. Even tried bumping the default level to debug as well.

Do you?

My current log settings:

logger:
  default: debug
  logs:
    homeassistant.core: debug
    homeassistant.components.zha: debug
    bellows.zigbee.application: debug
    bellows.ezsp: debug
    zigpy: debug
    zigpy_deconz.zigbee.application: debug
    zigpy_deconz.api: debug
    zigpy_xbee.zigbee.application: debug
    zigpy_xbee.api: debug
    zigpy_zigate: debug
    zigpy_znp: debug
    zhaquirks: debug
    custom_zha_quirks: debug
    zigpy.zcl: debug
    zhaquirks.tuya.mcu: debug

[javicalle]

I don't have any similar device to check. Are you in HA 2022.03?

The write_attributes method have a debug log: https://github.com/zigpy/zha-device-handlers/blob/83057c45b3e5f757fa2b05f3951ad51d584a551e/zhaquirks/tuya/mcu/__init__.py#L103-L111

If you get logs from tuya.mcu.__init__.py (the tuya_mcu_command: ... messages) you should also get logs from the write_attributes. 🤷🏻‍♂️

[javicalle]

Which zigbee controller/ZHA library are you using?

[javicalle]

My current log settings:

logger:
  default: debug
  logs:
    homeassistant.core: debug
    homeassistant.components.zha: debug
    bellows.zigbee.application: debug
    bellows.ezsp: debug
    zigpy: debug
    zigpy_deconz.zigbee.application: debug
    zigpy_deconz.api: debug
    zigpy_xbee.zigbee.application: debug
    zigpy_xbee.api: debug
    zigpy_zigate: debug
    zigpy_znp: debug
    zhaquirks: debug
    custom_zha_quirks: debug
    zigpy.zcl: debug
    zhaquirks.tuya.mcu: debug

Have you restarted HA?

If not, you can also modify the log level (without restar) from HA developer-tools --> service --> logger.set_level --> 'YAML mode':

service: logger.set_level
data: {
  homeassistant.core: debug
  homeassistant.components.zha: debug
  bellows.zigbee.application: debug
  bellows.ezsp: debug
  zigpy: debug
  zigpy_deconz.zigbee.application: debug
  zigpy_deconz.api: debug
  zigpy_xbee.zigbee.application: debug
  zigpy_xbee.api: debug
  zigpy_zigate: debug
  zigpy_znp: debug
  zhaquirks: debug
  custom_zha_quirks: debug
  zigpy.zcl: debug
  zhaquirks.tuya.mcu: debug
}

[jerrm]

Have you restarted HA?

Many times, I'm definitely getting the debug output when I have the settings enabled. They've been commented/uncommented in configuration.yaml multiple times now.

The service call option will be a big help.

Which zigbee controller/ZHA library are you using?

Stick is the Sonoff 3.0 Dongle Plus/CC2652 based - so znp correct?

If you get logs from tuya.mcu.init.py (the tuya_mcu_command: ... messages) you should also get logs from the write_attributes.

With tail -f home-assistant.log | grep tuya_mcu_command, toggling the on_off control from the UI gives me

2022-03-05 18:21:50 DEBUG (MainThread) [zigpy.zcl] [0x2a72:1:0xef00] tuya_mcu_command: cluster_data=TuyaClusterData(endpoint_id=1, cluster_attr='on_off', attr_value=0)

Setting attributes from the "Manage Clusters" page doesn't report anything.

Neither the control nor manage cluster page give anything with tail -f home-assistant.log | grep write_

[stephenjamieson]

Seeing the same behavior on my end, nothing logged for set or get on 2022.3.0

[javicalle]

Stick is the Sonoff 3.0 Dongle Plus/CC2652 based - so znp correct?

I think that will be bellows:

• https://www.home-assistant.io/integrations/zha/#known-working-zigbee-radio-modules

[javicalle]

So now there are 2 situations to fix:

1. make the switch work
2. understand why there are no traces when attributes are written

For point 2 I have a possible test:

• assign known values to some of the attributes (this should modify the values on the device)
• reboot the device (this will cause the device to publish its values of those same attributes)
• verify that the published values match those previously assigned

If they match, it means that we can really communicate with the device and interact with it. Then we can focus in why isn't working the switch part. If it doesn't match, surely HA is not able to communicate with the device and what we see is some kind of local cache in HA. This will address us to undestand why Z2M can talk to device but ZHA not.

[javicalle]

💡 Can you check that you don't have any local quirk (other than ts0601_siren_1.py) that could affect to this device. Any local tuya or tuya.mcu quirk maybe?

[javicalle]

I have compared the ZHA messages with those of Z2M and what I have found has been more or less what I expected:

• the payload of the messages on both platforms coincides:
• • ZHA:

    TuyaCommand(
    status=0,
    tsn=27, 
    dp=13, 
    data=TuyaData(
    dp_type=<TuyaDPType.BOOL: 1>,
    function=0,
    raw=b'\x01', 
    *payload=<Bool.true: 1>
    )
    )

• • Z2M:

    manuSpecificTuya.dataRequest(
    {
    "seq":7,
    "dpValues":[
    {"dp":13,"datatype":1,"data":[1]}
    ]
    }, 
    .../...
    )

    (tsn & seq are not relevant here)

I'm curious about the headers attributes (the manufacturer ones), but as we don't get logs in HA from this part I can't compare.

[stephenjamieson]

Hello,

Can you check that you don't have any local quirk (other than ts0601_siren_1.py) that could affect to this device. Any local tuya or tuya.mcu quirk maybe?

As far as I know there are no other quirks, at least not in the custom directory. There's in fact only this one in the issue. Wondering if there's a debug issue since even enabling debug for all logs shows nothing.