Unfortunately I had to reverse release 0.113. I am back on 0.112.4 because after the update I suddenly lost all my smoke detectors, motion sensors and switches that work via the RFXcom. And with that also a large part of my automations. I had read the ‘breaking changes’ that an adjustment had been made for the RFXcom and therefore I had removed the integration from my configuration.yaml.
I also see the RFXcom at the integrations but without devices.
Is this a bug that is going to be solved or should I try to log on all my smoke detectors, motion sensors and switches one by one once again?
Or is there another (simple) solution?
1 Like
I had to also revert - I have a lot of LightwaveRF mood switches, with the ‘name:’ field set, so I end up with switch.mood_switch_1 on 0.112.x.
After the upgrade and modifying my configuration, all the devices seem to have a change in name (as ‘name:’ doesn’t appear to be a listed option, on the rfx documentation page) so I end up with switch.lightwaverf_34hj3hjk3 or similar.
I just don’t have the time or desire at the moment to go find out which switch is switch, then modify everything.
EDIT: The post below has examples of how your configuration needs to change:
If you removed all rfxrtx entries, this is why they’re empty in integrations. If you modify your configuration inline with the above, or the RFX help page:
…you should then see entries…but all their entity ID names are going to change, which is hugely annoying.
1 Like
I did not remove all of my entries. That’s just the point. I only removed
#rfxtrx:
# device: /dev/ttyUSB1
I have the same problem sort of… All the ID names changed since you cannot specify a name within the config file anymore, you actually need to do this within the front end 1 by 1 which is stupid and more time consuming. Secondly my kaku doorbell aint working anymore, before it was setup up as an binary sensor with a fire_event setup. Or I am missing something from the rfx docs or there is a bug. Anyway I think about reverting back to 0.112.
p.s. why did they make a breaking change anyway, from my view everything was working fine as always till now…
1 Like
I also experienced some issues with this. Got some Gen1 LightwaveRF devices.
I removed their entries in my separate configs and added them to the rfx config, but it kinda sucks that the naming is lost and you just have a few characters to go off to try and work out what is what via the UI.
Took me ages to go through all the devices turning them on and off to work out which one was which 
Also, unless I’m missing something, my rfxtrx lights now longer have the ability to have their dimming level set? Maybe I have to set them as a “light” type or something? Anyone else experience this?
1 Like
Yep - think I’ll be staying on 0.112 for the foreseeable future. It works, does all that I need…happy with that 
My understanding, for the brief time I had a play before rolling back, you would need to have:
rfxtrx:
device: /dev/ttyUSB1
devices:
# Siemens/LightwaveRF Shutter
0b1100ce3213c7f210010f70:
# RFY Shutter
071a00000a000101:
# Light 1
0b11000f10e9e5660b010f70:
# Light TV
0b1100100f29e5660c010f70:
# Binary Sensor
0913000022670e013b70:
Remove all of the light, switch, binary_sensor lines with ‘platform: rfxtrx’ and put them under the above heading instead, minus any ‘name:’ specifications you have. The entity ID’s in Home Assistant will then change to something like switch.lightwave_rf_34324hjkh
Not a ‘game’ I think I want to play… will stay on 0.112 I think
At this point, like I said I cannot get my coco doorbell to work anymore. I must be doing something wrong I think hopefully someone can help…
Before 0.113 I had the following configured…
switch:
- platform: rfxtrx
devices:
"0b110000018b5aca01040f70":
name: Doorbell
fire_event: True
With an automation as follows…
- id: ‘1531251962240’
alias: Doorbell Notification
trigger:
- event_data:
entity_id: switch.doorbell
event_type: button_pressed
platform: event
condition:
And everything worked fine till now. I tried some option as changed the ID name in the automation script but that did not worked. Secondly running on 0.113 my doorbell not only shows itself as a switch but also as a binary sensor within the entitities front-end.
So Im lost here, looking on the rfx docs page really does not help me at all or like I said Im missing something…
P.s. And yes I already changed my configuration file according to the new update.
–Update-- Reverted back to 0.112.4 everything is working again, I’ll wait when I got more time for testing this out cuz it’s annoying.
2 Likes
Yea, so I’ve managed to get all my devices back into HomeAssistant by using the config:
rfxtrx:
device: !secret rfxtrx_device
debug: True
automatic_add: True
devices:
#Lights
#Dining Room Light
0a14000101f20302010080:
#Livingroom Light
0a14000000f20302010080:
#Bedroom Light
0a14000202f20302010080:
However, the problem is they all show as "switch.<entity_id>" and I can’t seem to change them to be a light instead. If I add the device_class: light I get an error in the config checker so obviously that isn’t right.
Anyone got any ideas? Without being lights, you can’t dim them 
FYI: I submitted an issue on GitHub for this:
As I believe at least the fact the devices are now brought in as a switch rather than a light is a big enough issue.
2 Likes
Oh, interesting. Didn’t find this earlier, but just found it now:
In case this helps anyone, someone else posted about this and looks like they posted on GitHub too.
1 Like
Same problem.
Reconfigured the rfxtrx devices so they are available as integration. But they all show up as switches and not as (dimmable!) lights.
Also, adding older Klik-aan-Klik-uit (kaku) receivers, they got a 16 digets RF code, the rfxtrx module gives and error:
For example adding:
rfxtrx:
device: /dev/ttyUSB0
devices:
# kaku switch garden lights
0710010042010170:
2020-07-25 07:46:01 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry RFXTRX for rfxtrx
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/config_entries.py”, line 219, in async_setup
result = await component.async_setup_entry( # type: ignore
File “/usr/src/homeassistant/homeassistant/components/rfxtrx/init.py”, line 160, in async_setup_entry
await hass.async_add_executor_job(setup_internal, hass, entry.data)
File “/usr/local/lib/python3.8/concurrent/futures/thread.py”, line 57, in run
result = self.fn(*self.args, **self.kwargs)
File “/usr/src/homeassistant/homeassistant/components/rfxtrx/init.py”, line 179, in setup_internal
event.device, data_bits=event_config.get(CONF_DATA_BITS)
AttributeError: ‘NoneType’ object has no attribute ‘device’
Using the newer devices (24 digits code), it is starting…
rfxtrx:
device: /dev/ttyUSB0
devices:
# kaku switch bedroom
0b110000013bb2920b000060:
… but then it is a switch in stead of a light.
Previously we could use this:
light:
- platform: rfxtrx
automatic_add: false
devices:
"0b110000013bb2920b000060":
name: bedroom
This does not seems to work anymore.
Please help us get our RFX devices working again the way they where. Thanks.
2 Likes
Hello,
also tried to change the ID, but did not work.
I cannot use my switches and blinds, they only are shown as binary_sensors 
I also please request help to get them working.
Thanks in advance
Thats funny, my case running 0.113 I did not have to change the ID at all. All my devices are seen by HA but every switch is also seen as a binary sensor as well, so I got both.
To me it seems something went very wrong during beta test as I see more people running into problems. If you would ask me I think they better revert back to the old rfxcom way of things. The new update broke more then it actually fixes…
2 Likes
Sorry, I totally don’t understand this new type of configuration. Can someone post an example of how you define a device as being a cover? I got this far, which doesn’t work:
rfxtrx:
device: /dev/serial/by-id/usb-RFXCOM_RFXtrx433XL_ABCD123-if00-port0
automatic_add: false
devices:
071a000001010101: # RFY
device_class: cover
name: Curtain Left
signal_repetitions: 2
From what I read above, the name is no longer supported and there is no “cover” device_class?
EDIT:
Figured it out, just add the devices and you can change the rest in the GUI. Took me 10 minutes to fix rename everything and fix automations and HomeKit.
For examples, see the RFX doc
All must be in the configuration.yaml section now.
As you mentioned, the name flag is not available anymore, this can be done in the UI (however, mine seem not to be accepted).
same for the device_class: my Intertechno cover switched are discovered as binary_sensors. Tried to change the ID but didiN#t help. Don’t see any switched in the Lovelace UI (but there are some in the Integrations section).
Very weird now and a step back to what we had before changed in 0.113.0.
Think i will go back until this is solved.
/ Ralf
1 Like
Am having the same challenges; getting the devices over to 0.113 is just the first hurdle, but getting them renamed is a much bigger problem. And after adding and renaming I also need to check my automations and scripts again. With 100+ devices (out of which around 30 are rfxtrx) this process will take a few hours
I have the same issue.
I found this:
But i dont know how to find out the information for my doorbell:
packet_type: sub_type: id_string:I guess id_string is the device ID?
Cant remember for sure…has been some years now. But I believe I used rfx manager on windows to find some string number and used a linux script to convert it into an ID number I think.
Will get back to you if I know some more about it or perhaps someone knows an easier way to do this now.
But running on 0.113 my coco (klikaanklikuit) doorbell is not working anymore. For now im sticking with 0.112.4 till someone manage to make rfxcom working as it should be…