Choosing the correct rfxcom identity

Configuration
1

I am using an rfxcom device. It receives an event from a doorbell, which can be seen in the logs:

2018-07-29 12:21:13 DEBUG (Thread-2) [homeassistant.components.rfxtrx] Receive RFXCOM event from (Device_id: ab1593 Class: LightingDevice Sub: 0, Pkt_id: 0913001dab1593016570)

The device is added as a binary sensor. Note the identifier is from an older packet, but the device ID ab1593 is visible:

binary_sensor:
    platform: rfxtrx
    devices:
        09130001ab1593016580:
            name: doorbell
            off_delay:
                seconds: 1

When pressed this triggers an automation and message, which works fine:

automation:
  - alias: Send a message when the doorbell rings
    trigger:
      - platform: state
        entity_id: binary_sensor.doorbell
        to: 'on'
    action:
        <Pushbullet action here>

The following device triggered the automation and I can’t see why.

2018-07-29 03:16:23 DEBUG (Thread-2) [homeassistant.components.rfxtrx] Receive RFXCOM event from (Device_id: ac360b Class: LightingDevice Sub: 0, Pkt_id: 09130019ac360b017e40

This isn’t a device I own, it was automatically detected. It’s using the same lighting protocol but has a completely different identifier.

How should I be expressing device IDs in the configuration to avoid this happening?

2

not sure what to say here except disabling auto discovery and commenting out the culprit in the known_devices.yaml and see if that still happens

3

Try to edit the config:

binary_sensor:
platform: rfxtrx
devices:
    09130001ab1593016580:
        name: Unknown device1
        fire_event: false

And maybe also hide it in your customization file

Unknown_device1:
  hidden: true
1 Like
4

I’m not sure this seems like the best solution. Firstly there could be a lot of unknown devices using the lighting4 protocol. as it’s very popular. Adding each one is a lot of unnecessary effort.

Secondly the unknown device is being mistakenly identified as the doorbell. I assume this matching happens in the Home Assistant code, but have not checked yet. It seems the wrong part of the packet is being used as the unique identifier.

5

Then I guess if you don’t want a whole lot of devices being added, then you need to indeed comment out the auto discover option…:wink:

6

This misses the point. I don’t mind if devices are added. But it’s wrong for them to trigger an automation linked to a completely different device.

What if I owned both devices? One is a doorbell, the other is a garage opener? It would not be acceptable for the garage opener to trigger the doorbell in Home Assistant (when they do not interact in real life). That is effectively the problem here.

7

understood. Silly question maybe but have you checked your known_devices.yaml? I’m wondering if somehow you have your doorbell linked to the wrong Device ID in there

1 Like
8

I have auto discover enabled for years and never had any unknown/unwanted devices added after the first 3 weeks of use (start-up period), it takes some time to identify, rename and/or hide all the switches and remote codes but after that you should be fine.
If you keep receiving new unknown/unwanted devices from your neighbors (because they keep changing/expanding there hardware) the only solution is to disabling auto discovery.

But where in your configuration is the 09130019ac360b017e40 mentioned, it should be somewhere :wink:

9

I have checked known_devices.yaml as suggested by lolouk44. I don’t see any of the rfxcom devices in there, only those from wifi discovery. If this is a problem I will look into it.

The unknown device 09130019ac360b017e40 does not appear in my config, only in the logs. The known doorbell only appears in the configuration snippet I posted at the top, where I named it doorbell.

10

My rfxtrx devices all appear in the switches.yaml, not in the known_devices.yaml.
That includes my KAKU doorbell.
But I do have to say that my doorbell transmitter only showed up once and doesn’t show up in the log at all.
I will test what happens if I put it in the binary_sensor.yaml :smiley:

1 Like
11

Worth noting that I’m using vanilla Home Assistant using the Docker image, not any other specific version. I did use lolouk44’s excellent github repository for ideas and inspiration - thanks!

1 Like
12

This just happened again and I had debug logging enabled. Full logs are below:

2018-07-31 20:30:53 DEBUG (Thread-2) [homeassistant.components.rfxtrx] Receive RFXCOM event from (Device_id: 08a562 Class: LightingDevice Sub: 0, Pkt_id: 0913004908a56200f350)
2018-07-31 20:30:53 DEBUG (Thread-2) [homeassistant.components.rfxtrx] rfxtrx: found matching device 08a562 for None
2018-07-31 20:30:53 DEBUG (Thread-2) [homeassistant.components.binary_sensor.rfxtrx] Binary sensor update (Device ID: 08a562 Class: LightingDevice Sub: 0)
2018-07-31 20:30:53 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=binary_sensor.doorbell, old_state=<state binary_sensor.doorbell=off; friendly_name=doorbell @ 2018-07-31T12:50:56.813218+01:00>, new_state=<state binary_sensor.doorbell=on; friendly_name=doorbell @ 2018-07-31T21:30:53.951787+01:00>>
2018-07-31 20:30:53 INFO (MainThread) [homeassistant.components.automation] Executing Send a message when the doorbell rings

This section is interesting:

rfxtrx: found matching device 08a562 for None

This is generated inside get_pt2262_device() (see here) and suggests that get_pt2262_deviceid() is returning None.

This is likely invalid. The device in the config is generating a masked ID of None, so is the device that I don’t own. The comparison of None == None will be true, therefore it assumes they are the same device.

Will file a bug to see if someone with PT2262 knowledge can resolve.

13

Bug report is here: https://github.com/home-assistant/home-assistant/issues/15773

14

Could some of you try this fix: https://github.com/home-assistant/home-assistant/compare/issue_%2315773?expand=1