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 
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 
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
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. 
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?
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.
Do you have this fully working in your HA? Looking for a way to catch an alarm and trigger some automation, but i can not even find a way to find all the detectors to add them…
MQTT auto discovery plugin seems to have seen one sensor during a hub-initiated test, but it also skips “net_id” and “message” part that the sensor sends.
During development I had it working in my lab, but I handwrote each detector as an mqtt sensor in HA.
I’m not sure if MQTT discovery would work, since it requires to follow a certain schema (MQTT - Home Assistant)
AFAIK rtl_433 doesn’t have support for this format out of the box.
Maybe @uphillbattle could shed some light on that?
The intention was (and still is) to write a HA integration for Cavius.
Unfortunately life happend, so I can’t give any dates or promises.
I haven’t investigated the issue further…
It is true that rtl_433 doesn’t by itself publish mqtt messages that can be auto-discovered by HA, but there is an add-on that should do it, here:
I have no practical experience with that add-on, but it does sound promising.
My experience with the Cavius detectors is, however, that they mostly keep silent (unless the alarm goes off), so there’s not much in the way of mqtt messages anyway.
Thanks.
I am using this, and it does see the sensor, but it does not understand the most important parts of the data - it picks up battery only.
If i press each one detector 5 sec, it will test, and i can collect all id’s for manual setup. I just have to wrap my head around mqtt and how/where to tell HA to use it (the sensor)
Thanks,
Do you have an example of a sensor config, and where you put it? I struggle with knowing how to write the config and where to actually put it.
I did feel openhab was a lot of moving parts for simple things, but i am not suer how i feel about HA yet 