Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot turn off siren - Frient Intelligent smoke alarm (SMSZB-120) #8040

Open
2 tasks done
SvenNilsson opened this issue Nov 24, 2024 · 1 comment
Open
2 tasks done

Comments

@SvenNilsson
Copy link

SvenNilsson commented Nov 24, 2024

Does the issue really belong here?

  • I definitively want to report a bug within deCONZ or its REST-API

Is there already an existing issue for this?

  • I have searched the existing issues and there is none for the bug at hand

Describe the bug

The Frient Intelligent smoke alarm should support setting 3 states via the rest apis on the "warning device" endpoint:

select and lselect would turn on the siren and none should turn it off.

sending select and none does nothing. (sending lselect, turn on siren which has to be manually reset/turned off by pressing the button on the smoke alarm (front))

Steps to reproduce the behavior

use put command on endpoint:
https://ip-address-to-rest-plugin/api//lights//state

first with body: { "alert": "select" }, siren does not go off

then with body: { "alert": "lselect" } siren goes off

then with body { "alert": "none" } siren does not stop

Expected behavior

{ "alert": "none" } stops the siren
{ "alert": "select" } start the siren

Screenshots

image

Environment

  • Host system: Synology NASwith docker
  • Running method: docker: deconzcommunity/deconz:latest
  • Firmware version: 26780700
  • deCONZ version (not Home assistant Addon version!): 2.29.0 and 2.28.1
  • Device: ConBee II
  • Do you use an USB extension cable: no
  • Is there any other USB or serial devices connected to the host system? no
    -Frient smoke alarm has firmware 4.0.8 (latest from what I could tell)

deCONZ Logs

No response

Additional context

From what I could see reading the code the DDF have been changed lately (August 8) and actually tested with my device... So it could have something to do with this part of the DDF, if this issue didn't exist before:

{
"name": "attr/uniqueid"
},
{
"name": "state/alert",
"description": "Start warning command payload has 5 Bytes. Byte 1: Options. 0x17 = Warning mode 1 (burglar), Strobe, Very high sound. Byte 2-3: Duration, Byte 4: Strobe duty cycle, Byte 5: Strobe level",
"read": {
"fn": "none"
},
"write": {
"cl": "0x0502",
"cmd": "0x00",
"ep": "0x01",
"eval": "if (Item.val=='select') { '1701000000' } else if (Item.val=='none') { '0000000000' }",
"fn": "zcl:cmd"
},
"default": "none"
},
{
"name": "state/reachable"
}
]

image

@SvenNilsson
Copy link
Author

For anybody reading this and have the same issues, using the previous ddf file solved the issue for me. Seems like this line introduces the bug: "eval": "if (Item.val=='select') { '1701000000' } else if (Item.val=='none') { '0000000000' }",

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant