rfxtrx switches are shown as a switch as well as a binary sensor in the ‘old style’ interface. See screen dump where the binary sensor is not dedicated to a group and showing in the top section. The switch is in a group shown lower and outside the screen dump
Is this by design?
The state of a device does not match what is displayed as a binary sensor compared to the switch. In my case the binary sensor HKAB1_3 shows ‘On’ where the switch (lower, not in the screen dump) state is ‘Off’.
Is this a bug?
There are a bunch of sensors that indicate the receive dBm for each rfxtrx device, but for me they are not of use. What is the best way to hide these without showing them in a dedicated group (which can’t be hidden to my knowledge).
Thanks for your support
Regards,
OWK
My Home Assistant:
Running on Intel NUC with release 114.3
Thanks. I’m still grasping what you consider to be an issue. Let me explain a few things and perhaps you can comment or elaborate.
Since 0.113, platform setup has been removed (it’s a home assistant architecture decision to get rid of platform setup). Downside is that instead of you defining what platform to use (e.g. binary_sensor or switch), the integration needs to detect what platforms could be necessary. Especially with rfxtrx this is a hard job because there is no real standard and manufacturers use same identifiers for all kind of different devices. For example, your codes starting with 0b1100 could be remotes which would make sense to have as switch, they could also be doorbells which make sense to have as binary_sensor. The integration creates entities that cover them all. Perhaps there are a few too much for your use, you could go through the UI to Integrations and select the devices on the rfxtrx card. Select a device and you can disable entities you don’t need.
As for the dbi, if you only use HA to send out commands, this value never gets set. When a physical device reports with the ID code, it sends out things like RSSI and battery, but it needs to receive something to set those entities. If you only use certain codes from HA and they are not linked to a physical remote, you could disable them.
In my set-up: a binary sensor is installed at a door or a window and sends a code to indicate open or closed. A switch is located behind a real switch in the wall and sends a code, or sits in a wall socket and receives a code to operate. A sensor sends a temperature/humidity. So I hope we are now on the same page for functions supplied by rfxtrx (all KaKu/CoCo btw) in my set-up.
So where before the manual configuration of the device into a file (with a file name like sensors.yaml or switches.yaml) dictated the device type, it now needs to be detected from a received code. Which seems to be difficult due to the lack of standardization.
If I open a device in integration, each shows 3 entities, and if I don’t do anything those 3 will show up in the frontend interface. That wil show a binary sensor and a switch, plus a dBm indication. Having a binary sensor and a switch for the same device is kind of weird and that is what I write in my posting (item one).
Are you saying I need to manually disable the entity (binary sensor or switch) that is not required? That must be described in the documentation and should have been described when the change of rfxtrx was announced in the release notes.
That leaves the second item in my posting: how is it possible that 2 entities of the same device show a different state. This ‘problem’ is pushed away if you disable the entity not required, so can basically be ignored. But it is not working correctly in my set-up.
So to conclude: where before the file name dictated the device type, now you define it’s type by disabling the entity you don’t need. Is that correct?
Why not dump the binary sensor entity of a device. It is confusing.
A switch or a binary sensor both have an on and off value, so basically the same function.
The switch icon shown in the interface can be overwritten in configuration.yaml anyway.
I have to say I don’t know the use cases for the binary sensor, but for devices where HA only receives data I think it makes more sense than a switch.
I’m not a Lovelace expert, but once you start customizing it, new entities aren’t automatically added to it. You can build your own panels filtering out what you want. Also you do not have to disable entities, you can if it really bugs you to have them visible in the entity list.
Now, the binary sensor and switch differing in state, that interests me. Could you elaborate on which device this happens and how you can reproduce that? Does this happen with the door/window switch or the wall switch where HA sends out a code?
I’ve moved the entities indicating dBm to a separate group and disabled the binary sensor entities. I will explore the Lovelace interface later.
The incorrect state of the remote control HKAB1_3 is solved by toggling the device state using the button on the remote. So that only leaves one conclusion: the previous state change was not processed correctly. To be frank, I’ve seen state changes being missed more often since updating to 0.113. I have to investigate this to see if this is not due to battery problems in the device, because both device involved are frequently used.
Isn’t it that when toggling from HA the binary sensor doesn’t update? Or do you also sometimes get state mismatches when toggling from a physical remote?
I see mainly that status changes in HA are not always updated on a remote and a doorsensor. I will replace batteries on those devices involved and monitor this.
State mismatches of different entities of the same device I’ve seen only on one device (a remote). I will keep track of that Too
For sensors not always reporting you could check the dBm, lower value means bad reception. I have a bunch of Oregon sensors which failed occasionally. Funny thing is that without doing anything, they sometimes went silent for hours and then all of a sudden started reporting.
Another thing that may not help, once the rfxtrx boots, it’s going to detect a noise level and filter out everything received below noise level. If you startup in a noisy environment that negatively impact reception.
My problems were all gone after installing this one:
The default antenna is cheap and not optimal for 433Mhz wavelength.
I share that experience with rfxtrx from the time I used DomotGa software as a domotica controller on Cubie truck hardware. I use a diy ground plane antenna since then. See photo.
Since 1 year I use Home Assistant on a Intel Nuc i3, with rfxtrx on a usb port.
