Release 0.113 and RFXtrx

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!

RobBie1221 · July 27, 2020, 12:33pm

You are using the fire_event but the logic around this has changed (it does not fire with entity id anymore). I think in your case you can just make your automation against the state of the entity. You should use the binary sensor for this because it gets a state event fired even when state doesn’t change.

Mark5 · July 27, 2020, 1:58pm

Well thank you ! You just solved my doorbell problem too.

FWIW, here’s my automation for a “select plus” doorbell.

- id: ding-dong
  alias: Coup de sonnette
  trigger:
  - entity_id: sensor.select_plus_00_de_sound
    platform: state
  action:
  - data:
      message: Quelqu'un sonne à la porte !
      title: Ding Dong !
    service: notify.all_iphones

Yeah, I know, everything is in french. But it works.

RobBie1221 · July 27, 2020, 2:21pm

Could you try the following? (I flipped a bit from 0x00 to 0x02). This is a bit ugly, multiple issues have been reported (see issues in the github repo) and it is being picked up.

rfxtrx:
  device: /dev/ttyUSB0
  devices:
    # kaku switch bedroom
    0b110000013bb2920b020060:

BlintWave · July 27, 2020, 4:30pm

I already tried that automation state with on off state, both the switch ID as well as the binary sensor…it just wont work or something else i’m doing wrong

Moreincubus · July 27, 2020, 6:53pm

Thanks! that fixed it for me… how did you find that out?

RobBie1221 · July 28, 2020, 7:52am

There is a subtle change in 0.113 that was I think not mentioned explicitly in the docs/release notes. If you open all changes you’ll see an item but you really have to look for it.

The fire_event has been moved to device level, but I think in most cases the fire_event is not required anymore. The sensor and binary sensor have a new property set internally such that always state events are fired when data is received, even when the state doesn’t change. This is particularly useful for devices which only report “on” or a “chime”, but always the same.

Flodu31 · July 28, 2020, 9:17am

Hi all,

Thanks for these great information.
I updated everything.
Only one point is missing here. I created groups before, like that:

  - platform: group
    name: Tous les volets
    entities:
      - cover.volet_bureau
      - cover.volet_chambre_parents
      - cover.volet_chambre_luke
      - cover.volet_chambre_telio
      - cover.volet_salle_de_jeu
      - cover.volet_salon_jardin
      - cover.volet_salon_route
      - cover.volet_buanderie
      - cover.volet_cuisine

How can I do a group now with the following?

rfxtrx:
  automatic_add: false
  device: /dev/ttyUSB0
  devices:
    # Volet salon route
    071a000000000301:
    # Volet salon jardin
    071a0000040D0E01:

Thanks in advance.
Florent

EDIT:
I adapted the code with the new cover id:

cover:
  - platform: group
    name: Tous les volets
    entities:
      - cover.rfy_000000_1
      - cover.rfy_0a060c_1
      - cover.rfy_000004_1
      - cover.rfy_080a08_1
      - cover.rfy_000006_1
      - cover.rfy_000001_1
      - cover.rfy_000005_1
      - cover.rfy_040d0e_1
      - cover.rfy_000003_1

RobBie1221 · July 28, 2020, 9:50am

The entities got new names like cover.rfy_000000_1. If you change through the UI these names to the “old” names you had, you don’t have to change the group in your configuration.yaml

mccubix · July 29, 2020, 9:44am

Hi!
How do I revert to 0.112?
I have the same problem…

lolouk44 · July 29, 2020, 10:14am

Same here. Would have been nice to at the very least leave the name: option to allow for manual naming at device level, instead of now having to hunt for some id and rename all related entities.
I’m normally up for changes, including breaking ones if it makes sense, but this one is a real killer and doesn’t seem to have been thought through that much

Mark5 · July 29, 2020, 11:10am

I just followed RobBie1221 advice.

lolouk44 · July 29, 2020, 11:57am

And done…
Thank god I only had 79 entities to manually update…