Any example how to get window/door contact sensors into Home Assistant?

[segdy]

While I really love the configurability of rtl433 with mqtt etc I have a real hard time figuring out how to get my DSC contact sensors into HA (using a "best practice approach"). I decided do not want to use the auto configuration script (since my setup won't change much).

The documentation only shows a temperature/humidity sensor.

I am really confused what I should use as mqtt parameter (retain, devices, etc) and how my yaml section would like like.

Since I have dozens of sensors with the same structure, I'd like to have one line to get all of them. The documentation makes use of "+" but doesn't show how the names are dynamically created.

Would anyone be so kind sharing their rtl433 command line and their yaml section showing how the contact sensor is mapped properly into HA?

[HolgerAusB]

Home Assistant (HA) is not dicussed here or any other home automation. But maybe parts of my configuration (rtl > homebridge > Apple HomeKit) can help.

I use a config file at /etc/rtl_433/rtl_433.conf instead of start-parameters and use rtl_433 as server/deamon.

"retain" is in my opinion not useful in this scenario. It means that the mqtt-broker caches the data and as soon a new client subscribe to that topic, it will deliver this (meanwhile maybe OLD) data. While HA should be constantly subscribing, there is no need for retaining/caching this data.

For homebridge it is the easiest way to use "devices", because you get seperate topics for each data field. With "event" you get a single JSON-datablock each time your rtl receives data. "states" brings you statistics every x minutes (see report_meta stats).

But you can combine multiple mqtt-outputs by seperating with comma or set multiple output-lines:

output mqtt://192.168.xx.xx:1883,devices=rtl[/protocol:0][/id:0][/model:unknown],events=rtl/Pi01-event,states=rtl/Pi01-states

as command line it should be:
-F "mqtt://192.168.xx.xx:1883,devices=rtl[/protocol:0][/id:0][/model:unknown],events=rtl/Pi01-event,states=rtl/Pi01-states"

Here is the output of mosquitto_sub for a weather sensor. the first 8 lines are the 'devices'-lines and the last one the 'events'-line

2022-09-23T09:32:36+0200 rtl/20/55/Ambientweather-F007TH/time 2022-09-23 09:32:35
2022-09-23T09:32:36+0200 rtl/20/55/Ambientweather-F007TH/protocol 20
2022-09-23T09:32:36+0200 rtl/20/55/Ambientweather-F007TH/id 55
2022-09-23T09:32:36+0200 rtl/20/55/Ambientweather-F007TH/channel 2
2022-09-23T09:32:36+0200 rtl/20/55/Ambientweather-F007TH/battery_ok 1
2022-09-23T09:32:36+0200 rtl/20/55/Ambientweather-F007TH/temperature_C 13.72222
2022-09-23T09:32:36+0200 rtl/20/55/Ambientweather-F007TH/humidity 72
2022-09-23T09:32:36+0200 rtl/20/55/Ambientweather-F007TH/mic CRC
2022-09-23T09:32:36+0200 rtl/Pi01-event {"time":"2022-09-23 09:32:35","protocol":20,"model":"Ambientweather-F007TH","id":55,"channel":2,"battery_ok":1,"temperature_C":13.72222,"humidity":72,"mic":"CRC"}

If rtl_433 knows your contact sensor there should be a topic field kinda opened or closed with true/false or 1/0 which you can subscribe to with HA.

[segdy]

Much appreciated, thanks!

"retain" is in my opinion not useful in this scenario. It means that the mqtt-broker caches the data and as soon a new client subscribe to that topic, it will deliver this (meanwhile maybe OLD) data. While HA should be constantly subscribing, there is no need for retaining/caching this data.

Hmm, maybe I understand this wrong. Say, my window sensors only send updates when opening/closing a window. Say I open a window once a month. If I restart Home Assistant, it would not know the state until I open/close the window. With retain=1, MQTT broker would have cached the previous result and I get the latest state. Is this thinking wrong?

For homebridge it is the easiest way to use "devices", because you get seperate topics for each data field.

Thanks for the explanation. Seems this is default then. I do not give any argument to mqtt but I still get rtl_433/hostname/... which I read out.

With "event" you get a single JSON-datablock each time your rtl receives data. "states" brings you statistics every x minutes (see report_meta stats).

I know this is again more HA (possibly homebridge?) specific; could these be of any use for HA? Or is "devices" everything I should make use of?

Do you use any -M options? Especially I don't understand what -M newmodel does and I find this frequently.

By the way, the documentation suggests to use -Y autolevel -Y squelch which you don't use, it seems? I feel I get better results without but maybe that's subjective.

[HolgerAusB]

'retain' saves the last state physically. So not only when HA restarts it reveives the retained data. Also when restarting your mqtt broker. So when the state changes while broker is offline, you might get old/wrong data.

Did you ever got data from your sensor? I don't have 433mHz contact or motion sensors. Does it really only send data when state changes or does it repeat its state every x seconds/minutes? If so, you don't need retain and should not use it.

BTW: If you have ever used retain on a topic and don't want to have this any more, you have to remove this from cache by hand - or use a different topic-name/prefix.

I am using -M just with protocol aka report_meta protocol in config-file. No -Y here.

I am using rtl for weather sensors with standard protocols and two doorbells with flex device (-X)

[rct]

Would anyone be so kind sharing their rtl433 command line and their yaml section showing how the contact sensor is mapped properly into HA?

Here's the YAML for the main open/close sensor for one of my DSC sensors:

homeassistant/binary_sensor/Main-Entrance-DSC/Main-Entrance-DSC-closed/config {
  "device_class": "door",
  "force_update": "true",
  "payload_on": "0",
  "payload_off": "1",
  "name": "Main Entrance Door",
  "state_topic": "rtl_433/+/devices/DSC-Security/2449999/closed",
  "unique_id": "Main-Entrance-DSC-closed",
  "device": {
    "identifiers": "Main-Entrance-DSC-Sensor",
    "name": "Main Entrance Door Security Sensor",
    "model": "DSC Security WS4945",
    "manufacturer": "rtl_433"
  }
}

Note: I've been using that definition for a year or two, so it may not reflect the current state of Hass features, like trigger based sensors. Also I'm not sure whether force_update still makes sense to use for these or not.

I decided do not want to use the auto configuration script (since my setup won't change much).

You don't need to run autodiscovery all the time -- it actually isn't recommended. I believe I put notes in the README about running the script and having it post to a different topic. so you see what it creates and use it as a template.

I do recommend hand editing the YAML config so you can edit the names, device classes. (Door vs. window vs. smoke vs ...), and even model.

Hmm, maybe I understand this wrong. Say, my window sensors only send updates when opening/closing a window. Say I open a window once a month. If I restart Home Assistant, it would not know the state until I open/close the window. With retain=1, MQTT broker would have cached the previous result and I get the latest state. Is this thinking wrong?

First, before we get into retain, the piece you are missing is that the DSC (and other security sensors), resend their current state periodically as a heartbeat -- both the monitor that the device is still alive and can be received and to refresh state in case any messages were lost. There is an event field that will be false on heartbeats. Most DSC sensors in this family send heartbeats around once per hour. (There are a few models of sensors that send heartbeats only every 72 - 84 minutes based on my observations. These are made by another company for DSC.)

Your understanding of retain is correct, when connecting/subscribing to the MQTT broker, with retain off, you won't get anything from MQTT until there is another update. With retain on, when you connect/subscribe, you will get the current state of those topics from the MQTT broker. So in this case retain is desirable, but there are drawbacks.

The primary drawback with retain on is that everything device the rtl_433 hears will have a permanent set of topics created under rtl_433/+/devices/*. Every false positive you receive will get created there. So you will periodically want to clean that out. I don't know if anyone has written a script to do that yet.

(Note: The above is the primary reason why many don't recommend e autodiscovery script full-time, you'll have to clean up falsely created sensors in Home Assistant too.)

One alternative would be to use a custom rtl_433 -> MQTT bridge, and in the bridge set retain based on some criteria like model, known devices, etc.

---

Just curious, do you also have a DSC panel? If so, have you integrated it into Home Assistant?

---

Finally there is more active discussion of Home Assistant configuration for rtl_433 over on the community forum:

https://community.home-assistant.io/t/home-assistant-add-on-rtl-433-with-mqtt-auto-discovery/260665/244

[segdy]

Here's the YAML for the main open/close sensor for one of my DSC sensors:

Amazing, thank you so much!! It's also DSC sensors for me

Sorry if this is trivial, but is this code an alternative YAML syntax?

May I also ask some followups?

"unique_id": "Main-Entrance-DSC-closed",

Is there a specific reason you add "unique_id" ?
The name of the entity should be unique already no?

"device": {
"identifiers": "Main-Entrance-DSC-Sensor",
"name": "Main Entrance Door Security Sensor",
"model": "DSC Security WS4945",
"manufacturer": "rtl_433"
}

Do you know what this does, exactly?
I actually wanted to create a "Device" which consists of multiple entities but I was not able to do so. I don't really understand what the "device" array is for or how it works.

Since each device has "closed", "battery_ok" and "tamper" I ideally would have one device that exposes all three as entities. Do you know if this is possible?

By the way, are you using the "event" property in any way? (event=1 when opened/closed and 0 when they just send a heart beat, as explained by you)

Also I'm not sure whether force_update still makes sense to use for these or not.

So I don't really understand the specifics but I did not have it before and enabled it today and I think it is required:

• Without it, even if my sensors send a heartbeat and HA received the MQTT message, the "Last Updated" property of the entity would not change. This is bad because I add them as secondary info to make sure the information showed is up to date.
• With it, this property updates properly

By the way, I also ended up including:

expire_after: 43200

Most DSC sensors in this family send heartbeats around once per hour.
[...]

Indeed, according to my observation today, they are updated approximately once an hour
That's great! So I removed retain=1 (and deleted the retained messages to start fresh)

Just curious, do you also have a DSC panel? If so, have you integrated it into Home Assistant?

No. It is an ADT security system that previous owners left. I can check the panel if you want but it's turned off and I don't use it. Plan to replace with a wall mounted tablet at some point ;-) The sensors are DSC EV-EW4975

Slightly OT: Did you play with the magnets? On one window, the magnetic contact is missing. I tried to use one of my neodym magnets but it does not seem to work well. Is there an easy way to get replacement?

Finally there is more active discussion of Home Assistant configuration for rtl_433 over on the community forum:
https://community.home-assistant.io/t/home-assistant-add-on-rtl-433-with-mqtt-auto-discovery/260665/244

Thanks, I'll read through this thread.

[rct]

Here's the YAML for the main open/close sensor for one of my DSC sensors:

Sorry if this is trivial, but is this code an alternative YAML syntax?

Ugh, my mistake sorry, that is actually JSON because I've been keeping all of the MQTT configs in MQTT, so to Home Assistant they are autodiscovered. For what it is worth, I edit these using the MQTT Explorer client/GUI, which is really useful for any MQTT work. I also set retain when editing/publishing them from MQTT Explorer. When I run the auto-discovery script, I have it configured to publish to a different topic name hass_433/# and then I copy the definitions that I want Home Assistant to actual use over and publish them to homeassistant/...

Is there a specific reason you add "unique_id" ?
The name of the entity should be unique already no?

Adding unique_id lets you do some amount of editing from Home Assistant's UI. Unique ID will be used for the entity name, and name will be used for the friendly name.

Do you know what this does, exactly?
I actually wanted to create a "Device" which consists of multiple entities but I was not able to do so. I don't really understand what the "device" array is for or how it works.

That's what this does, it ties the entities together into a device. You'll get a device page where you'll be able to see the entities and also a link to MQTT info for the device.

Since each device has "closed", "battery_ok" and "tamper" I ideally would have one device that exposes all three as entities. Do you know if this is possible?

Yes. exactly. They will be individual binary sensor entities, mapped to one device.

By the way, are you using the "event" property in any way? (event=1 when opened/closed and 0 when they just send a heart beat, as explained by you)

Not in Home Assistant. My automations all just look for the state changes on the closed and tamper sensors. So in Hass, all I care is that it changed.

---

I asked about the DSC panel (ADT resold them at some point) because I was wondering if you had connected it to Home Assistant. I have the DSC sensors because I have a DSC panel. I'm using an Envisalink to connect the panel to Home Assistant. The DSC panel connects to central station monitoring which makes my home owner's insurance company happy.

I tried to use one of my neodym magnets but it does not seem to work well. Is there an easy way to get replacement?

I don't think there is anything special about those magnets. If you open the sensor, you'll see there is just a reed switch inside. Maybe that sensor is just dead?

The sensors are DSC EV-EW4975

Those are the small/slimline sensors. They are actually made by a different company. After there has been activity, those devices send a different bit on the next heartbeat. You can use that to determine if the last message you saw was not an event, you missed an event, possibly because it was being interfered with.

[segdy]

Ugh, my mistake sorry, that is actually JSON because I've been keeping all of the MQTT configs in MQTT, so to Home Assistant they are autodiscovered. For what it is worth, I edit these using the MQTT Explorer client/GUI, which is really useful for any MQTT work. I also set retain when editing/publishing them from MQTT Explorer. When I run the auto-discovery script, I have it configured to publish to a different topic name hass_433/# and then I copy the definitions that I want Home Assistant to actual use over and publish them to homeassistant/...

This is a very intriguing approach! Then I wouldn't need to restart HASS if I change config. I think I'll move towards this approach.
The retained messages here are only used because you use the MQTT broker config storage?
What if I change my bash script to publish (one time, if config changes) to mqtt instead of writing a yaml file; could I remove the retained attribute then?

Adding unique_id lets you do some amount of editing from Home Assistant's UI. Unique ID will be used for the entity name, and name will be used for the friendly name.

I think my question was the difference to object_id (Used instead of name for automatic generation of entity_id)

I am setting object_id. Wondering if I also should use unique_id instead of even both?

Yes. exactly. They will be individual binary sensor entities, mapped to one device.

Must have done something wrong then. I'll try this again

[...] if you had connected it to Home Assistant [...]
which makes my home owner's insurance company happy.

:-) I got SimpliSafe for free but fortunately they don't require me to sign up for it. I rather build this myself.

Sorry, did not connect the old panel to HA; actually not even sure how to turn it on...

---

EDIT: Maybe the devices do not work for me because data comes from a YAML in my case?

Only works through MQTT discovery and when unique_id is set.