Halo Smoke Alarm fails to detect smoke or carbon monoxide alerts, falsely claims clear

🛎️ Get Help
1

When the Halo smoke alarm detects smoke, the messages it sends aren't properly parsed by the driver:

dev:8402020-10-08 01:43:21.964 pm infoSmoke - Kitchen  smoke and carbon monoxide are clear
dev:8402020-10-08 01:43:21.960 pm debugzigbee.parseDescriptionAsMap-read attr: [raw:catchall: 0104 FD00 04 01 0040 00 A81B 01 01 1201 00 01 00, profileId:0104, clusterId:FD00, clusterInt:64768, sourceEndpoint:04, destinationEndpoint:01, options:0040, messageType:00, dni:A81B, isClusterSpecific:true, isManufacturerSpecific:true, manufacturerId:1201, command:00, direction:01, data:[00]]
dev:8402020-10-08 01:43:21.951 pm debugparse: catchall: 0104 FD00 04 01 0040 00 A81B 01 01 1201 00 01 00
dev:8402020-10-08 01:43:12.015 pm debugzigbee.parseDescriptionAsMap-read attr: [raw:catchall: 0104 FD00 04 01 0040 00 A81B 01 01 1201 00 01 13, profileId:0104, clusterId:FD00, clusterInt:64768, sourceEndpoint:04, destinationEndpoint:01, options:0040, messageType:00, dni:A81B, isClusterSpecific:true, isManufacturerSpecific:true, manufacturerId:1201, command:00, direction:01, data:[13]]
dev:8402020-10-08 01:43:12.008 pm debugparse: catchall: 0104 FD00 04 01 0040 00 A81B 01 01 1201 00 01 13

Likewise the same is true for carbon monoxide:

dev:8402020-10-08 01:44:51.725 pm infoSmoke - Kitchen  smoke and carbon monoxide are clear
dev:8402020-10-08 01:44:51.712 pm debugzigbee.parseDescriptionAsMap-read attr: [raw:catchall: 0104 FD00 04 01 0040 00 A81B 01 01 1201 00 01 00, profileId:0104, clusterId:FD00, clusterInt:64768, sourceEndpoint:04, destinationEndpoint:01, options:0040, messageType:00, dni:A81B, isClusterSpecific:true, isManufacturerSpecific:true, manufacturerId:1201, command:00, direction:01, data:[00]]
dev:8402020-10-08 01:44:51.702 pm debugparse: catchall: 0104 FD00 04 01 0040 00 A81B 01 01 1201 00 01 00
dev:8402020-10-08 01:43:59.424 pm debugzigbee.parseDescriptionAsMap-read attr: [raw:catchall: 0104 FD00 04 01 0040 00 A81B 01 01 1201 00 01 12, profileId:0104, clusterId:FD00, clusterInt:64768, sourceEndpoint:04, destinationEndpoint:01, options:0040, messageType:00, dni:A81B, isClusterSpecific:true, isManufacturerSpecific:true, manufacturerId:1201, command:00, direction:01, data:[12]]
dev:8402020-10-08 01:43:59.417 pm debugparse: catchall: 0104 FD00 04 01 0040 00 A81B 01 01 1201 00 01 12
2

Well that’s a bummer.

IIRC they stopped further development efforts for this driver a while back, but perhaps @mike.maxwell has time to look into this?

1 Like
3

@mike.maxwell created this driver after the company had already folded. It's 100% his code.

4

Yes I’m aware he wrote the built-in driver for this device (and many others). Hence why I tagged him.

Just pointing out that for this driver, they took the unusual step of announcing they wouldn’t continue to develop it and released the code in their public GitHub repository.

Granted, that was unrelated to the issue you are bringing up, so perhaps they’ll come back to it if there’s something in need of a fix.

Then again, they might not. If that’s the case, hopefully a community dev could step in, fix it, and submit a pull request to the hubitat team.

1 Like
5

It's an official driver in their build which HSM purportedly can get smoke and carbon alarms from... and yet they don't work.

Zigbee isn't documented the way Z-Wave is. Read @mike.maxwell's thread on development of this driver. He was stabbing in the dark.

I'd totally provide a PR or a community driver if there was any reasonable chance of being able to diagnose or debug what's happening, but Zigbee is unparseable even by people who support it. Numberous 1st-party developers have told me that zigbee decoding isn't possible: "We can only work with information the SDK provides to us"

6

Yup, and if there’s something wrong with the driver, I do hope they fix it. I have one of these devices too.

But unfortunately for us, I don’t think they’re under any obligation to, and I think you’ve reiterated why they gave up working on this driver in the first place, so I will not hold my breath.

But I’m more of a glass half-empty kind of guy, so hopefully I’m wrong about that :slightly_smiling_face:.

1 Like
7

Depends on what's in that glass :smile:

1 Like
8

well that's sort of true, but a bit misleading...
anyway, from what you posted, the device is reporting read attribute values, the driver is parsing read attributes, its converting the data[0] value of 00 into clear, but isn't converting the values 12 and 13 into whatever it's supposed to convert these to...
Try changing the following:
line 163 case "AL1" to case "13"
line 167 case "AL2" to case "12"

if that works, i'll update the repo and production driver code

2 Likes
9

Well if there is any way I can help fix Zigbee drivers, tell me how. I'm happy to hack. Every time I've asked someone else they shrug and say it's hard for them and they own the hardware. If there's any docs I can learn from, point me the way. Z-Wave is considerably more open.

Thanks, I'll give that a try... and set something on fire. Fire!
Fire!
heh heh

10

You'll notice I didn't say it was always easy...

11

Anyone try reaching out to these guys? They appear to have some of the original SmartThings / Iris code in their repos

Device handler for SmartThings Hub:

Also found this:

Arcus Platform

12

LMAO, the origin of this driver is us...

13

Author: Halo/SmartThings (original), MMaxwell (from Hubitat), JSConstantelos (modifications/updates)

I did see that he used some of your code, but the "Halo/SmartThings (original)" made me wonder if he had access to something we don't

14

Was this ever fixed? My Halos are one of the final devices left to move over from SmartThings but I'm still hesitant.

15

my halos & halo+ plus work on HE. Not as well as on ST, as you can't adjust the WWB on the plus.
The ones on HE do report smoke, however never tested CO and I'm not gonna pull a Mike and climb out the window to my car's tailpipe to test CO reporting in HE, but CO works even without any zigbee connection.

16

I still haven't gotten to testing this change (until today) gah.

For anyone looking, my Halo units are ~4 years old according to the manufacturing date and they are starting to kick out random alarms. With nothing going on, and no source of smoke (no cooking, no shower or humidifier running) one of them at random will wake up, announce "Smoke Detected" and start to beep. Then suddenly they will stop as if they wake up and realized they were dreaming.

Data points of interest: these false alarms don't appear to trigger Zigbee notifications. Whereas a real smoke alert does generate a Zigbee notification. I've finally applied the changes @mike.maxwell mentioned above and added a few other logs for any message received to capture some more data...

I had hoped to keep using these until something better came on the market but it seems my only choice may be to go non-smart :frowning:

17

^ basis for this statement:
We have Nest Protects too... good sensors, but they complain about needing new batteries every week. They only work with one specific and quite expensive battery. It's totally a false alarm and they run for years after complaining but it means I can never trust they'll be powered when a problem happens. (and don't love the cloud dependency either)

First Alarm just sucks, both in the false alarm and in detection. A friend had constant false alarms, but when the real fire came he was choking in the hallway before the alarm triggered) . There are several other units with good reports (netatmo, etc) on the market, but not for sale in the US

18

I’ve mostly changed over to using dumb detectors, and adding ecolink firefighter devices to integrate with Hubitat.

An inexpensive option for smoke detectors with a wired interconnect. More expensive without that, since one would need a firefighter device for each smoke detector.

2 Likes
19

Yeah that's pretty much what I'm thinking I'll have to do. I do have a smoke alarm detector too, tied to my Abode system as backup already.

The one thing I really, really wanted was Location information. Getting an alarm telling me location would be really helpful in the case of detached garage, parent's home down the street, etc...

Smoke alarm vendors appear to be much more interested in giving me Alexa voice controls and music, rather than data about fires :frowning:

20

I hear you, but I’m not sure how common that is within the world of residential fire/life safety systems, generally speaking?

Fundamentally, the purpose of smoke detectors in the home is to alert the inhabitants of a fire as early as possible so they can safely exit the dwelling and call for help.

I’ve never had a traditional home security system with detectors that wire into a panel for central station monitoring, though, so maybe that’s more common among those?