Hold it near your cars exhaust?
1 Like
I was able to add mine but it took a few tries. It kept wanting to do an unauthenticated install and would just load a basic node with no attributes. I found that if I went to the integrations page and just clicked on add integration, there is now 2 new additions at the top for adding Zigbee and ZWave devices. Adding it in that way seemed to do the proper L2 authentication and it loaded up all of the attributes correctly. I didn’t need to make any template sensors just needed to create my automations for notifications and add the sensors into Alarmo for monitoring.
See my post below
@kramttocs Did you ever hear back from First Alert on the error? My alarm just went off today and now it has this error and it is not going away.
Sorry, I never did.
Just a quick note that I migrated from the deprecated Wave 1.4 to ZwaveJS2MQTT today. I’d been putting it off, but it was in the way of upgrading HA (I was stuck on 2022.3.7, just before they removed the old integration).
I followed these great instructions:
A real worry that I had was our First Alert Smoke/CO detectors. They were a total pain to get working in the first place since they were not directly supported by the legacy integration (and they were fiddly trying to join the network).
Fortunately all I had to do was wait until they all woke up (step 9 of the instructions above). Took a while (I think the sleep interval is 70 minutes, worse case). So luckily I didn’t have to break out the ladder to wake them up or get them to re-join.
I did have to rework my templates, but it was well worth it to use the new entities that ZwaveJS2MQTT provided. Much better than the raw value templates that I had to hack together because the device was never directly supported by the deprecated Zwave integration.
Since my NodeRed integrations were using the template, I didn’t have to change the flows very much. I did remove a hack (which I’m not sure ever worked) that would report a low battery situation by looking at the battery percentage level. Instead I’m now using the provided entity that indicates if the unit is in low battery mode (binary_sensor.blah_blah_low_battery_level).
Luckily I’ve got some units with older batteries, so while testing the detectors, some of them ran out of juice and the binary sensor indicated low battery (exactly coinciding with the low battery chirp from the alarm).
Now I know that I’ll get a push notification when any unit is in low battery mode, and I can see their status from our wall panels. I no longer have to wander around listening for which unit is chirping.
It was a bit of work, but I’m very happy with the upgrade.
1 Like
Is there a way to trigger the alarm/siren via HA? Wondering if anybody ever made that work. Would love to add that to my security system as @LoRd_NeX also mentioned. As he also mentioned, would be great to be able to stop the alarm as well rather than having to wait for it decide to stop. Thanks!
2 Likes
Hi Guys,
I have some First Alert devices and today tried to connect them to my HA via an Aeotec gen 5 zw90 868.42Mhz . My First Alert smoke detectors are from 2018 “ZCOMBO” These device just do connect to the Aeotec gen 5. Is it possible that First alert devices use a different frequency?
No. ZWave frequencies are standard, they are regional - you can’t use US ZWave in the UK because of the frequency but they are standardized…
Hey all, I got my gen 1s working thanks to the people in this thread but had a question:
This morning one of the alarms went into state 12 alarm level 254. I know 12 / 255 is test, but what does 254 mean?
Thanks!
Hi!
I recently migrated from Smartthings and these are the last ones I’m trying to automate.
Luckily, I was able to add 12 of them without any hiccups via Zwave2Mqtt (JS UI).
Read the whole thread here from the beginning and It looks like there are two general version of these ZCombo - non-plus and the zwave-plus versions.
I have included mine via Zwave JS UI and from there, it doesn’t indicate I have the plus. Here is a picture too: (no zwave plus label anywhere). Firmware version 0.5
So having that established that I don’t have newer version. I was checking the states and was not able to find sample: ‘sensor.master_smoke_detector_alarmlevel’, ‘255’ – what I found are states that are for the new ones? (screenshot below)
So even though I have a Gen 1, does it mean I have to use the template for Gen 2 since the states will line up to that template?
Sorry but since I’m new to HA, I just want to make sure I understand before testing or making changes.
TIA!
This thread spans several years and multiple integrations, so a lot of information is out of date.
As of Z-Wave JS v10.10.0 (released Feb 2023), these sensors are created automatically for the first gen versions, and ZJS maps the old alarm values to the “new” notification values. Assuming the mapping is correct, it means you don’t need templates anymore.
2 Likes
that’s a super cool idea !
It’s supposed to map the values now? I just rebuilt my HA from scratch on a Yellow and I’m not seeing that. Brand new install of 2023.6.2, fresh install of Z-Wave JS UI. I did have the pairing still in the controller dongle (ZST10-700), so I just had to wake each detector up and they were back into HA. I am just getting the alarmLevel and alarmType sensors, so my old templates are still in use.
I currently have multiple binary sensors provided by the integration, based on the mapped values.
"manufacturer": "BRK Brands, Inc.",
"manufacturerId": 312,
"label": "ZCOMBO",
"description": "Smoke and Carbon Monoxide Alarm",
{
"domain": "binary_sensor",
"entity_id": "binary_sensor.smoke_and_carbon_monoxide_alarm_smoke_alarm_smoke_alarm_test",
"original_name": "Smoke alarm test",
"original_device_class": "problem",
"disabled": false,
"disabled_by": null,
"hidden_by": null,
"original_icon": null,
"entity_category": null,
"supported_features": 0,
"unit_of_measurement": null,
"value_id": "10-113-0-Smoke Alarm-Alarm status",
"primary_value": {
"command_class": 113,
"command_class_name": "Notification",
"endpoint": 0,
"property": "Smoke Alarm",
"property_name": "Smoke Alarm",
"property_key": "Alarm status",
"property_key_name": "Alarm status",
"state_key": 3
}
},
{
"domain": "binary_sensor",
"entity_id": "binary_sensor.living_room_smoke_detector_smoke_detected",
"original_name": "Smoke detected",
"original_device_class": "smoke",
"disabled": false,
"disabled_by": null,
"hidden_by": null,
"original_icon": null,
"entity_category": null,
"supported_features": 0,
"unit_of_measurement": null,
"value_id": "10-113-0-Smoke Alarm-Sensor status",
"primary_value": {
"command_class": 113,
"command_class_name": "Notification",
"endpoint": 0,
"property": "Smoke Alarm",
"property_name": "Smoke Alarm",
"property_key": "Sensor status",
"property_key_name": "Sensor status",
"state_key": 2
}
},
{
"domain": "binary_sensor",
"entity_id": "binary_sensor.living_room_smoke_detector_carbon_monoxide_detected",
"original_name": "Carbon monoxide detected",
"original_device_class": "carbon_monoxide",
"disabled": false,
"disabled_by": null,
"hidden_by": null,
"original_icon": null,
"entity_category": null,
"supported_features": 0,
"unit_of_measurement": null,
"value_id": "10-113-0-CO Alarm-Sensor status",
"primary_value": {
"command_class": 113,
"command_class_name": "Notification",
"endpoint": 0,
"property": "CO Alarm",
"property_name": "CO Alarm",
"property_key": "Sensor status",
"property_key_name": "Sensor status",
"state_key": 2
}
},
For what it is worth, mine have started to randomly trigger the fire alarm, which is extremely annoying. If you have these and plan on using them, the recommendation from their tech support is to vacuum them out on a weekly basis to avoid dust triggering the sensor.
No thanks! I’ll just pass on the hardware!
1 Like
To add another annoyance with these (not sure if the device or ZwaveJS) but I am getting so many ‘junk’ sensors:
Hi All, I’ve had two of the zwave first alerts for about 18 months now in a rental. I thought everything was good, but this last week I realized that both units had been removed from the wall and the batteries removed. This happened at least a week ago. Yet HA is still reporting that both units are online, batteries are still at ~75%, and everything looks find. All entities are still reporting available and no changes over this time period.
Does anyone know how or why both devices would be still active/available and alive within HA yet the units had no batteries installed? How can I periodically check a device like this to make sure it’s still active within an automation considering it goes to sleep?
I would have assumed that once the batteries were pulled and after a certain sleep time, HA would have realized there was no response and change the entities to unavailable or change to a dead node.
Thanks for any help.
I would have assumed that once the batteries were pulled and after a certain sleep time, HA would have realized there was no response and change the entities to unavailable or change to a dead node.
That isn’t functionality that the z-wave integration has. The Z-Wave driver does not even support it itself. You can create your own template entities to check some property. This will vary by device. For some devices you can check last wake up time. The first generation of ZCOMBOs don’t ever wake up. There is a heartbeat message you’ll see in the above templates. New generation supports both wake up and a heartbeat.
2 Likes