Sonoff hasn’t released an official edge driver for this device yet. My hub recognized it as a generic Zigbee sensor but gives no status information other than battery level and can’t activate it.
I found some information here that I think would be helpful but I don’t have the first clue about how to make a ST driver.
You can install the Sonoff driver for this device. You can find the link here.
For SmartThings Users: Check SmartThings. Add a little smartness to your things. for the SmartThings Drive.
Copied from SNZB-09P-SONOFF Help Center
A bit disappointing and maybe of interest, the Sonoff driver (no ST native alternative) does not expose the alarm to Home Monitor.
Because of this it can not be set as a response device without use of either routines on the trigger devices or a virtual alarm with triggering routines.
This is something I have noticed lacking in other manufacturer drivers (Frient heat sensor kitchen fire alarm for ex. - ST native smoke alarm driver does not expose this device either 
)…
It is frustrating 
(@nayelyz , off topic but re. the Frient device, is this a fault with the native smoke detector driver?)
Looks like every device that has an alarm capability works with STHM:
The frient smoke detector uses the stock SmartThings driver, the Tapo H110 are cloud connected, and the Woox siren uses my driver - so there’s certainly not a certification required.
Frient wise, yes, the smoke detectors do but the heat sensor (which is recommended for kitchens regardless of implementation) uses the ST stock smoke detector driver but is not exposed in STHM, like the Sonoff Alarm - although that is using manufacturer driver…
They must both be missing that capability?
Interesting. The heat sensor has the alarm capability:
Maybe it’s a matter of the category: SmokeDetector vs. TempSensor…
My Tapo H110 and the Woox siren are category Siren. So it looks like it must be one of these categories (SmokeDetector or Siren) and must have an alarm capability.
Yes, also odd is that the Frient is supposedly certified works with ST:
maybe I’ll contact them if I have a moment…
As I said: it doesn’t matter if the device is certified - otherwise my obscure Woox Siren wouldn’t show up in STHM. I’m pretty sure it’s the category of the device. When I find some time (later today or tomorrow) I can create a snapshot from the stock driver with only one line changed: SmokeDetector instead of TempSensor as the category in the profile for your device. Just to see what happens.
SecurityPanel works as well. Unfortunately the subset of Webhook SmartApp functionality that the community got to play with is no longer documented and I can’t remember if filtering available devices by categories was ever an option. It seems the most likely explanation but why on earth would they do that instead of just filtering by the Alarm capability?
I do note that with a virtual device I have it is the ‘both’ command that is used to activate the alarm and that doesn’t seem to be enabled for the heat sensor. Again I can’t remember if filtering on available commands was ever a configuration option.
Why wait when I can do it remotely via VPN (Tailscale + Termius on Android)?
@TheHundredthIdiot Please install the Zigbee Smoke Detector (TEST) driver from my channel and either switch to the driver from within the app or - even better - delete and re-add the device.
That would complicate things a lot more.
Hey thanks @Andreas_Roedl , I installed your driver and deleted/reinstalled the Frient and as you posited it still does not show as a detector in STHM.
Looks like it is the complicated option!
Just to clarify, it shows as a response alarm regardless of driver… my previous post was a bit non-specific!
That’s a bit of an understatement. What exactly is the issue then?
My apologies @Andreas_Roedl , yesterday was a loooong old day for me 
…
The issue is that the Frient does not show as a detector in STHM even though it is identified as such by ST driver assignment.
I see.
That’s because STHM only supports smoke (smokeDetector capability) and water leak detectors (waterSensor capability), but not heat detectors (temperatureAlarm capability).
Later today I could modify the driver again, so your device looks like and acts as a smoke detector… Edit: on the other hand, that would be ugly…
Curious that they claim it that ‘Smoke’ works with carbon monoxide detectors but they haven’t also extended it to work for heat alarms.
@Andreas_Roedl 
(sorry again…)
It does, I have (ZWave) CO detectors (Nice/Fibaro):
That use the stock Z-Wave Smoke Alarm driver and they do indeed show as smoke detectors in STHM (but not as response alarms - no Fibaro Z-Wave devices do…)
I had a closer look at the stock SmartThings Zigbee Smoke Detector driver, and the interesting part is that no Lua code change was actually necessary.
The driver was already prepared for exactly this situation.
The Frient HESZB-120 uses the dedicated frient subdriver, and its IAS alarm handling already checks independently whether the device supports temperatureAlarm and/or smokeDetector.
For a real alarm, the existing stock code contains:
if device:supports_capability(capabilities.temperatureAlarm) then
device:emit_event(temperatureAlarm.temperatureAlarm.heat())
end
if device:supports_capability(capabilities.smokeDetector) then
device:emit_event(smokeDetector.smoke.detected())
end
And when the alarm clears:
if device:supports_capability(capabilities.temperatureAlarm) then
device:emit_event(temperatureAlarm.temperatureAlarm.cleared())
end
if device:supports_capability(capabilities.smokeDetector) then
device:emit_event(smokeDetector.smoke.clear())
end
The same is true for the IAS test state:
if device:supports_capability(capabilities.temperatureAlarm) then
device:emit_event(temperatureAlarm.temperatureAlarm.heat())
end
if device:supports_capability(capabilities.smokeDetector) then
device:emit_event(smokeDetector.smoke.tested())
end
So SmartThings had already implemented support for exposing a Frient alarm simultaneously as a heat alarm and as a smoke/fire alarm.
The problem was simply that the HESZB-120 profile never declared the smokeDetector capability.
The stock profile contained:
- id: temperatureAlarm
version: 1
- id: temperatureMeasurement
version: 1
- id: battery
version: 1
but not:
- id: smokeDetector
version: 1
That means this part of the Lua code:
device:supports_capability(capabilities.smokeDetector)
could never evaluate to true for the HESZB-120, so the already existing smoke.detected(), smoke.clear() and smoke.tested() events were effectively dormant.
The experimental driver therefore makes only one functional production change: it adds smokeDetector to the existing heat-temp-battery-alarm profile.
The device now exposes both:
temperatureAlarm
heat / cleared
smokeDetector
detected / clear / tested
I deliberately left the existing device category as:
categories:
- name: TempSensor
unchanged for now. That way we are testing only one variable: whether adding the smokeDetector capability is enough to make the Frient Heat Detector available in SmartThings Home Monitor as a fire/smoke sensor.
So if this works, the stock driver is not missing any actual alarm-handling logic. It is simply missing one capability declaration in the HESZB-120 profile.
Added two lines to the profile - that’s all:
- id: smokeDetector
version: 1
I’ll strip down the driver later, so it’ll be lean and elegant.
Edit: here it is:
────────────────────────────────────────────────
Driver Id 756b1240-b84b-4d7b-9f95-4561ca22486a
Name frient Heat Detector HESZB-120
Package Key zigbee-frient-heat-sthm
Version 2026-08-14T16:39:39.312237496
────────────────────────────────────────────────
I removed all unrelated fingerprints, profiles, custom capabilities, tests, Aqara/MultiIR/ShinaSystem code, the Frient subdriver structure, can_handle.lua, lazy loading, and sub_drivers.lua.
The Frient implementation is now directly integrated into the main init.lua. It still retains all HESZB-120 functionality from the stock driver.
zigbee-frient-heat-sthm-v1.1.0/
├── config.yml
├── fingerprints.yml
├── profiles/
│ └── heat-temp-battery-alarm.yml
└── src/
└── init.lua
Do you know if the device would detect if an electrical range/cooktop/stove is left turned on?
I don’t know but believe not in day to day use.
Mine is mounted about 2-2.5 feet out from the front of a gas range (itself in an alcove) and on a 9ft high ceiling so by no means on top of the range but in the locality. I have had no false positives from it as yet.
Unlike the many I have had from various smoke detectors… mind you that may just have been my cooking 