Cavius smoke detector integration?

Well done! :tada: :clap:

@hhovde I’ve (finally) set up as you proposed (rtl_433 -f 868.68M -s 250k -R 179), but get nothing (I’ve waited half an hour or so). Have you noticed how often the Cavuis detectors transmit? I’m wondering if they transmit very seldom (and that’s why I haven’t seen anything yet) or if my rtl_433 instance is not working as expected.

Just caught this thread, as I am trying to see if I can get some data from my Cavius smoke alarms as well. Using a standard (cheap) USB stick with a R820T tuner…
I have tried the command “rtl_433 -f 868.68M -s 250k -R 179” as well, but doesn’t really see any output (just tried to remove the battery from one of the detectors and re-inserting it, to see if that could initiate some traffic)
Update: I suspect that battery level only is sent in case of events on the detector, that means testing, pairing, smoke detected - and low battery…

Yes, the Cavius detectors claim that they have five years battery life, so it might be that they only transmit when something’s going on, not just to say «hey, I’m fine». Although, how can the hub be sure that the detectors are fine if they don’t (once in a while) transmit a «I’m here» message?

@uphillbattle and @bipsen;
First and foremost, make sure you have the latest version of rtl_433. The PR where accepted back in February, and was officially added to rtl_433 in version 21.5, released in May this year. Usually linux repositories is lagging a bit behind. You can download and install the latest version directly from github if needed.
To get your running version, run “rtl_433 -V”

Thanks, I was aware that Cavius (sensor 179) was a recent addition. On my Home Assistant instance, I run the rtl_433 addon which currently includes the 21.05 version of rtl_433.

rtl_433 version 21.05 branch  at 202105091238 inputs file rtl_tcp RTL-SDR

I have also tried an even more recent version which I compiled directly from github, but I not even that rtl_433 instance has reported any messages from the Cavius detectors.

Are you receiving messages regularly on your system, @hhovde ?

Running this version pulled from Github:

rtl_433 version 21.05-100-g118a5265 branch master at 202110080858 inputs file rtl_tcp RTL-SDR

Should frequency be changed ? The source code of rtl-433 for cavius lists:

The alarm units use HopeRF RF69 chips on 869.67 MHz, FSK modulation, 4800 bps.

I also just tried to test one of thr wireless units (by pressing the “test button” on it - and RTL433 did not seem to catch anything…

Tried once more - with frequency 869.680MHz.

Here I get:

time      : 2021-10-09 14:58:53
model     : Cavius-Security                        Device ID : 190861
Battery   : 1            Net ID    : 81374         Message   : 64            Description: Test alarm   Integrity : CRC

Now I just need to find out if the battery status is transmitted in intervals - or if the way the hub behaves actually is by querying the devices (as a radio module in receive mode consumes way less power than in transmitting mode).

Yeah, minor adjustments to the frequency may be required, due to imperfections in the cheap hardware. Most dongles will have some frequency offset. Be aware that your receiver might also fade out of sync once it’s heated up and will need to be re-adjusted.
It’s possible to remove the offset by “calibrating” your dongle with rtl_433’s -f flag. To know how much your hardware is off, you can either use the dongle against a known source and measure the offset or utilize one of the many great opensource tools out there, like this little program: https://github.com/asdil12/kalibrate-rtl.

As to the status of the battery, it’s transmitted via a single bit, in each and every transmission from the device. (Battery Low: Yes/No)

I guess the basic question right now is if there is some sort of “keepalive” traffic being sent at regular intervals - or the radio communication between the devices only is “event-based” …

I have now tried frequencies spaced 50 kHz apart from 868.0 MHz to 870.0 MHz (i.e., 868.0, 868.05, 868.1, 868.15, …), but I get nothing. It has taken me a couple of days. I presume that the smoke detectors transmit on a regular basis, and presume that waiting 15-30 minutes at each frequency should give me something if they are, in fact, transmitting within such an interval.

Do you guys also use the hub, or do you just have the smoke detectors? I have the hub and have paired the detectors with the hub, and I wonder if it could be that the pairing in some way modifies the communication.

I have also, by the way, set the rtl frequency to 433.92 MHz to check if it finds some temperature sensors I have, and it does, so it does work - but I have not had success with the smoke detectors.

Any suggestions are welcome :slight_smile:

I have had RTL433 running for a couple of days now, and there doesn’t seem to be any sort of “announcement” at fixed intervals to tell if the battery status is OK - so I assume, that the communication only is event based (without the hub).
I have no idea how it works if a hub is connected - if the app can query devices for the battery status. But in this scenario, it is again event-driven communication, meaning that the devices always are in listen-mode, and only transmits something if needed (being a reply to some sort of query or pairing).
The way I “provoked” communication that my RTL433 could intercept, was by doing an alarm-test (pushing the test button on one of the devices for ~6-7 seconds)

Ah, ok, thank you - that explains it:

The smoke detectors are at my cabin, and I am at home, so listening for «unsolicited» transmissions is therefore futile, since its hard to push the button on the smoke detectors when my arm is about 170 km too short. So I’ve spent a couple of days listening for transmissions that are never sent :man_facepalming:

I’ll go at it again when I’m at my cabin again.

Hopefully your RTL433 with the SDR stick is in the cabin as well. Don’t expect the signal to travel 170km :slight_smile:

Haha, good point, but yes, the SDR stick is connected to my cabin HA instance physically located at the cabin.

I run HA OS on an RPi 4 with SSD at my cabin and HA Supervised on Debian 11 on a NUC at home, using Remote Home-Assistant to fetch data from the cabin HA to the home HA. On the cabin HA, I run rtl_433 and rtl_433 mqtt autodiscovery add-ons. As I said, it picks up 433 MHz temperature sensors without problems, so I’m just waiting for a chance to make the Cavius smoke detectors transmit something in order to tune the SDR to the right frequency and pick up the transmissions.

The cabin HA did, by the way, pick up a signal from an Efergy-e2CT transmitter on 869.68 MHz. Presumably from a near-by cabin in which someone has installed such a device to monitor power consumption.

I can’t remember to have seen any heartbeat packages during the RE process.
That said, I didn’t expect (or look for) such packages either. Transmitting at regular intervals surely will shorten the battery-life significantly, without any clear advantages.
Most of these product are sold and used without a dongle, and as far as I can tell, each device are completely indifferent to the state or presence of other devices, so why broadcast it regularly ?

They do, however, start flooding the waves with battery-status messages when the state changes to “battery-low” …

I agree, being silent until there is something to report (alarm or low battery) seems to be the sensible thing to do. :+1:

Hello.
Can anyone share their mqtt template sensor code to make sensors for cavius ​​smoke alarms?

is there any news on this topic? I have installed cavius smoke detectors with hub. Is there someone that can share there config file?

1 Like

Great topic, I will follow with bated breath as our local electrical wholesaler has just started selling these in the UK. Fingers crossed for a HA integration soon.