[Device Support Request] Develco Frient SMSZB-120 Intelligent Smoke Alarm

[Veldkornet]

Is your feature request related to a problem? Please describe. I am able to pair the device, the temperature sensor works, but the battery sensor does not. Unclear on the binary_sensor. Upon investigation, found errors in logs.

Describe the solution you'd like Add quirks for the Frient devices as needed. There is apparently ZigBee2MQTT support.

Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.

{
  "node_descriptor": "NodeDescriptor(byte1=2, byte2=64, mac_capability_flags=0, manufacturer_code=4117, maximum_buffer_size=80, maximum_incoming_transfer_size=80, server_mask=0, maximum_outgoing_transfer_size=80, descriptor_capability_field=0, *allocate_address=False, *complex_descriptor_available=False, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False, *is_valid=True, *logical_type=<LogicalType.EndDevice: 2>, *user_descriptor_available=False)",
  "endpoints": {
    "1": {
      "profile_id": 49353,
      "device_type": "0x0001",
      "in_clusters": [
        "0x0003",
        "0x0005",
        "0x0006"
      ],
      "out_clusters": []
    },
    "35": {
      "profile_id": 260,
      "device_type": "0x0402",
      "in_clusters": [
        "0x0000",
        "0x0001",
        "0x0003",
        "0x000f",
        "0x0020",
        "0x0500",
        "0x0502"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "38": {
      "profile_id": 260,
      "device_type": "0x0302",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0402"
      ],
      "out_clusters": [
        "0x0003"
      ]
    }
  },
  "manufacturer": "frient A/S",
  "model": "SMSZB-120",
  "class": "zigpy.device.Device"
}

Additional context ZHA Issue: https://github.com/home-assistant/core/issues/49127 Zigbee-Herdsman Converter: https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/devices/develco.js

2021-04-16 17:43:50 DEBUG (MainThread) [zigpy.zcl] [0x17e8:35:0x0500] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=61 command_id=0>
2021-04-16 17:43:50 DEBUG (MainThread) [zigpy.zcl] [0x17e8:35:0x0500] ZCL request 0x0000: [<ZoneStatus.Restore_reports|Supervision_reports: 48>, <bitmap8.0: 0>, 0, 65535]
2021-04-16 17:43:50 DEBUG (MainThread) [zigpy.zcl] [0x17e8:35:0x0500] No handler for cluster command 0
...
2021-04-16 17:48:50 DEBUG (MainThread) [zigpy.zcl] [0x17e8:35:0x0500] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=62 command_id=0>
2021-04-16 17:48:50 DEBUG (MainThread) [zigpy.zcl] [0x17e8:35:0x0500] ZCL request 0x0000: [<ZoneStatus.Restore_reports|Supervision_reports: 48>, <bitmap8.0: 0>, 0, 65535]
2021-04-16 17:48:50 DEBUG (MainThread) [zigpy.zcl] [0x17e8:35:0x0500] No handler for cluster command 0

[Martinnygaard]

I am very much interested in this one as well - I have 7 of these I want to connect. I see the exact same behavior as in the issue: #49127

If I can do anything to help, please let me know!

[BusinessClaes]

I am also very interested in this device and its sibiling the Develco/Frient Heat detector HESZB-120. They have the funcionality of being used as Warning Device (cluster 0x0502), which is quite unique among all the other zigbee smoke detectors. Sending the right message you can get all the detectors to sound at once, either when fire is detected by one of them, or for burglar alarm purpouses.

Develco publish at their site the technical documentation for the SMSZB-120 and the HESZB-120. With this and the information at the zigbee2mqqt site I have been able to send zha.issue_zigbee_cluster_command to cluster 0x0502 and start/stop the warning at the devices.

Start command (3 seconds warning, 2nd arg) { "ieee":"xx:xx:xx:xx:xx:xx:xx:xx", "endpoint_id":35, "cluster_id":1282, "cluster_type":"in", "command":0, "command_type":"server", "args":[1,3,0,0] }

Stop command { "ieee":"xx:xx:xx:xx:xx:xx:xx:xx", "endpoint_id":35, "cluster_id":1282, "cluster_type":"in", "command":0, "command_type":"server", "args":[0,0,0,0] }

Putting the Sonoff ZbBridge at module 75 gives me following mqtt messages. The 0500<00 messages come quite often, I guess it is the "everything OK, no fire" message. If this helps in any way I can try to fetch other messages like "fire detected" or "test button pressed". Just tell me if you need that.

{"ZbReceived":{{"Device":"0x2895","Manufacturer":"frient A/S","ModelId":"SMSZB-120","Endpoint":38,"LinkQuality":58}}}
{"ZbReceived":{{"Device":"0x2895","0019!01":"001510510219040300","Endpoint":35,"LinkQuality":58}}}
{"ZbReceived":{{"Device":"0x2895","0020<00":"","Endpoint":35,"LinkQuality":10}}}
{"ZbReceived":{{"Device":"0x2895","0500<00":"30000000FFFF","ZoneStatusChange":48,"Endpoint":35,"LinkQuality":21}}}
{"ZbReceived":{{"Device":"0x2895","0500<00":"300000","ZoneStatusChange":48,"Endpoint":35,"LinkQuality":26}}}
{"ZbReceived":{{"Device":"0x2895","BatteryVoltage":3.1,"0001/003E":0,"BatteryPercentage":100,"Endpoint":35,"LinkQuality":18}}}
{"ZbReceived":{{"Device":"0x2895","Temperature":20.37,"Endpoint":38,"LinkQuality":29}}}

{"ZbReceived":{{"Device":"0xEA9E","Manufacturer":"frient A/S","ModelId":"HESZB-120","Endpoint":38,"LinkQuality":68}}}
{"ZbReceived":{{"Device":"0xEA9E","0019!01":"001510510219040300","Endpoint":35,"LinkQuality":73}}}
{"ZbReceived":{{"Device":"0xEA9E","0020<00":"","Endpoint":35,"LinkQuality":31}}}
{"ZbReceived":{{"Device":"0xEA9E","0500<00":"30010000FFFF","ZoneStatusChange":304,"Endpoint":35,"LinkQuality":29}}}
{"ZbReceived":{{"Device":"0xEA9E","0500<00":"300100","ZoneStatusChange":304,"Endpoint":35,"LinkQuality":26}}}
{"ZbReceived":{{"Device":"0xEA9E","BatteryVoltage":3.1,"0001/003E":0,"BatteryPercentage":100,"Endpoint":35,"LinkQuality":31}}}
{"ZbReceived":{{"Device":"0xEA9E","Temperature":20.56,"Endpoint":38,"LinkQuality":29}}}

[Martinnygaard]

They have the funcionality of being used as Warning Device (cluster 0x0502), which is quite unique among all the other zigbee smoke detectors

@BusinessClaes, And this is a great feature, eliminating the need for HA to bind everything together in software. Defenetly a must for me, not having safety in my house relying on HA to properly work.

With this and the information at the zigbee2mqqt site I have been able to send zha.issue_zigbee_cluster_command to cluster 0x0502 and start/stop the warning at the devices.

Start command (3 seconds warning, 2nd arg) { "ieee":"xx:xx:xx:xx:xx:xx:xx:xx", "endpoint_id":35, "cluster_id":1282, "cluster_type":"in", "command":0, "command_type":"server", "args":[1,3,0,0] }

Stop command { "ieee":"xx:xx:xx:xx:xx:xx:xx:xx", "endpoint_id":35, "cluster_id":1282, "cluster_type":"in", "command":0, "command_type":"server", "args":[0,0,0,0] }

Out of curiosity, where do you send these commands from ZHA?

Putting the Sonoff ZbBridge at module 75 gives me following mqtt messages. The 0500<00 messages come quite often, I guess it is the "everything OK, no fire" message. If this helps in any way I can try to fetch other messages like "fire detected" or "test button pressed". Just tell me if you need that.

Also for curiosity, what does it mean that you put the Sonoff ZbBridge at module 75? I have flashed my SonoffZBBridge with Tasmota and connected to ZHA.

[BusinessClaes]

Out of curiosity, where do you send these commands from ZHA?

I send them from Node-RED with a call service node (triggered by an inject node) Domain: zha Service: issue_zigbee_cluster_command Data:

{
   "ieee":"your:device:ieee",
   "endpoint_id":35,
   "cluster_id":1282,
   "cluster_type":"in",
   "command":0,
   "command_type":"server",
   "args":[1,3,0,0]
}

Also for curiosity, what does it mean that you put the Sonoff ZbBridge at module 75? I have flashed my SonoffZBBridge with Tasmota and connected to ZHA.

After flashing the ZbBridge with Tasmota you made a couple of configurations at the tasmotas console in the bridge. One of the commands was module 0, which puts the bridge in kind of "pass through" mode, giving to ZHA direct control of the zigbee radio. The default after flashing the bridge is module 75 which activates Tasmotas own Zigbee2Tasmota (Z2T). With this default configuration, the zigbee traffic is monitored and controlled directly from Tasmota, without sending it to ZHA.

Tasmota sends then mqtt messages to your broker to inform about what is happening in the zigbee network. Then you can if you want (as I did) listen to these mqtt messages in Node-RED, log them to a file and analize them later.

With module 75 you can send messages to the zigbee network directly from the Tasmotas console. The command ZbSend {"Device":"0x2895","endpoint":35,"Send":"0502!00/010300"} has the same result as zha.issue_zigbee_cluster_command with module 0 (triggers the sound in the smoke detector for 3 seconds). You can swap back and forth between module 75 and module 0 without breaking anything. Just remember to swap back to module 0 if you want your zigbee lights to work with HA :)

[Martinnygaard]

Hi,

I would really like this to work properly with zHA. Can anyone help me in creating the Quirk? Or guide me to getting started.

i have read the "readme" of the Zigpy repo, and looked at previously qirks - but it still a bit confusing haw exactly I need to handle the task..

[Hedda]

Wondering if the root cause is the same as that described by dmulcahey in https://github.com/zigpy/zha-device-handlers/issues/605 issue? That is, a a limitation in ZHA integration for Home Assistant which currently only support 1 sensor per cluster, and these type of devices requiring 2 or more sensor per cluster?

[Stefano0042]

@Adminiuga hello Alexei, I know you are working like an hell on other ZHA task, when you have some time on your side, could you take a look at this request, this smoke sensor is really promising, it exposes:

• Temperature: measured temperature value
• Battery: remaining battery in %
• Smoke: indicates whether the device detected smoke
• Battery_low: indicates if the battery of this device is almost empty
• Test: indicates whether the device is being tested
• Max_duration: duration of siren
• Alarm: manual start of siren
• Linkquality: link quality (signal strength)

[Martinnygaard]

@Adminiuga hello Alexei, I know you are working like an hell on other ZHA task, when you have some time on your side, could you take a look at this request, this smoke sensor is really promising, it exposes:

• Temperature: measured temperature value
• Battery: remaining battery in %
• Smoke: indicates whether the device detected smoke
• Battery_low: indicates if the battery of this device is almost empty
• Test: indicates whether the device is being tested
• Max_duration: duration of siren
• Alarm: manual start of siren
• Linkquality: link quality (signal strength)

I really second that! To be, the best feature of them is the IAS alarm, which should let them talk together directly.

I bought 8 of these smoke alarms, because they looked so promising - and I got into ZHA because of them.

• but was sad to see they didn't work.

  I hope someone will help bringing this up to a working order - and I will do what I can do to help!

[Ulrar]

I just got one of these, and here's what I'm seeing :

• on_off cluster, turning it on does nothing and it resets itself to off after a few seconds, as if the set timed out.
• binary_input, seems to be off normally and turn on when doing a long press on the physical test button.
• IAS Zone sensor, always clear. I haven't tried putting the alarm next to a real fire yet, so it might be working as expected, will have to test it. I've never seen of these, as I understand it that would be the actual smoke detector ?
• Battery, showing unknown but it may not have had time to update yet, I just paired it less than an hour ago.

Using zha.issue_zigbee_cluster_command as suggested above I can make it ring once, which is neat. It stops itself though which is unfortunate for an alarm. I would expect the on_off cluster to control the burglar alarm mode, but it doesn't seem to.

My guess now is I should create an automation to notify me on either binary_input or ias_zone turning on, since that would indicate a fire. Does that sound right ?

[TexTown]

My device paired months ago, still no battery level.. When you check the HA logs, you'll probably see errors similar to this one:

Logger: zigpy.device
Source: /usr/local/lib/python3.9/site-packages/zigpy/device.py:320
First occurred: 11:58:51 (198 occurrences)
Last logged: 20:19:34

Failed to parse message (b'190100300000') on cluster 1280, because Data is too short to contain 1 bytes
Failed to parse message (b'19da00300000') on cluster 1280, because Data is too short to contain 1 bytes
Failed to parse message (b'190300300000') on cluster 1280, because Data is too short to contain 1 bytes
Failed to parse message (b'19db00300000') on cluster 1280, because Data is too short to contain 1 bytes
Failed to parse message (b'190500300000') on cluster 1280, because Data is too short to contain 1 bytes

It is however detecting smoke and working as expected in that area. I have an automation working that sends notifications when smoke is detected. Here's the yaml config of that automation

alias: Smoke Detected
description: ''
trigger:
  - type: smoke
    platform: device
    device_id: 8c6be332d5c951f878427e4d6d71b5a8
    entity_id: binary_sensor.frient_a_s_smszb_120_e8960031_ias_zone
    domain: binary_sensor
  - type: smoke
    platform: device
    device_id: 3a9f8d856ca7e2f272xxxxxxxxxxxxxxx
    entity_id: binary_sensor.frient_a_s_smszb_120_50990031_ias_zone
    domain: binary_sensor
condition: []
action:
  - service: notify.mobile_app_deviceXXX
    data:
      message: SMOKE !!!
      title: Smokedetector
mode: single

[Ulrar]

Interesting. I don't see these errors on mine, but maybe that'll come later, I'll keep an eye on it.

I see you are using the ias_zone one in your automation, I'll do the same, thanks!

[Teryeahh]

I would really like these to work too. have 5 of them. The temperature seems to work, and they do report smoke detected. But No battery state. and no way to program them together ot trigger them, the switch entity doesnt do anything. I know they work with deconz, and zigbee2mqtt. But I'll rather stay with ZHA. At least for now..

Anyone got it working? I tried to read up on how to make a quirk.. doesnt seem too easy..

[Adminiuga]

you should request OTA update file, because the firmware from 20210625 00:54 sends correctly formatted ZoneStatus updates

2021-11-18 20:16:11 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=1280, sourceEndpoint=35, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=153), 128, -68, 0x443e, 255, 255, b'\x19\x11\x000\x00\x00\x00\xf0\t']
2021-11-18 20:16:11 DEBUG (MainThread) [zigpy.zcl] [0x443e:35:0x0500] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=17 command_id=0>
2021-11-18 20:16:11 DEBUG (MainThread) [zigpy.zcl] [0x443e:35:0x0500] ZCL request 0x0000: [<ZoneStatus.Restore_reports|Supervision_reports: 48>, <bitmap8.0: 0>, 0, 2544]
2021-11-18 20:16:11 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0x443E:35:0x0500]: Updated alarm state: ZoneStatus.0

Device Signature

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.NONE: 0>, manufacturer_code=4117, maximum_buffer_size=80, maximum_incoming_transfer_size=80, server_mask=10752, maximum_outgoing_transfer_size=80, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=False, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=False, *is_receiver_on_when_idle=False, *is_router=False, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 49353,
      "device_type": "0x0001",
      "in_clusters": [
        "0x0003",
        "0x0005",
        "0x0006"
      ],
      "out_clusters": []
    },
    "35": {
      "profile_id": 260,
      "device_type": "0x0402",
      "in_clusters": [
        "0x0000",
        "0x0001",
        "0x0003",
        "0x000f",
        "0x0020",
        "0x0500",
        "0x0502"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "38": {
      "profile_id": 260,
      "device_type": "0x0302",
      "in_clusters": [
        "0x0000",
        "0x0003",
        "0x0402"
      ],
      "out_clusters": [
        "0x0003"
      ]
    }
  },
  "manufacturer": "frient A/S",
  "model": "SMSZB-120",
  "class": "zigpy.device.Device"
}

[Adminiuga]

@TexTown can you read the date code of the basic cluster of your device? And post device signature?

[Martinnygaard]

you should request OTA update file, because the firmware from 20210625 00:54 sends correctly formatted ZoneStatus updates !

How do I get it to OTA update? I mean, can it force the Sonoff ZB bridge (Flashed) to go online and pull it?

@TexTown can you read the date code of the basic cluster of your device? And post device signature?

I can see that my sensors has the following version/date_codes: Current_file_version = 197657 date_code = 2020-08-31 00:49

[MattWestb]

Can that they have posing updated firmware in there support forum but its need one account for looking in. Also possible making one support ticket that can resulting getting one firmware from the manufacture but no grantee then its there property.

[MartinNygaardSchacht]

Can that they have posing updated firmware in there support forum but its need one account for looking in. Also possible making one support ticket that can resulting getting one firmware from the manufacture but no grantee then its there property.

I cant find a forum, but I asked on their facebook page.

[Veldkornet]

Zigbee2mqtt has v4.0.2 here. As far as I know, this is the latest.

[MattWestb]

Try configuring local OTA as https://github.com/zigpy/zigpy/wiki/OTA-Device-Firmware-Updates#enabling-ota-updates but dont adding IKEA or ledvance if you dont have those device only the otau_directory: /config/zigpy_ota and copy the downloaded file to the new directory and restart HA. Some devices is asking for OTA other need being asked and other need little help for triggering the update. Repower the device is normally working for most devices.

[Stefano0042]

2021-11-19 10:28:22 DEBUG (SyncWorker_7) [zigpy.ota.provider] ImageKey(manufacturer_id=4117, image_type=593): /home/homeassistant/.homeassistant/ota/ED_Smoke_Sensor_SSIG_4.0.2.zigbee, version: 262146, hw_ver: (None, None), OTA string:

The above is from the HA LOG file, the file has been recognized, I tried to accelerate the update by forwarding a cluster command image_notify (id: 0x0000) to the device, but by now there is not any new activity in the LOG....

[MattWestb]

You must putting up the debug longing for see the OTA by zigpy.ota: debug or by service in HA.

One sort cut to see the log is open the network for joining device and clicking show log and you can see the progress :-))

[Stefano0042]

@MattWestb DEBUG is already active for zigpy.ota, it could be that my version is already 4.0.2 my date_code is (id: 0x0006): 20210624 13:34,. Primary SW version is a Develco specific ostring, can't be acquired..

[MattWestb]

Sorry i was wrong you need having debug forzigpy.zcl. I was looking in my test system for then one IKEA E1743 was being quered:

2021-11-18 17:24:11 DEBUG (MainThread) [zigpy.zcl] [0xc1d9:1:0x0019] OTA query_next_image handler for 'IKEA of Sweden TRADFRI on/off switch': field_control=1, manufacture_id=4476, image_type=4549, current_file_version=587699761, hardware_version=1
2021-11-18 17:24:11 DEBUG (MainThread) [zigpy.zcl] [0xc1d9:1:0x0019] No OTA image is available

[Stefano0042]

the picture is related to a temporary pairing with deconz.

[MattWestb]

If you is having it pared with deCONZ you can trying doing the update with it and you can also see the version the device is requesting in the OTA GUI.

Very goode implementation of the attribute they have making but i dont think its Chinese writing in the attribute and not some Scandinavian then i have understanding it ;-))

If the device is doing one normal OTA request you is getting the version as current_file_version=587699761 in (Z)HA log and you can comparing it with the firmware loaded then starting HA.

[Stefano0042]

@MattWestb thank you for deCONZ advice, I was not aware of the OTAU plugin, the result, as expected, is that Files version and Version are matching 0x00040002.

[Adminiuga]

You do appear to have the latest version. I was referring to a TexTown who was getting this error

Failed to parse message (b'190100300000') on cluster 1280, because Data is too short to contain 1 bytes 

@Martinnygaard you could update yours

[Teryeahh]

I'm trying to run the fw-update. I have downloaded the file from here: https://github.com/Koenkk/zigbee-OTA/tree/master/images/Develco and put it in the config\zigpy_ota folder. added this to configuration.yaml: zha: zigpy_config: ota: otau_directory: /config/zigpy_ota

Running this with developer tools:

service: zha.issue_zigbee_cluster_command data: ieee: 00:15:bc:00:31:00:49:e1 endpoint_id: 35 cluster_id: 0x0019 cluster_type: out command: 0 command_type: client args:

• 0
• 100

Getting this error:

Logger: zigpy.device Source: /usr/local/lib/python3.9/site-packages/zigpy/device.py:320 First occurred: 00:51:50 (2 occurrences) Last logged: 00:53:37

Failed to parse message (b'194900300000') on cluster 1280, because Data is too short to contain 1 bytes Failed to parse message (b'198b00300000') on cluster 1280, because Data is too short to contain 1 bytes

What am I doing wrong?

[Teryeahh]

This is the signature of one of my detectors: { "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.NONE: 0>, manufacturer_code=4117, maximum_buffer_size=80, maximum_incoming_transfer_size=80, server_mask=0, maximum_outgoing_transfer_size=80, descriptor_capability_field=<DescriptorCapability.NONE: 0>, allocate_address=False, is_alternate_pan_coordinator=False, is_coordinator=False, is_end_device=True, is_full_function_device=False, is_mains_powered=False, is_receiver_on_when_idle=False, is_router=False, *is_security_capable=False)", "endpoints": { "1": { "profile_id": 49353, "device_type": "0x0001", "in_clusters": [ "0x0003", "0x0005", "0x0006" ], "out_clusters": [] }, "35": { "profile_id": 260, "device_type": "0x0402", "in_clusters": [ "0x0000", "0x0001", "0x0003", "0x000f", "0x0020", "0x0500", "0x0502" ], "out_clusters": [ "0x000a", "0x0019" ] }, "38": { "profile_id": 260, "device_type": "0x0302", "in_clusters": [ "0x0000", "0x0003", "0x0402" ], "out_clusters": [ "0x0003" ] } }, "manufacturer": "Develco Products A/S", "model": "SMSZB-120", "class": "zigpy.device.Device" }

[TexTown]

@TexTown can you read the date code of the basic cluster of your device? And post device signature?

Below is the device signatue. Can you explain how I can obtain the date code you need?

{ "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.NONE: 0>, manufacturer_code=4117, maximum_buffer_size=80, maximum_incoming_transfer_size=80, server_mask=0, maximum_outgoing_transfer_size=80, descriptor_capability_field=<DescriptorCapability.NONE: 0>, allocate_address=False, is_alternate_pan_coordinator=False, is_coordinator=False, is_end_device=True, is_full_function_device=False, is_mains_powered=False, is_receiver_on_when_idle=False, is_router=False, *is_security_capable=False)", "endpoints": { "1": { "profile_id": 49353, "device_type": "0x0001", "in_clusters": [ "0x0003", "0x0005", "0x0006" ], "out_clusters": [] }, "35": { "profile_id": 260, "device_type": "0x0402", "in_clusters": [ "0x0000", "0x0001", "0x0003", "0x000f", "0x0020", "0x0500", "0x0502" ], "out_clusters": [ "0x000a", "0x0019" ] }, "38": { "profile_id": 260, "device_type": "0x0302", "in_clusters": [ "0x0000", "0x0003", "0x0402" ], "out_clusters": [ "0x0003" ] } }, "manufacturer": "frient A/S", "model": "SMSZB-120", "class": "zigpy.device.Device" }

[Teryeahh]

That's my date code

[TexTown]

I have 2 devices, both have the same date code:

[Ulrar]

Hey,

Updated to 2021.12 yesterday and this PR seems to be in it. After reconfiguring the device the battery now shows up correctly, thanks for the work !

The on_off switch still does nothing, is that quirk supposed to handle it ? Would be nice if it could be used to trigger / stop the alarm, instead of having to use the zha service call with manual payloads.

Thanks again for the battery !

[TexTown]

I have two of these devices, and was able to get one showing the battery status by 'reconfuring' the device is ZHA. The attempt to reconfigure the second device (and any other device after this first success) fails.... Can't get the seconds device to show a correct battery status

[ark-]

These devices are still not fully working in ZHA in home assistant, see https://github.com/home-assistant/core/issues/49127#issuecomment-1254309187

The temperature seems to be stuck at the value when the device was first paired.

[tobixen]

The temperature seems to be stuck at the value when the device was first paired.

I have the same problem.

I have five of those devices ... best firealarm ever, if just everything would work as it should ...

EDIT: According to https://github.com/home-assistant/core/issues/49127 it's needed to do a firmware upgrade

[Martinnygaard]

The temperature seems to be stuck at the value when the device was first paired.

I have the same problem.

I have five of those devices ... best firealarm ever, if just everything would work as it should ...

EDIT: According to home-assistant/core#49127 it's needed to do a firmware upgrade

The ones I have connected to ZHA reports temp just fine. I have FW version 0x00030419 installed.

[tobixen]

Oh darn. I also have FW version 0x00030419, and my fire alarms shows a flat line.

[tobixen]

Still a flat line after firmware upgrade ... and after upgrading the firmware, I'm not able to utilize the siren anymore.

[Veldkornet]

Still a flat line after firmware upgrade ... and after upgrading the firmware, I'm not able to utilize the siren anymore.

This happened in Z2M as well (the siren part). Needed a fix in Z2M --> https://github.com/Koenkk/zigbee2mqtt/issues/15795

[Martinnygaard]

Still a flat line after firmware upgrade ... and after upgrading the firmware, I'm not able to utilize the siren anymore.

This happened in Z2M as well (the siren part). Needed a fix in Z2M --> Koenkk/zigbee2mqtt#15795

I also have 5 pcs on Z2M, all upgraded to FW verison 4.0.5, and they also works perfectly. It is really strange, that you guys are having those issues, and im not.

[tobixen]

I also have 5 pcs on Z2M, all upgraded to FW verison 4.0.5, and they also works perfectly. It is really strange, that you guys are having those issues, and im not.

I'm on ZHA, and Z2M got a workaround to fix siren issues in 4.0.5. Perhaps I should consider Z2M.

The zigbee router hardware can also affect things, sonoff vs conbee.

[Commifreak]

Same here. frient with FW x00040008. HA 2023.11.3 hangs at Configuring. Coordinator: Sonoff ZNP = Texas Instruments Z-Stack ZNP protocol: CC253x, CC26x2, CC13x2

A reconfiguration fails as well:

:/

[Isengo1989]

Experience the same here last night, was there a fix for that?