How to trigger smoke detector alarm

fabian91 · January 8, 2025, 9:37pm

I am using openHAB with Phoscon and want to trigger the alarm for a smoke detector.
The smoke detector has cluster 502.
When I trigger the alarm for one second through the deCONZ GUI, the alarm goes off immediately and stops after one second. Perfect.
When I search for the smoke detector via Phoscon and integrate it into openHAB, an alarm channel is created, where I can select “none,” “select,” and “lselect.”
Unfortunately, triggering the alarm this way doesn’t work – when I switch multiple times between select and lselect, the alarm eventually goes off, but this seems random.

I have saved the DDF, which is visible in the deCONZ preview, as a JSON file under /home/user/.local/share/deCONZ/devices. Changes to the file also take effect.
I have logged the command from the deCONZ GUI; what should I do with it now?

{
“type”: “$TYPE_WARNING_DEVICE”,
“restapi”: “/lights”,
“uuid”: [
“$address.ext”,
“0x23”
],
“items”: [
{
“name”: “attr/id”
},
{
“name”: “attr/lastannounced”
},
{
“name”: “attr/lastseen”
},
{
“name”: “attr/manufacturername”
},
{
“name”: “attr/modelid”
},
{
“name”: “attr/name”
},
{
“name”: “attr/swversion”
},
{
“name”: “attr/type”
},
{
“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’) { ‘01FF001001000000’ } else { ‘0000000000000000’ }”,
“fn”: “zcl:cmd”
},
“default”: “none”
},
{
“name”: “state/reachable”
}
]
}

does not work. I can switch multiple times between “none” and “select”. Nothing happens. If i choose “lselect” (like before), it goes off.

If I trigger it, it sends:

APS-DATA.request id: 19, addrmode: 0x03, addr: 0x0015BC00310269B4, profile: 0x0104, cluster: 0x0502, ep: 0x01 → 0x01 queue: 0 len: 8 tx.options 0x00
21:23:40:814 asdu (length: 8): 110B001701000000

This is NOT the payload I have declared…

How can I address this issue?

OMR · January 9, 2025, 12:42am

The Zigbee alarm or rather alert channel is usually found for lights, and select and lselect makes the light blink 3 or 8 times respectively before ending up in it most current state.
I think after it is done blinking, it reverts back to none automatically.

I use this for an event feedback on a light:

String EntryAlarm { channel = "deconz:colortemperaturelight:homeserver:000b57fffe29e5ce01:alert" }

EntryAlarm.sendCommand("select")

How do the Endpoints and Clusters look like for your device?
And the DDF you are using?

Seems like openHab is confusing your alarm channel with this?

fabian91 · January 9, 2025, 5:44am

This is what the DDF-Preview in deCONZ-Gui looks like:

{
“schema”: “devcap1.schema.json”,
“manufacturername”: “frient A/S”,
“modelid”: “SMSZB-120”,
“vendor”: “Frient”,
“product”: “Intelligent smoke alarm (SMSZB-120)”,
“sleeper”: false,
“status”: “Gold”,
“path”: “/devices/frient/smszb-120_smoke_detector.json”,
“subdevices”: [
{
“type”: “$TYPE_FIRE_SENSOR”,
“restapi”: “/sensors”,
“uuid”: [
“$address.ext”,
“0x23”,
“0x0500”
],
“fingerprint”: {
“profile”: “0x0104”,
“device”: “0x0402”,
“endpoint”: “0x23”,
“in”: [
“0x0000”,
“0x0001”,
“0x0500”
]
},
“items”: [
{
“name”: “attr/id”
},
{
“name”: “attr/lastannounced”
},
{
“name”: “attr/lastseen”
},
{
“name”: “attr/manufacturername”
},
{
“name”: “attr/modelid”
},
{
“name”: “attr/name”
},
{
“name”: “attr/swversion”
},
{
“name”: “attr/type”
},
{
“name”: “attr/uniqueid”
},
{
“name”: “config/battery”,
“parse”: {
“at”: “0x0020”,
“cl”: “0x0001”,
“ep”: 35,
“script”: “develco_battery.js”
},
“default”: 0
},
{
“name”: “config/enrolled”,
“public”: false
},
{
“name”: “config/on”
},
{
“name”: “config/pending”
},
{
“name”: “config/reachable”
},
{
“name”: “state/fire”
},
{
“name”: “state/lastupdated”
},
{
“name”: “state/lowbattery”
},
{
“name”: “state/test”,
“default”: false
}
]
},
{
“type”: “$TYPE_TEMPERATURE_SENSOR”,
“restapi”: “/sensors”,
“uuid”: [
“$address.ext”,
“0x26”,
“0x0402”
],
“fingerprint”: {
“profile”: “0x0104”,
“device”: “0x0302”,
“endpoint”: “0x26”,
“in”: [
“0x0000”,
“0x0001”,
“0x0402”
]
},
“items”: [
{
“name”: “attr/id”
},
{
“name”: “attr/lastannounced”
},
{
“name”: “attr/lastseen”
},
{
“name”: “attr/manufacturername”
},
{
“name”: “attr/modelid”
},
{
“name”: “attr/name”
},
{
“name”: “attr/swversion”
},
{
“name”: “attr/type”
},
{
“name”: “attr/uniqueid”
},
{
“name”: “config/battery”,
“parse”: {
“at”: “0x0020”,
“cl”: “0x0001”,
“ep”: 35,
“script”: “develco_battery.js”
},
“default”: 0
},
{
“name”: “config/offset”,
“default”: 0
},
{
“name”: “config/on”
},
{
“name”: “config/reachable”
},
{
“name”: “state/lastupdated”
},
{
“name”: “state/temperature”,
“default”: 0
}
]
},
{
“type”: “$TYPE_WARNING_DEVICE”,
“restapi”: “/lights”,
“uuid”: [
“$address.ext”,
“0x23”
],
“items”: [
{
“name”: “attr/id”
},
{
“name”: “attr/lastannounced”
},
{
“name”: “attr/lastseen”
},
{
“name”: “attr/manufacturername”
},
{
“name”: “attr/modelid”
},
{
“name”: “attr/name”
},
{
“name”: “attr/swversion”
},
{
“name”: “attr/type”
},
{
“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’) { ‘01FF001001000000’ } else { ‘0000000000000000’ }”,
“fn”: “zcl:cmd”
},
“default”: “none”
},
{
“name”: “state/reachable”
}
]
}
],
“bindings”: [
{
“bind”: “unicast”,
“src.ep”: 35,
“cl”: “0x0001”,
“report”: [
{
“at”: “0x0020”,
“dt”: “0x20”,
“min”: 300,
“max”: 43200,
“change”: “0x00000001”
}
]
},
{
“bind”: “unicast”,
“src.ep”: 35,
“cl”: “0x0500”
},
{
“bind”: “unicast”,
“src.ep”: 38,
“cl”: “0x0402”,
“report”: [
{
“at”: “0x0000”,
“dt”: “0x29”,
“min”: 60,
“max”: 600,
“change”: “0x0000000A”
}
]
}
]
}
(modified the eval method)
So it’s shown as a light in Phoscon and an AlertDevice in OpenHab.

I copied the ddf, changed the eval-method and placed it under
/home/user/.local/share/deCONZ/devices

If I delete a part of this ddf, it’s gone from phoscon, too. So I think the file is loaded.
But if I start deCONZ-Gui I have to stop the phoscon-service because the gui comes with it’s own, so I don’t know if the file is loaded or not.

Fact:
The payload in the modified eval is not sent when triggering with “select”.
So I see 2 possibilities here:

The file is loaded properly using phoscon-service but not loaded properly when using deCONZ-Gui ( I don’t think so because the default-ddf-file uses a 5-byte payload - but 8 are needed and sent)
The “name”: “state/alert” - part is useless and some other mechanism is triggered while triggering the alarm

This is what I need to send:

01FF001001000000

This is what is sent:

110B001701000000

I have absolutely no idea where this is coming from. Ideas?
Thanks

Smanar · January 9, 2025, 3:19pm

And if you try with a random number ?

“eval”: “if (Item.val == ‘select’) { ‘1122334455667788’ } else { ‘AABBCCDDEEFFGG’ }”,

To see the result on logs.

fabian91 · January 9, 2025, 4:03pm

There is always:

PS-DATA.confirm id: 87, status: 0x00 SUCCESS
Even if I change it to

“eval”: “0”
it logs:

16:56:10:813 ZCL cmd attr 0x0015BC00310269B4, ep: 0x01, cl: 0x0502, cmd: 0x00, mfcode: 0x0000, aps.id: 87, zcl.seq: 26
16:56:10:813 APS-DATA.request id: 87, addrmode: 0x03, addr: 0x0015BC00310269B4, profile: 0x0104, cluster: 0x0502, ep: 0x01 → 0x01 queue: 0 len: 4 tx.options 0x00
16:56:10:813 asdu (length: 4): 111A0000
16:56:10:844 APS-DATA.confirm id: 87, status: 0x00 SUCCESS
16:56:10:844 APS-DATA.confirm request id: 87 → erase from queue
16:56:10:849 aps request id: 87 finished, erase from queue

even with eval: “0”
I can toggle between “none” and “select” a few hundret times. Nothing happens.
Then I choose “lselect” and booom, the alarm goes off.
Sounds useable… but the alarm will not stop until I remove the batteries…

Another thing:
I’ve toggled a few times bewtween “none” and “lselect”.
Every time “none” was chosen, the request looks like this:

APS-DATA.request id: 209, addrmode: 0x03, addr: 0x0015BC00310269B4, profile: 0x0104, cluster: 0x0502, ep: 0x01 → 0x01 queue: 0 len: 4 tx.options 0x00
asdu (length: 4): 110C0000

And lselect looks like this:

APS-DATA.request id: 64, addrmode: 0x03, addr: 0x0015BC00310269B4, profile: 0x0104, cluster: 0x0502, ep: 0x01 → 0x23 queue: 0 len: 8 tx.options 0x04
asdu (length: 8): 111800172C010A00

Smanar · January 10, 2025, 3:39pm

“eval”: “0”
16:56:10:813 asdu (length: 4): 111A0000

This one is better for me, remember first bytes are zigbee stuff, not the value.
But the lenght is bad, 0x0000000000000000 is not the same thing than 0x00