Trouble including Develco smoke/heat sensors

[Fr00t]

Hi,

I'm trying to include som SMSZB-120 and HESZB-120 in my network. Running FW 2.05.71 which should be the latest that touch on the support of these sensors as far as I can tell.

I'm trying to add through Phoscon, and I can see them show up in Deconz, but they are not identified correctly. I've tried multiple sensors, restarted everything and still no success.

Some show up like this (not visible at all in Phoscon):

Some show up like this (not visible at all in Phoscon):

And I've got one detector that seems to have been identified correctly and responding to IAS-WD commands (Visible as warning device in Phoscon).

The heat detector I added showed up seemingly correctly, but doesn't respond to IAS-WD commands (also visible as warning deice in Phoscon).

The identified sensors show up as lights in Phoscon:

EDIT: I see siren support for heat sensor was added in 2.5.75 which is probably why it doesnt work for me. This version doesnt seem to have a windows version yet so I cant test

Any tips on how I can have better luck adding these sensors?

[SwoopX]

@Fr00t : Sorry, but this is necessary now: there is a search function for issues!

Enough kidding. Version .71 has not yet included the vital updates for smooth sensor discovery. Also managed to iron out a firmware error from them in this regard.

For the smoke sensors: By now, they should run nearly perfectly (the caveat you experienced in Phoscon). I got 4 of them running fine and 2 more waiting for action. It is possible to correct the manufacturer thingy you see (and any incorrect info in the node info panel), but a manual update of the deconz database is required for that https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2127#issuecomment-573210412

For the heat sensors: Version .75 should have some updates indeed regarding the siren. However, I'm lacking proper feedback to understand if it is working ok

Without updating, you could follow this procedure https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2052#issuecomment-552202908 to find the missing endpoints and have the missing sensors created. However, automatic attribute reporting will not work, so you have to do the bindings and the reporting adjustments manually.

[Fr00t]

@SwoopX Sorry I'd actually searched. I've actually read the thread you linked, but somehow I forgot about its contents. I was under the impression that those issues were "fixed" in the .71 version so I didnt think they could help anymore.

Is there a noob friendly way to run .75 on windows before they compile it? The last version I found for Windows was .74.

I've updated to .74 now and will report back after giving it another try today :) I've deleted the sensors that wasn't included correctly in Deconz and reset the sensors before trying. Not to eager to mess with the database directly, so hoping this will work! :)

[SwoopX]

I'm pretty confident. Just let me know.

[Fr00t]

Thanks a lot! I've included all 9 sensors now (7 smoke, 2 heat), and they seem to show up just fine. Had to restart Deconz every few alarms, but thats not a big deal.

Can also execute heat sirens with version .74

One question though. How can I get them to alarm in series? The manual says holding the button for 6+ seconds should make all of the sirens go off, but for me its just one at a time.

I've added the "lights" to a group in the hopes that would fix it, but alas.

I've got a feeling this has to do with adopting/enrolling a IAS Zone, but I'd like to ask before making a mistake.

Thanks again @SwoopX

[SwoopX]

Parallel warning of all devices is the "killer feature" everybody is asking. To be honest, haven't tried it yet. I need to have my kid and dog to be out and me being at home, which is jobwise a pretty rare condition. These days, the difficulties lies a bit differently...

But not sure if I understood you correctly, have all devices fired of during an alarm condition? If so, theoratically, there's a command in deconz GUI which should cease the alarm condition (in fact, it is). The point I'm not sure about is, if this spreads out to all devices.

[ebaauw]

My Heiman siren supports the Groups server cluster. I hadn't tested it before, but it works as expected. I can can send a group command to turn on or off the siren (double-checked by WireShark, that it's indeed a groupcast). Not sure if the fire/smoke sensors support Groups as well. In the GUI, you can send group commands, using the Destination Settings popup from the Edit menu (or by pressing F6).

I'm not too familiar with IAS Zone devices, but I don't think you can bind the fire/smoke sensors to (other) sirens directly (or through a group). You would need an IAS controller (or what's it called) in between, see Fig. 8-1 in the ZCL spec.

Getting the REST API to support groups of non-lights is on my list, but will be a lot of work. I need my PR to refactor the light state to be merged, then apply the same logic to the group action. I think it would be best to use different state or action attributes for warning devices and window covering devices, see https://github.com/dresden-elektronik/deconz-rest-plugin/pull/2553#issuecomment-597260650, point 4. Alternatively, we would need to keep track of what devices types are in a group. Or maybe use group types SirenGroup and WindowCoveringGroup (instead of LightGroup).

[ebaauw]

@SwoopX @Fr00t, where do you get these sensors? Develco seems to sell them only to OEM vendors.

[Fr00t]

@SwoopX I might have misunderstood these things it seems. I thought they were able to fire off eachother during an alarm. i.e fire starts in basement, Conbee is offline for some reason -> All sensors siren.

@ebaauw I got mine from this site in Norway. https://www.elektroimportoren.no/ Thanks for pointing me to the figure, seems this functionality might not be in Zigbee the way i thought.

I can fire the sirens of from Homeseer through Jowihue, I just wanted a solutian with local redundancy in case anything goes wrong on the way. Homeseer/Jowihue/Deconz/Conbee all need to be online for this functionality. They usually are, but I dont want critical safety features to work most of the time, I want it all of the time :)

[SwoopX]

@ebaauw You can also buy them from the ubisys shop, but there, they're pretty costly. I bought them at cozify.fi

[ebaauw]

Thanks, I’ll have a look.

You should be able to control the sirens using deCONZ rules, even without group support by the REST API plugin. That way, the only dependency is deCONZ itself. I run deCONZ on a Raspberry Pi powered by a USB power bank that supports passthru charging. It powers the Pi for (I think) over 12 hours when the mains power fails. See http://raspi-ups.appspot.com/en/index.jsp.

[SwoopX]

Erik, I can also send you one if you like. Got some of them lying around.

[ebaauw]

@SwoopX that would be brilliant! Could you please contact me by email or by PM on Discord.

[Fr00t]

@ebaauw @SwoopX Just wanted to bump here to hear if you've had the time to look at this? :)

Thanks

[ebaauw]

I recevied one from @SwoopX, which joined my network just fine. I advertises Manufacturer Code 0x0000 in the Node Descriptor so to see the Develco specific attributes in the Basic cluster, I needed to patch the code in the database. Not sure how to do that from the REST API plugin (assuming that's possible in the first place). No big deal though, as these (read-only) attributes don't seem to provide any useful info.

I tried to link the General domain to the Develco profile, to get the standard cluster definitions for 0x0003, 0x0005, and 0x006. But after that, deCONZ complains: "Can't send ZCL command we don't have a compatible endpoint". Seems hard-coded; I cannot find anything in general.xml to indicate that a profile supports ZCL. This is specified only at domain level. Still need to try probing these clusters with the CLI plugin.

I haven't found any way to link the detector directly to a siren (or another detector's siren). As it doesn't support Groups, you'd have to create rules with an action for each detector's siren individually. With a limit of 8 actions per rule (or was that only on the Hue bridge?), you might have to resort to multiple rules. Not at all pretty.

The detector does react to network-wide broadcasts (destination 0xFFFF). From the GUI, I cannot seem to send a broadcast to endpoint 0xFF, so I haven't yet been able to activate my Heiman Siren and the Develco detector with one single command (as they use different endpoints). Need to try with the CLI plugin.

Even so, the REST API plugin currently doesn't provide a means to specify a network-wide broadcast (/groups/0 issues a groupcast to the Zigbee group mapped to this resource). Nice design challenge for APIv2. Maybe create a virtual group "All Sirens", so people can complain that they cannot get rid of that group either.

[Fr00t]

I wont preted i understand more than a fraction of that post, but thanks a lot for your work!

I understood as much as the feature I want (link detectors directly outside DeConz) is not possible.

Think I'm gonna resort to linking them with Homeseer, as its easier to have the programming gathered there. The installation is very stable, but obviously wont protect against fires in the server (wouldnt help with programming in Deconz either).

As an extra precaution I'll add a separate, redundant, set of linked fire detectors on each floor. (I.e. 3 in total). I'll just get some simple 433Mhz linked detectors for cheap. Those will work side by side with the Develco detectors that I have in more rooms (heat sensors in kitchen/washing room, smoke in all bedrooms).

[ebaauw]

I understood as much as the feature I want (link detectors directly outside DeConz) is not possible.

Not in so far I know. There is a theoretical change that the Develco private profile provides something to set that up. However, without technical documentation, or their bridge for sniffing, we’re unlikely to find out.

Next best thing is to use deCONZ rules. I’m not fan of introducing another dependency (i.c. Homeseer), but if that runs on the same server, I suppose it’s not too bad.

I wont preted i understand more than a fraction of that post,

Sorry about that. In summary: I want to try and cook up a single REST API command to activate all sirens using a broadcast. I know this is doable for the sirens in the Develco sensors; I need to test when combined with other sirens.

I'll just get some simple 433Mhz linked detectors for cheap.

That might not be a bad idea. I currently have some mains-powered, battery-backed, linked smoke detectors, that also provide battery-powered emergency lighting. They were already installed when I bought the apartment, and are probably long overdue for replacement. Looking at the price difference with so-called smart sensors that don’t even match these (imho basic) specs, I’m not sure what to do. I might go for a combi of the cheapest battery-powered Heiman/Trust smart sensors I can find and Heiman mains-powered, battery-backed sirens (that do support groups). Or simply replace my old sensors with similar sensors, forgoing the home automation integration for the next decade (or whatever the life expectancy of these sensors).

[Fr00t]

Next best thing is to use deCONZ rules. I’m not fan of introducing another dependency (i.c. Homeseer), but if that runs on the same server, I suppose it’s not too bad.

Yea I agree. It's just a better practise to gather the user-programming in Homseer to not be confused down the road. Also they run on the same server, in the same VM even.

Or simply replace my old sensors with similar sensors, forgoing the home automation integration for the next decade (or whatever the life expectancy of these sensors).

Yea the smart smoke detectors are limited in specs and/or high in price. I'd rather have good coverage with lots of cheap sensors than poorer smart-coverage.

With that said, having detectors in Homeseer provides some nice functionality like possibility to turn on lights and open doors for evacuation, raise screens to give first responders more view into the house, and push-notifications about which sensor has triggered. 10 years is the correct life expectancy.

[SwoopX]

I advertises Manufacturer Code 0x0000 in the Node Descriptor so to see the Develco specific attributes in the Basic cluster, I needed to patch the code in the database.

At least the manufacturer code got patched with newer firmwares. However, due to the MAC capabilities still being 0 (and as I understand Develco support that is ok and adheres to zigbee standard, which it does on ZDO level), the node descriptor validity check still fails. That's in my opinion an inaccuracy in deconz core and therefore requires patching of the DB to have manufacturer specific attributes available.

I also asked Develco support if there are any plans to introduce the groups cluster; feedback is still pending.

[ebaauw]

That's in my opinion an inaccuracy in deconz core

Huh? Don’t you mean the REST API plugin? If not: Where in the core do you think this check is made? What core function doesn’t work?

[SwoopX]

@ebaauw

Huh? Don’t you mean the REST API plugin? If not: Where in the core do you think this check is made? What core function doesn’t work?

Well, it's probably both. There's 2 things to differentiate: macCapabilities amd node descriptor validity.

1. macCapabilities (REST API plugin) This is primarily used in rest_sensors.cpp and seems to pick up its data either from device anouncement or node descriptor. Based on my discussion with Develco support, it is not wrong to have macCapabilities set to 0x00 (for end devices, as the smoke sensors have set it) as zigbee standard makes no requirement to set the allocate short address bit to 1 (must be 0 or 1). This is why I believe those checks can be (partially) omitted. However, I haven't dared to make any changes there as it needs to be thoroughly tested; we briefly discussed that and there might be unknown/legacy reasons for that.

2. Node descriptor validity (deconz core) As I recall (and that's at least valid for the device running an older firmware I've send you), the node descriptor is evaluated as being Null in bindings.cpp, although a valid node descriptor response is transmitted. As far as I know, the node descriptor is processed in deconz core and there is also a function for that in zdp_descriptors.h (bool isNull() const;). We also had a brief discussion on this via Discord (Ghosting and issues #1653 and #2154). Maybe there's indeed something initialized wrongly; would love to identify the root cause for this.

[ebaauw]

Ah, so in your experience, the Node Info panel shows the wrong data for devices that report Mac Capabilities as 0?

[SwoopX]

As this is the only device where I've seen that, yes.

[ebaauw]

OK, I managed to hack a network broadcast command to activate all sirens. The Heiman siren reacts immediately; the Develco smoke detector 40-45s later. The coordinator (of my test network) is the detector's parent. It re-sends the NWK broadcast as MAC unicast to the end device, around the time it issues the APS-DATA-Confirm:

Apr 17 18:28:13 pi5 deCONZ[2029]: 18:28:04:456 add task 3499 type 34 to 0x000D6F000BE643B8 cluster 0x0502 req.id 50
Apr 17 18:28:13 pi5 deCONZ[2029]: 18:28:04:456 APS-DATA.request id: 50, addrmode: 0x02, addr: 0xffff, profile: 0x0104, cluster: 0x0502, ep: 0x01 -> 0xFF queue: 0 len: 8 tx.options 0x00
...
Apr 17 18:28:54 pi5 deCONZ[2029]: 18:28:47:556 Erase task req-id: 50, type: 34 zcl seqno: 111 send time 43, profileId: 0x0104, clusterId: 0x0502
Apr 17 18:28:54 pi5 deCONZ[2029]: 18:28:47:556 APS-DATA.confirm id: 50, status: 0x00 SUCCESS
Apr 17 18:28:54 pi5 deCONZ[2029]: 18:28:47:572 aps request id: 50 finished, erase from queue

IEEE 802.15.4 Data, Dst: 0xffa8, Src: 0x0000
    Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
    Sequence Number: 198
    Destination PAN: 0x5067
    Destination: 0xffa8
    Source: 0x0000
    [Extended Source: dresden-_ff:ff:03:d4:a7 (00:21:2e:ff:ff:03:d4:a7)]
    [Origin: 2]
    TI CC24xx-format metadata: FCS OK
ZigBee Network Layer Data, Dst: Broadcast, Src: 0x0000
    Frame Control Field: 0x0208, Frame Type: Data, Discover Route: Suppress, Security Data
    Destination: 0xffff
    Source: 0x0000
    Radius: 10
    Sequence Number: 50
    [Extended Source: dresden-_ff:ff:03:d4:a7 (00:21:2e:ff:ff:03:d4:a7)]
    [Origin: 2]
    ZigBee Security Header
ZigBee Application Support Layer Data, Dst Endpt: 255, Src Endpt: 1
    Frame Control Field: Data (0x08)
    Destination Endpoint: 255
    Cluster: Intruder Alarm System WD (0x0502)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 25
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x11)
    Sequence Number: 110
    Command: Start Warning (0x00)
    Payload
        0001 .... = Warning Mode: Burglar (1)
        .... 01.. = Strobe: Use strobe in parallel to warning (1)
        Warning Duration: 0x0001

Here's the original broadcast:

IEEE 802.15.4 Data, Dst: Broadcast, Src: 0x0000
    Frame Control Field: 0x8841, Frame Type: Data, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
    Sequence Number: 190
    Destination PAN: 0x5067
    Destination: 0xffff
    Source: 0x0000
    [Extended Source: dresden-_ff:ff:03:d4:a7 (00:21:2e:ff:ff:03:d4:a7)]
    [Origin: 2]
    TI CC24xx-format metadata: FCS OK
ZigBee Network Layer Data, Dst: Broadcast, Src: 0x0000
    Frame Control Field: 0x0208, Frame Type: Data, Discover Route: Suppress, Security Data
    Destination: 0xffff
    Source: 0x0000
    Radius: 10
    Sequence Number: 50
    [Extended Source: dresden-_ff:ff:03:d4:a7 (00:21:2e:ff:ff:03:d4:a7)]
    [Origin: 2]
    ZigBee Security Header
ZigBee Application Support Layer Data, Dst Endpt: 255, Src Endpt: 1
    Frame Control Field: Data (0x08)
    Destination Endpoint: 255
    Cluster: Intruder Alarm System WD (0x0502)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 25
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x11)
    Sequence Number: 110
    Command: Start Warning (0x00)
    Payload
        0001 .... = Warning Mode: Burglar (1)
        .... 01.. = Strobe: Use strobe in parallel to warning (1)
        Warning Duration: 0x0001

Still need to test with the Develco linked to another parent.

[Mimiix]

It seems this issue is resolved or otherwise inactive. If it is not, please re-open!

[torbjornsk]

Any news on getting these smoke detectors to group properly?

I've bought a couple to test, and can't get them to work, even though they show Zone State = Enrolled, have the same IAS_CIE_Address and Zone ID. The Deconz log periodically prints something like this:

20:56:47:473 [IAS ZONE] - 0x0015BC003100656D Status Change, status: 0x0030, zoneId: 100, delay: 65535 20:56:47:475 [IAS ZONE] - 0x0015BC003100656D Sensor is enrolled. 20:56:47:485 void DeRestPluginPrivate::handleIasZoneClusterIndication(const deCONZ::ApsDataIndication&, deCONZ::ZclFrame&),366: assertion 'stream.status() == QDataStream::Ok' failed 20:56:47:486 [IAS ZONE] - 0x0015BC003100656D Status Change, status: 0x0030, zoneId: 0, delay: 0 20:56:47:487 [IAS ZONE] - 0x0015BC003100656D Sensor is enrolled.

I'm not sure why it does both Zone ID 0 and 100, in the attributes in deconz/vnc it says Zone ID 0, while the Zone Status Change Notification part has Zone ID 100 under its Extended Status field. When I run what is supposed to be a network test of the smoke detectors, I get a similar "Status Change" message, with the status being 0x0130. I can't change the Zone status in the VNC GUI, as any attempt returns status 0x93 (no access or something?).

What's a bit strange, is that both when testing and in the logs that appear by itself, the devices seems to be separate. In the above log example 0x0015BC003100656D sends a status change and reports that it is enrolled. In other log messages, my other device does the same, but only seems to reach itself (?)

21:06:53:230 [IAS ZONE] - 0x0015BC00310053AB Status Change, status: 0x0030, zoneId: 100, delay: 65535 21:06:53:232 [IAS ZONE] - 0x0015BC00310053AB Sensor is enrolled. 21:06:53:244 void DeRestPluginPrivate::handleIasZoneClusterIndication(const deCONZ::ApsDataIndication&, deCONZ::ZclFrame&),366: assertion 'stream.status() == QDataStream::Ok' failed 21:06:53:245 [IAS ZONE] - 0x0015BC00310053AB Status Change, status: 0x0030, zoneId: 0, delay: 0 21:06:53:247 [IAS ZONE] - 0x0015BC00310053AB Sensor is enrolled.

I have found some extended technical documentation for the device here: https://www.develcoproducts.com/media/1742/smszb-120-technical-manual-smoke-alarm.pdf

I'm not getting much wiser by reading it though.

[SwoopX]

Sorry for being a bit blunt here, but I got no idea of what you're trying and neither of what you're trying to say.

The sensors are not groupable! They simply lack the groups cluster and do not allow for any group bindings. I guess I've only seen one sensor wupporting that until now. What we did here was a software workaround to fire the audio of all available warning device's sirens manually via API which depends them to support that feature.

Due to whatever reason, the devices always send 2 status zone notifications: a compliance one (1st) and a non-compliant one (2nd). The 2nd is where the error comes from and just can be ignored. In deconz GUI, neither playing with the tickmarks nor trying to set the zone status can succeed, as those are read only and set only by the device itself.

[heinekmadsen]

Hi... Stumbled upon this thread about the develco smoke detectors. I have 3 Frient branded "develco" alarms, which according to the product description, at the time of ordering, was supposed to be interconnectable with each other.

Time has past since I bought them and i had other things to do. Then recently i started to look at them again and realized that they weren't interconnected with each other. Reached out to "Frient" and they told me that they have only tested the product with a single coordinator where interconnectability is working, and that's not conbee :(.

So before I put the all up for sale, it there anything like "interconnectability" working for these some detectors? maybe some kind of grouping via deconz? (Not ideal but at least some kind of group).

I can pair them with deconz and are able to sound the siren from Home Assistant, but i cant stop the siren again unless i press the button on the alarm it self. Is it possible to remotely turn off the siren? (Purpose for this is to use the siren for alarm system for the house)