RFXTRX Changes in 0.113.0 - Migration Process Issues & Light type devices no longer seem supported

[HarmlessSaucer]

The problem

Previously, RFXTRX devices were added to the configuration like this example from a lights.yaml file:

platform: rfxtrx
automatic_add: True
devices:
  0a14000101f20302010080:
    name: Dining Room Light
  0a14000000f20302010080:
    name: Livingroom Light
  0a14000202f20302010080:
    name: Bedroom Light
  0a14000104f20302010080:
    name: "Isabellas Bedroom Light"

This meant that you could name RFXTRX devices in the yaml, which I can understand changing to the UI. However, with the changes to RFXTRX in 0.113.0, the required 'migration', that users have to follow is to:

• Remove the entries in their light/switch/etc sections of their configuration.yaml
• Add the RFX deviceIDs back into configuration.yaml, but under one single RFXTRX heading.
• Then reboot.
• This won't allow naming, so in the UI, the devices just show up as their manufacturer name or similar. Example: "LightwaveRF, Siemens 07f203:2" in integrations, with the actual entityID being: switch.lightwaverf_siemens_07f203_2
• This is unreadable and it's not possible to work out which device is which. So you have to perform a "turn it on and off until you find out which device is which" game! NOT FUN if you have a tonne of devices.
• THEN you can rename the devices in the UI.

The other problem is that this brings in all of the devices as switch.<entity_id>.
Previously you could have RFXTRX lights. Them now only being switches means that obviously you can't have dimming which is a big part of the use case for RFXTRX lights for me.

I tried to add this using device_class: but 'light' isn't a valid option for this:

rfxtrx:
  device: !secret rfxtrx_device
  debug: True
  automatic_add: True
  devices:
    #Lights
    #Dining Room Light
    0a14000101f20302010080:
    device_class: light

Environment

• Home Assistant Core release with the issue: 0.113.0
• Last working Home Assistant Core release (if known): 0.112.4
• Operating environment (OS/Container/Supervised/Core): All. (Supervised in my case)
• Integration causing this issue: RFXTRX
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/rfxtrx/

Problem-relevant configuration.yaml

rfxtrx:
  device: !secret rfxtrx_device
  debug: True
  automatic_add: True
  devices:
    #Lights
    #Dining Room Light
    0a14000101f20302010080:

    #Livingroom Light
    0a14000000f20302010080:

    #Bedroom Light
    0a14000202f20302010080:

Traceback/Error logs

Additional information

I feel that the documentation on: https://www.home-assistant.io/integrations/rfxtrx/ could do with a re-write to reflect the changes in 0.113.0 I'll happily submit some changes for this seperately.

[HarmlessSaucer]

Looks like this might be similar to: https://github.com/home-assistant/core/issues/38077

And may be fixed by using:

devices:
    # Living room main light
    0b1100010078e3360c020f70:
      device_class: light

Will test and close as necessary - might be an indentation issue on my part

[probot-home-assistant[bot]]

rfxtrx documentation rfxtrx source _{^{(message by IssueLinks)}}

[elupus]

Yes, you need to make sure the event contains a dimming command, otherwise we don't understand the device is a light.

Device class doesn't help here. We must know it support dimming. So yes the migration is a bit messy in the case you didn't do this originally. I will update the docs in regards to this.

Naming you can deduce by adding them one by one to config. Or just toggling them from HA.

The integration had been left behind in regards features so it needed (still need) major rework. Sorry about that.

[HarmlessSaucer]

Wasn't fixed by adding the device_class: light to the entity. From reading a forum post on the issue, you can change the last six digits of the id to 020f70

From: https://community.home-assistant.io/t/rfxtrx-lights-are-recognized-as-switches-in-0-113/213419/2?u=harmlesssaucer

Will test this. I assume this is what you refer to when you say the event must show that it supports dimming.

Thanks again.

[elupus]

don't change the last 6 digits. You should only change 01 to 10: 0a14000101f20302 01 0080 -> 0a14000101f20302 10 0080

What the digit should be changed to depend on the device sadly. For ARC sensors it should be changed to 02.

[knutfh]

Yes, you need to make sure the event contains a dimming command, otherwise we don't understand the device is a light.

Does this mean that a plain wall plug that does not support dimming cannot be recognised as a light?

In my case I have had the following device string for years: 0710030e41020150, should I just add something to the end here? Like 0710030e41020150100080?

[elupus]

Yes it does. Those you must use the wrapping light platform for those (thou you can probably set them as dimmable, it will still work the same as before)

https://www.home-assistant.io/integrations/light.switch/

[HarmlessSaucer]

Well this is all a bit of a mess! Bleurgh! I managed to get one of my devices to work by changing the last digits, but not the others. This change really sucks.

[elupus]

That was annoyingly a waveman: So it should be changed from 710030e41020150 should become 710030e41020250

[elupus]

Related to: #38107. @RobBie1221 we are going to need to be able to convert these things from optionflow i think. Will be hard thou :(.

[elupus]

@HarmlessSaucer had a typo above. had prefixed with 0. If you grabbed it that quickly. Please grab the code again.

[RobBie1221]

I'm still a +1 to find out through the underlying library which is a switch an which a dimming command and have an option to change through the UI from switch to dimmer and vice versa. We should reduce as much as possible user input on flipping bits in hex codes.

[RobBie1221]

Will dig into that once the basic options are done

[reaper]

Do someone knows what digit should I change for chacon devices (Rising Sun) ? for the A1, I have this ID 0710060041010000

[elupus]

The 01 at the end should be 02

[reaper]

Hum no it's the digit for the channel. A2 is 0710060041020000, A3 0710060041030000, and B1 0710060042010000

[elupus]

The it's the next byte after that. Sorry I may have been to quick on checking. So 0710060041020000 -> 0710060041020200

[reaper]

I already tried this id, and tried again right now but the device is always detected as a switch...

      # Chacon (RisingSun A,1) use RFXComIdGenerator
      "0710060041010200":
        device_class: light
        fire_event: true
        signal_repetitions: 2

[elupus]

Ah crap. This is a bug in underlying library.

[elupus]

@reaper Oh no. It's not a dimmable switch (or at least not level dimmable). You need to use the light switch platform to convert it: https://www.home-assistant.io/integrations/light.switch/

[reaper]

Oh yes non it's not a dimmable switch. Ok I will use this platform thank you! But I interrogating myself, at the end the device_class should not be used as default to specify the type of the device ? I thought it was a bug and would be corrected in the 0.113.1 but it was not as this issue has been quickly reported.

Anyway thank you for your time!

[elupus]

device_class is only used for binary sensor entity that can get generated for last received remote press.

[reaper]

Ok thank you for the clarification

[philippe-toussaint]

This upgrade to 0.113.0 is a big mess for the RFXCom devices, and there was no warning about that in the UI to update... I have lost all my configuration and scripts and automation. This is not funny at all!

But it seems that I have found (the right ?) way to fix that :

1) declare the devices

rfxtrx:
  device: /dev/ttyUSB0
  automatic_add: true
  devices: 
    0b1100090080acd202xxxxxx:
   etc...

2) Restart HA and find the ID associated to the device(s). They appear as several types! Dunno why ?. Example:

binary_sensor.ac_080acd2_2
sensor.ac_080acd2_2_rssi_numeric
switch.ac_080acd2_2

Note: If I remember well, "ac" here describe the RFX protocol used. I guess that it is the "0b1100090" in the device maker identifier In my case it is a Chacon/DiO device. It will be great if the ID could be specified by the user; it would save time to research it later.

3) declare switch as a light:

light:
  - platform: switch
    name: Lampe bureau
    entity_id: switch.ac_080acd2_2

It now appear in Light card in the UI.

I am a newbie with HA, tell me if what I have done is wrong. And if it is ok, well, use it.

[elupus]

You can rename the entity_id to something a little more understandable once you figured out which is which (from GUI). The whole idea is to get rid of yaml completely. All being possible to do from GUI:

[philippe-toussaint]

You can rename the entity_id to something a little more understandable once you figured out which is which (from GUI). The whole idea is to get rid of yaml completely. All being possible to do from GUI:

Mmmm ok, I understand. Great idea to go whole GUI, especially to make HA more open to everybody (with no IT/computer background) 👍 Thanks @elupus

[PiAir]

I actually read the release notes this time before upgrading, but stil missed the effect of this on my switches and sensors. Glad that it was possible to return to 0.112.4 with a single command. I simply do not have the time to figure out how to get them working again the same way they have done so far. :(

[onlyPotatoes]

Glad that it was possible to return to 0.112.4 with a single command. I simply do not have the time to figure out how to get them working again the same way they have done so far. :(

Thanks, I had to do the same thing, in emergency and for the first time after six months of HA. I also read the release notes before upgrading, but nothing was saying clearly :

⚠️ Your whole Rfxtrx integration will be destroy during that upgrade, you will lost all of your automations or scripts done with your entities. And after you, in emergency, follow the new rule given on the documentation, you will loose all your entities names and have to go "haphazardly" for retrieve them and rebuild every things you have done before.

It's clearly a big mistake, do note that we sure all apreciate your effort done and improvment for the integration, but, for breaking changes like that, things must be explicit and a migration process (because that's the deal if the migration is not managed during the upgrade), must be clearly given on the documentation beforehand, for prevent all users to be lost and potentialy a bit frustrated

[elupus]

That is why it's called a breaking change.

[elupus]

PS. You have lost no automations. You don't need to touch them at all. But yes some more things written under breaking changes would have been good.

The dimmable light change I'm working on mitigating btw.

[peternijssen]

This migration process was a pain in the ass. The documentation wasn't really helpful in this because there was no clear example. Anyway, I migrated all of the devices, one by one, restarting each time.

Just my door triggers no longer work, so I lost several automations;

trigger:
  - platform: event
    event_type: button_pressed
    event_data: {"state": "on", "entity_id": "switch.garage_door"}

Apparently this needs to be changed to:

trigger:
  - platform: event
    event_type: rfxtrx_event
    event_data:
      packet_type: 22
      sub_type: 0
      id_string: "00:90"

But how on earth should I find the packet_type, sub_type and id_string?

Edit; Apparently this was enough;

trigger:
    - platform: state
      entity_id: switch.garage_door
      from: "off"
      to: "on"

[elupus]

@peternijssen if they do switch back to off again, then that is good. If not, id trigger on the binary sensor instead and skip the from: "off"

[MartinHjelmare]

Please don't use this issue to complain about how "bad the release was" and how much it "broke your setup".

Instead please describe how you'd like the integration or the documentation to be improved.

[peternijssen]

Please don't use this issue to complain about how "bad the release was" and how much it "broke your setup".

Instead please describe how you'd like the integration or the documentation to be improved.

A simple old vs new config example.

Automated migration of the names. I had to migrate a device, restart, rename, migrate a device, restart, rename, etc.

[Goudtik]

Automated migration including the names +1!!!!

Op ma 27 jul. 2020 23:45 schreef Peter Nijssen notifications@github.com:

Please don't use this issue to complain about how "bad the release was" and how much it "broke your setup".

Instead please describe how you'd like the integration or the documentation to be improved.

A simple old vs new config example.

Automated migration of the names. I had to migrate a device, restart, rename, migrate a device, restart, rename, etc.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/38191#issuecomment-664654345, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEXLGM42JSZ4NSKY7T4AUODR5XYOPANCNFSM4PHKXL4Q .

[onlyPotatoes]

Please don't use this issue to complain about how "bad the release was" and how much it "broke your setup".

This wasn't my intention, sorry about that (it was late for me)

Instead please describe how you'd like the integration or the documentation to be improved.

As the others says, an automated migration including the names would be awesome If it would be too heavy, a simple migration process explaining what users should do for retrieve their setup

Apart from this, thank you for the hard work done to improve the integration

[bmesuere]

Please don't use this issue to complain about how "bad the release was" and how much it "broke your setup".

Instead please describe how you'd like the integration or the documentation to be improved.

I read about the breaking change but was still surprised by the effects this had. For such a big breaking change, a little more documentation would have helped, eg. which steps to take to fix this instead of just "Configuration of entity name must now be done inside home assistant".

[don66]

Hi, I experience as well issue on getting the NEXA remote control configuration to identify light dimming. As the same remote on signal / button is used for "on" - and start/stop dim for dimmable device (020f).

Anyone have suggestions how to get the device registered with a dimmable light entity?

[RobBie1221]

Could you share your configuration entry you are using for this remote?

[don66]

Well - in previous version I had this config:

Enable RFXtrx device

rfxtrx:
device: /dev/serial/by-id/usb-RFXCOM_RFXtrx433_A128MSSF-if00-port0
debug: True

switch:

• platform: rfxtrx
  automatic_add: True
  devices:
  0b11000a013007da04010f70:
  name: stikk_lys_kjellerstue_reol
  0b110000012e596205010f70:
  name: stikk_lys_stue_vindu
  0b110002012e596208010f70:
  name: stikk_lys_drivhus
  0b11001b013007da06010f70:
  name: bryter_lys_kjellertrapp
  0b11002a012e59620d010f70:
  name: stikk_lys_stueIV1
  0b110012012e596210010f70:
  name: bryter_terassevarmer_stor
  0b110013012e59620f010f70:
  name: bryter_terassevarmer_liten
  0b110001012e59620e010f70:
  name: bryter_fontene
  0b110015012e59620c010f70:
  name: bryter_lys_yttergang

light:

• platform: switch
  name: lys_kjellerstue_reol
  entity_id: switch.stikk_lys_kjellerstue_reol

• platform: switch
  name: lys_stue_vindu
  entity_id: switch.stikk_lys_stue_vindu

• platform: switch
  name: lys_drivhus
  entity_id: switch.stikk_lys_drivhus

• platform: switch
  name: lys_kjellertrapp
  entity_id: switch.bryter_lys_kjellertrapp

• platform: switch
  name: lys_stueIV1
  entity_id: switch.stikk_lys_stueIV1

• platform: switch
  name: lys_yttergang
  entity_id: switch.bryter_lys_yttergang

• platform: rfxtrx
  automatic_add: True
  devices:
  0b110002012e596206000070:
  name: dimlys_spisestue
  0b110003012e596207000070:
  name: dimlys_salongbord
  0b110007013007da01010f60:
  name: dimlys_kjellerstue_venstre
  0b110008013007da02010f70:
  name: dimlys_kjellerstue_hoyre
  0b110009013007da03010f70:
  name: dimlys_kjellerstue_midt
  0b11001a013007da05010f70:
  name: dimlys_kjellerstue_gang
  0b110000019eee520d010f60:
  name: dimlys_2etg_romnord
  0b110000012e596209010f70:
  name: dimlys_inngang
  0b11002d012e59620a010f70:
  name: dimlys_utehjorne
  0b110010012e59620b010f60:
  name: dimlys_carport
  After upgrade to v 0.113.1 I removed the switch/light , and left only this:

  Enable RFXtrx device

  rfxtrx:
  device: /dev/serial/by-id/usb-RFXCOM_RFXtrx433_A128MSSF-if00-port0
  debug: True
  automatic_add: True
  devices:
  0b110008013007da01010f70:

Note - the "devices: 0b110008013007da01010f70:" was entered just for testing

• I pushed remote control for the lights - and it turned up as device - with switch, binary switch and sensor (sensor.ac_13007da_1_rssi_numeric)

[boywiz]

I am trying to get Bryon SX switch to work it is detected and shown in the log but the automation never fires, when i tests the event by entering the information manually the automation works.

from the Log 2020-07-28 23:38:42 DEBUG (Thread-2) [homeassistant.components.rfxtrx] Receive RFXCOM event: {'packet_type': 22, 'sub_type': 0, 'type_string': 'Byron SX', 'id_string': '00:95', 'data': '0716007d00950170', 'values': {'Sound': 1, 'Battery numeric': 0, 'Rssi numeric': 7}} 2020-07-28 23:38:42 DEBUG (MainThread) [homeassistant.components.rfxtrx.sensor] Sensor update (Device ID: 00:95 Class: RFXtrxDevice Sub: 0) 2020-07-28 23:38:42 DEBUG (MainThread) [homeassistant.components.rfxtrx.sensor] Sensor update (Device ID: 00:95 Class: RFXtrxDevice Sub: 0) 2020-07-28 23:38:42 DEBUG (MainThread) [homeassistant.components.rfxtrx.sensor] Sensor update (Device ID: 00:95 Class: RFXtrxDevice Sub: 0) 2020-07-28 23:45:06 DEBUG (Thread-2) [homeassistant.components.rfxtrx] Receive RFXCOM event: {'packet_type': 22, 'sub_type': 0, 'type_string': 'Byron SX', 'id_string': '00:95', 'data': '0716007e00950170', 'values': {'Sound': 1, 'Battery numeric': 0, 'Rssi numeric': 7}} 2020-07-28 23:45:06 DEBUG (MainThread) [homeassistant.components.rfxtrx.sensor] Sensor update (Device ID: 00:95 Class: RFXtrxDevice Sub: 0) 2020-07-28 23:45:06 DEBUG (MainThread) [homeassistant.components.rfxtrx.sensor] Sensor update (Device ID: 00:95 Class: RFXtrxDevice Sub: 0) 2020-07-28 23:45:06 DEBUG (MainThread) [homeassistant.components.rfxtrx.sensor] Sensor update (Device ID: 00:95 Class: RFXtrxDevice Sub: 0)

The values i test against id_string: '00:95' packet_type: 22 sub_type: 0 type_string: 'Byron SX' values: 'Sound': 1

the automation `trigger:

• event_data: id_string: 00:95 packet_type: 22 sub_type: 0 type_string: Byron SX values: Sound: 1 event_type: rfxtrx_event platform: event condition: [] action:
• entity_id: light.back_living_room service: light.turn_on mode: single`

[don66]

[RobBie1221]

@boywiz Please check community forums, this has been asked and answered there, and don't post support questions here unrelated to the issue.

@don66 Try this one:

0b110008013007da01020f70

I flipped a 01 to 02, at the same position you should do this for all switches you have. This changes from switch to dimming command and makes sure a light entity is created.

[boywiz]

@RobBie1221 I asked here because i could not find anything in the forum about it, i tried following the documentation and have been trying for 3 days. Please could you point me to the article in the forum?

many thanks

[elupus]

@boywiz then at least open a new issue about it, where you include old and new config.

[elupus]

Also, i've updated the docs a bit about this: https://www.home-assistant.io/integrations/rfxtrx/#convert-switch-event-to-dimming-event

[RobBie1221]

@boywiz If you think it's an issue, open a new issue. If you need support and you can't find anything in the forums, start a new thread such that people can reply there. If you search for rfxtrx on the forums I made a remark there that you should use state events for these kind of automations.

[boywiz]

@RobBie1221 I have started a new thread but as you said this had been answered and seemed to know I thought if you could provide the link then it would save unneeded tickets being opened.

Thanks

[repiuk]

I'm completely lost in how to solve this in HA. My sensors appear as devices with auto add, that's easy. I have several switches and dimmers (coco old and new / home easy) which I could control from 0.112. The original remotes are lost or broken. The documentation is a complete enigma For instance I have an old device under switch: "0710017544030170": name: amp No idea how this would translate to 0.113

[elupus]

Place the same code under devices in the config. You will get a device for it.