Perhaps a dumb question, as I’m a newbie: but I would like to not only disable some RFXCom devices, but also completely remove them from the database to keep things tidy The “delete” button however is greyed out.
These devices where received and automatically added to the list, while I had “enable automatic add” enabled to find my own devices. However also some “neighbour” devices where added which I want to remove from my systeem.
Have the same issue as TS; but the integration config option has been removed so it seems; there is no option to remove any set of automatic added devices currently. Only one by one, which in the case of the RFXtrx integration can be many…
Yes, I’m also missing this. I have about 100 RFXCOM devices that I would like to remove, but that is really tedious to do by selecting them individually. Also deleting the Entities is also not possible.
Any change the option to select and delete multiple RfxCom devices in one ego will be implemented soon? Or another workaround?
hello, I have the same issue with over 2800 unwanted, (not existing) devices.
You need 5 mouseclicks to remove 1 (one) device.
So I need 5*2800=14000 mouseclicks to get them removed. And hoping they will not return in case I want a new device to be added.
This is a working but stupid way. Is it not possible to use the method as in the mqtt integration?
I think this integration is pretty much dead. It was always very low activity and always had a terrible UX, but if you look at the repo on github, it’s mostly just bumps of various dependencies, translation updates and the occasional small bugfix by external contributors by now.
I have an RFXCOM myself and I have given up on this integration a long time ago. It’s just really really bad. I quickly threw together a minimalist RFXCOM to MQTT interface for the protocols I use in my home. That works (for me) but it’s not very generic. I have been looking into something a bit more general and well maintained lately and stumbled across this:
So this is a NodeJS API to the RFXCOM transceiver and looks pretty well designed. It shouldn’t be too hard to add an MQTT interface to this and make it talk to HA. Then all RFXCOM devices could be specified as MQTT devices in HA and bye bye rfxtrx HA integration forever.
Just as an addendum to my last post above. I wrote a simple RFXCOM to MQTT driver in NodeJS using the library I linked to above and it works really well. It completely replaces the built-in HA rfxtrx integration. No more awkward and limited UI. All devices, options, everything in defined in YAML. Right now the protocol support is rather basic (mostly those I use myself), but it can be easily extended. Being independent of HA and using MQTT, it can also run on a separate system over the network.
If there is some interest, I can upload this to github.
Really interesting! Would love to be able to put RFXCOM on a separate machine/location from my Home Assistance system.
I’m not a developer however, so couldn’t do much with the code, but if this would be available as an application e.g. with a Docker image with some configuration Yaml that I would love to try this.
My RFXTRX2MQTT driver is now available on my github:
The readme is still very basic, but the driver runs very well (at least for me). So far it supports most temperature, humidity, rain, wind and weather sensors, as well as lighting2 (DIO, CHACON, KlikAanKlikUit, etc) and lighting5 (OTIO, Conrad) protocols for switches, remotes and relays. Feedback is welcome !
Once I wrote a better readme I’ll create a separate topic about this with more detailed usage instructions.
I tried it this weekend and got it working quite easily. Worked pretty nice, so thanks for all the work!
Still need to find out how to get the node working as a service. Need to Google that, so any pointers would be great.
And of course then I have to scan for the id’s of all my devices and manually create mqtt configuration items for them in Home Assistant (auto-discovery would be a great addition ).
Well, considering the latest breaking changes in MQTT auto discovery… The idea with this driver is to keep it independent of HA, specifically to avoid HA breaking changes as much as possible. Adding auto-discovery would be against that concept, tying it again to HA.