Those door sensors have handy screw terminals in parallel with the reed switch so you can wire other things directly into them without needing to solder anything:
So then I have the door sensor report if the alarms are triggered or not. Obviously only a solution if you have wired smoke alarms but simpler and cheaper than wrangling a bunch of zwave smoke detectors.
Over the weekend end I set off my fir alert zwave smoke detector cooking bacon, and to my surprise the smoke alarm automations didn’t trigger. I am not sure if this had to do the transition to Zwavejs or not but I noticed my alarm type when normal is 13 with a level of 255.
When the smoke alarm triggered it went to alarm type 1 and level of 0 instead of what I thought was 255
Has anyone else seen this? I plan to make the smoke alarm automations more sensitive to the type changes, would almost rather have false positives.
I also noticed similar behavior but thought it was because I silenced it right away… meant to test again but haven’t yet cuz my dogs don’t like it going off… but it seemed to be 255 as expected then went to 0 after silencing (but as I said never verified)
I have the same problem with the dogs. I never silenced mine, for now I removed the level requirements from the template sensor and also added a trigger for my automation to trigger when it goes from “ok” to “unknown”. I’ll get the dogs out and push the test button here soon. and maybe try a burning something to try it out again.
So I just looked and both of my first gen ones are unavailable the newer model stayed connected… that’s unfortunate
EDIT: Also the battery life seems horrible in this first gen models… hopefully it’s just because of the back and forth between zwaves I have been doing so it is excessively interviewing and what not…
I was having trouble with my ZCOMBO after switching to ZWaveJS but was able to get it resolved. This this comment and the surrounding ones for details.
finally getting around to moving from SmartThings to HASS this week, getting ZCOMBO devices working was the first hurdle. I have 6 of the older ones from the start of the thread, rewrote the sensor.yaml a bit to make it easier to add multiples. couldn’t find any sort of case-switch statement for jinja so had to stick with if-elseif…
- platform: template
sensors:
detector_attic:
friendly_name: 'detector attic'
value_template: >
{% set s = states('sensor.detector_attic_alarmtype') %}
{% if s == '1' %}
smoke
{% elif s == '2' %}
co
{% elif s == '12' %}
test
{% elif s == '13' %}
idle
{% else %}
{{ s }}
{% endif %}
icon_template: >
{% set s = states('sensor.detector_attic_alarmtype') %}
{% if s == '1' %}
hass:fire
{% elif s == '2' %}
hass:molecule-co
{% elif s == '12' %}
hass:wrench
{% elif s == '13' %}
hass:smoke-detector
{% else %}
hass:help
{% endif %}
I was able to get it figured out on my end… basically I had some indent issue as well.
Here’s my updated working template if anyone else runs into the same issue:
template:
sensors:
kitchen_smoke_co_alarm:
unique_id: kitchen_smoke_co_alarm_status
friendly_name: 'Kitchen Smoke & CO Detector Status'
value_template: >-
{% if is_state("sensor.kitchen_smokeco_alarm_alarmlevel", "255") and is_state("sensor.kitchen_smokeco_alarm_alarmtype", "1")%}
!!!SMOKE DETECTED!!!
{% elif is_state("sensor.kitchen_smokeco_alarm_alarmlevel", "255") and is_state("sensor.kitchen_smokeco_alarm_alarmtype", "2")%}
!!!CARBON MONOXIDE ALARM!!!
{% elif is_state("sensor.kitchen_smokeco_alarm_alarmlevel", "0") and is_state("sensor.kitchen_smokeco_alarm_alarmtype", "12")%}
TEST TEST TEST
{% elif is_state("sensor.kitchen_smokeco_alarm_alarmlevel", "255") and is_state("sensor.kitchen_smokeco_alarm_alarmtype", "13")%}
Safe - Normal Operation
{% else %}
UNKOWN
{% endif %}
icon_template: >-
{% if is_state("sensor.kitchen_smokeco_alarm_alarmlevel", "255") and is_state("sensor.kitchen_smokeco_alarm_alarmtype", "1")%}
mdi:fire
{% elif is_state("sensor.kitchen_smokeco_alarm_alarmlevel", "255") and is_state("sensor.kitchen_smokeco_alarm_alarmtype", "2")%}
mdi:cloud-outline
{% elif is_state("sensor.kitchen_smokeco_alarm_alarmlevel", "0") and is_state("sensor.kitchen_smokeco_alarm_alarmtype", "12")%}
mdi:alert-octagram
{% elif is_state("sensor.kitchen_smokeco_alarm_alarmlevel", "255") and is_state("sensor.kitchen_smokeco_alarm_alarmtype", "13")%}
mdi:smoke-detector
{% endif %}
I also added modified the top to include packages like so:
Just want to give an update for these FirstAlert smoke/CO detectors. Super easy to set up now - didn’t have to do anything fancy. Went into the z-wave integration, clicked Add Node Secure, held the button on the device with the battery try open, then closed the battery tray with the button held down, done. It was added easily.
I then removed all entities other than CO and Smoke and set up automations to alert to my phone and through my sonos speakers if any of the detectors went off. Works beautifully.
I wish I could concur with your results. Mine still behaves the same as it always has - battery level, alarm level and alarm type. Doesn’t matter if I perform a secure or insecure inclusion. I just got the thing a few months back and keep trying every so often to see if something happened behind the scenes that would enable support. FWIW it’s reporting firmware version 0.5.
I just added mine (coming from SmartThings) and mine is also not showing CO or Smoke. Just battery, low battery, alarm level, and alarm type. The last two being disabled.
So for the sake of comparing notes, if possible, could we also list which First Alert (z-wave) unit / model we are using, and which version of FW in the alarm?
Reading through the thread, I have a feeling that we might be talking about different First Alert Z-wave units here and there, on top of differences on integration, and config/setup.
I’m saying this because First Alert might have gone through a couple of different iterations in terms of the alarm itself.
I had this working fine in my legacy zwave integration. After updating to the new Zwave JS MQTT addon/integration, I cannot get the alarm types in. I get that the thing needs to be re-interviewed - the Zwave JS MQTT config screen actually properly displays the alarm type and state… but it just doesn’t appear in Home Assistant. I still only have the battery %, low battery sensor, and testing sensor. No amount of restarting the zwavejsmqtt addon, the zwave js integration, or Home Assistant seems to help.
I’m having similar issues with entities with the first gen model and ZWave JS. I am able to successfully pair and interview the device but I only get Battery Level and Low Battery Level enabled with alarmLevel and alarmType disabled by default. When enabling those two I get readings of 255 and 13 respectively, which aren’t very useful. Any advice on how to get this properly set up?
The first gen model does not create those entities you have to make the template sensors yourself. There are some examples in this thread and a couple others.
the newer model stayed connected… that’s unfortunate
