Release 0.113 and RFXtrx

BlintWave · July 24, 2020, 11:17am

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.

HarmlessSaucer · July 25, 2020, 7:26am

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

HarmlessSaucer · July 25, 2020, 7:53am

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.

HarmlessSaucer · July 25, 2020, 7:56am

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.

CreatoX · July 25, 2020, 7:59am

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.

Ralf · July 25, 2020, 8:53am

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

BlintWave · July 25, 2020, 9:22am

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…

whitedogbe · July 25, 2020, 11:22am

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.

Ralf · July 25, 2020, 3:51pm

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

fversteegen · July 26, 2020, 5:48am

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

Moreincubus · July 26, 2020, 8:04pm

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?

BlintWave · July 26, 2020, 9:43pm

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…

Ralf · July 27, 2020, 9:08am

I am one step ahead: my entiies are now renamed.

I did this by the following procedure (please excuse me if i do not take the correct english wordings, using german).

Open Settings -> Integrations
Choose RFXTRX integration -> xxx
Click on a device, then click on the gear upper right
in the appearing dialogue, change the name of the device, optionally select an area
After clicking refresh, confirm to also replace the new name to all associated entities IDs.

Hope it helps.

RobBie1221 · July 27, 2020, 9:27am

Could you share the ID you are using for this in the configuration?

Ralf · July 27, 2020, 9:41am

Sure, following my enzry in the configuartion, yaml file:

rfxtrx:
  automatic_add: false
  device: '/dev/serial/by-id/usb-RFXCOM_RFXtrx433_A1WJDDPI-if00-port0'
  devices:
    0b110053009f566604020f70: 
      device_class: light
    0b110049009f566602010f70:
      device_class: opening    
    0b11004c009f566603010f70: 
      device_class: opening    
    0b110055009f566605010f70:
      device_class: battery_charging    
    0b110059009f566606020f70: 
      device_class: power
    0b110080009f566607010f70:  
        device_class: battery_charging
    0710011148010160:           
      device_class: power    
    0a520701350e00fe300169:     
    0710010943030150:         
      device_class: door
    0710010c41040160:         
      device_class: door
    0710010f42030150: 
      device_class: door

It’s a bit messy that all have IDs for rfxtrx communication, thgen show up e.g. (last one) binary_sensor.arc_b3
After renaming, it gets a bit better to work with in the UI. Note for renaming: do not use special letters like german ‘ü’, these will result in next mess (but this is less problem for me).

I tried to modify the last 6 digits of the ID as i read in the rfxtrx docs (renaming to end with 010f70) but unfortunately it does nothing. Also setting a devcie_class did not help.
All still detected as binary_Sensors, resulting i have no switch on/off possibility in the UI.
Will try to do a ‘dirty’ workaround with helpers and automation.

Hopefully it will be fixed in the next updates.
Anyone already did a feature or bug request?

Ralf · July 27, 2020, 9:50am

EDIT: just noticed that my switches now seem to have an on/off switch in the UI.
Don’t know why it is happening now. Maybe Update to 0.113.1 fixed this? Unsure…
Maybe a combination of what i did (editing the last 6 digit numbers, device_class) result… Unsure

However, the enties are still shown as e.g. switch.ac_09f5666_8 in the developer tools list, so not what i would say it is renamed. But i also did a friendly_name on this so i am able to handle this.

My personal opinion:
I really appreciate all work of all developers but this spoecial case did lots of work for me but didn’t see what is better than before now, it even got worse. Devcies of these types are often used, for me it was my first devices i put into HA. Hard times for startes currently.
Sorry to say that but should be constructive not destructive!

RobBie1221 · July 27, 2020, 10:00am

The platform setup that was used on this integration is deprecated by architecture decision.

github.com

home-assistant/architecture/blob/4049161a540c3af87921f92e6bb30c369f74eebf/adr/0007-integration-config-yaml-structure.md

# 7. Config YAML structure for integrations

Date: 2020-04-05

## Status

Accepted

---

## Context

There are currently many different ways of structuring an integration and its config in Home Assistant. We allow config YAML, either under the integration key or under platform keys with the integration name. We allow a config flow with configuration entered via the GUI, stored in config entries. We allow importing config YAML to a config entry via config flow.

This ADR focuses on the configuration YAML structure and its use in integrations.

The many options for configuration impact how the integration is structured and what Home Assistant backend APIs are used.

1. Integrations that only have a single platform, place the configuration under a platform key and use `async_setup_platform` to set up the platform.
2. Integrations that have multiple platforms, sometimes centralize the configuration to the integration domain name key and load platforms via `discovery.async_load_platform`, which in turn calls `async_setup_platform`.

This file has been truncated. show original

It can’t be denied that it breaks things and nobody likes this, but it’s the only way to move forward and allow this integration to innovate.

Ralf · July 27, 2020, 10:53am

@ RobBie1221 Thanks for making that more clear, no i can understand this better.
Fully agree that moving forward may break something.
Maybe you have more detailed information how all affected may proceed?

To summarize, i have:

editied the last 4 digits id and added a device_class.
renamed the entity and added a friendly name by Ui (also possible via customize.yaml)
Editied my UI and automations to work again.
Details see posts above.

Hope it helps others running into this problems, too.

RobBie1221 · July 27, 2020, 10:58am

It may be good to comment that this integration only partially moved to the UI. Through UI it will be possible to add devices or change options without requiring a restart of Home Assistant. This is work in progress, but perhaps this makes it easier to merge (start in yaml with no devices and add them one by one through the UI instead of having a long list and finding out which device is what).

BlintWave · July 27, 2020, 11:38am

Personally I expirience problems with only 1 doorbell switch which I could not get to work with this new update, hence I reverted back to 0.112.4. I did read the new rfx doc but still I could not get it to work.

Anyway I know moving forward could break things, especially moving from yaml to ui. But hey…if it aint broke dont fix it!