Hello,
Do you still get that phantom device?
A block list is not implemented, as I know, but if you declared all the devices in the known devices and ticked that only accept packets… just from the beginning… you should not have any issue with that phantom reappearing.
As for the asuming evofw3 message that is normal, but I do not know the exact reason. @EgbertB or @ghoti571 might have more insights in your issues.
As for that device class : problem… ^^^^
Wait a second. You just see that phantom in logs? If so you should not care about it. If it does not get added to the devices in ha it’s ok. It can mean that you have some interferencies in rf and the usb dongle just catches noise. Remember, ramses protocol does not do error correction very well and noise might be a issue in very crowded rf environments, tgat is why that allow list and the option to restrict pachets exists.
Yeap there are in my logs: it seems more than 1.000 occurencies per day
there is a way to “stop” to registry this kind of?
Regarding Ramses itself, is working very WELL without any issue from my view
I can setup my TRV from HA and it is all locally so I achieved my goal thanks to “Ramses Team”
If those do not appear in your integration as devices just ignore. There is no way ,I know of, to stop the cc11011 RF module to see them or ignore them.
Could anyone who has a controller with firmware version 02.47.00.01 (or later) please confirm that the official evohome integration works fine with HA 2025.11 or later?
Sorry I’m in the UK so stuck on 02.01.02.01 but I did notice that the Resideo website says the new release is RED compliant. They latest regulations there have quite a few additional requirements on cyber security which may have resulted in them restricting access.
Hi, QQ, I have been trying to find out if this will work to get the information from the Evohome system I have 3 HCC100M2002 with the ATC928G3027 as main controller. Before I buy the [nanoCUL USB Stick] nanoCUL USB Stick FTDI CC1101 868MHz FW 1.67 Knick-Antenne FHEM CUL 868 +Adapter | eBay) I would like to make sure I will be able to see the information these use to talk to each other, I am mainly interested in the status of the pump being on and off and how much % of each head is open. Thanks!
Just for the record on this I ended up manually removing the devices from the core device registry which was pretty easy. Take a backup, I’m glad I did as I managed to screw it up a couple of times and it could corrupt the ability to load any devices in HA.
I would strongly advise NOT to go for the nanocul. It has several drawbacks, the most important is it’s low memory. I would advise to go for the ramses esp from indalotech. It’s a very modern and capable device. Also, did oubinstall by yourself the HCC100? Were you required to use the pro app?
I have the Samba Share add-on installed and use that to access HA remotely.
From my laptop I browse the HA config folder to find the devices database file. Back this up, make a physical copy of it somewhere. Backup with HA backup also.
Open the devices database file in vscode. Make sure nothing like word wrap or anything is enabled.
Each device is on a line of it’s own.
Use search to locate the device you want to remove using the zone id I.e. 14:14400 or whatever. You must remove the entire line.
If the device you want to delete is at the end of the list then you MUST ensure that the structure of the file is not altered. This is what screwed me over. I removed the last line and it corrupted the database and deleted most of my devices on a reboot. I don’t know the exact syntax but if you just delete the last line if the section then expect hours of pain.
Once you’ve removed the devices you want. Save the file and reboot. Keep all your fingers crossed and hope that everythings ok. You should tell quickly, if the file size of the device database decreases in size after reboot then it’s bad times.
If you are trying to fix the database never use you original database file, always create new copies.
If you replace the file and reboot it seems to override the database on shutdown. I got to a point where I had to reboot HA, wait for it to be down enough, then I overwrite the dB file before it came back online. It came back and worked again.
It’s really not nice when it goes wrong. You may be able to restore from HA backup, I didn’t try.
I currently have just switched over to the ramses_esp module and I’m seeing this warning in the Home Assistant logs and wondered if I needed to do anything/manually specify the type somewhere?
Logger: ramses_tx.transport
Source: runner.py:289
First occurred: 13 December 2025 at 10:27:30 (4 occurrences)
Last logged: 12:08:25
/dev/serial/by-id/usb-Espressif_USB_JTAG_serial_debug_unit_CC:BA:97:08:CD:F8-if00: the gateway type is not determinable, will assume evofw3
Thanks for you input. They were installed by a company but i am able to access them with the Pro app. Is there something i can configure on the app to get the data out?
when you are responding to a previous item, instead of starting a new topic, select a few (informative) words in that topic before opening its three dots icon and picking “reply”.
This will add a link, like this example.
How do you handle keeping the input select helper in sync with the PIV mode? For example, if the PIV is boosted, after a period it will return to normal mode.
Good point; the input_select by design doesn’t follow the actual device state. You would need to add a repeating/on change automation to solve that. Add a short delay to prevent a loop. I read the actual fan state as an extra entity on my dashboard, and tolerate incidental mismatches…
This is the thing I’m missing. How do you read the current status of the PIV?
The PIV itself shows up as a device in HA but has no entities. I assumed sending a “get_fan_info” via the remote was what was needed. In the packet log I see the remote sending the request and the PIV responding:
