This feature (until) is not part of my code - it is part of HA (much like a ‘save file’ dialog box you might see when using an application on a PC is from the OS (on behalf of the app), not from the app).
As such - I cannot change it
Thanks for the expalnation David
It would be possible - but some code would need to be written to pull the data from the fault log, parse/reformat, etc., and I currently don’t have the capacity for that. I doubt I’ll have such capacity before the end of this Winter.
If anyone knows python well - I’m willing to help them have a go at it.
@zxdavb, yes I totally understand. It’s really just a nice to have 
… I am looking forward to testing the zone schedule setting feature when it becomes available, hoping it makes it in this season
trying to set a temporary_override in node-red but regardless of setpoint my zone is set to max temp until next setpoint
Doing same (but slight different formatting) in developer tools works:
service: ramses_cc.set_zone_mode
data:
entity_id: climate.living_room_2
mode: temporary_override
setpoint: 12
duration:
minutes: 5
I’m very confused 
You could also try: duration: 300
You have to start by sending me a recent packet log. You can best do this via a PM.
The log should be 24 hours (so it includes showers, etc.), and also includes a restart of HA. The last log you sent me (you posted in this thread)
Then I can pick it apart and see what’s what - for example I am pump it into HA in pseudo-realtime, as if from a real system.
You have sent me a previous log - but it does not include a restart, and so is not useful to me.
Niet beschikbaar means Not available, but what does Uit mean? False?
Can you confirm the above are the sensors that:
- are now:
not available, and - you used to get values for previously
“Uit” means “Off”.
Things have changed since Feb 2021 - I am not sure I understand how to install this. Recently came back to HA after being away for a long time - a lot has changed! This thread goes back years and things for evohome_cc have changed along the way. I’ve gone through this thread, but have obviously missed something. Can anyone help to set me straight!
I’ve installed various components (following post 662 as well as the wiki on zxdavb/ramses_cc, but cannot see anything in the log file yet.
(Evofw3 on a nanoCUL, and ramses_cc via HACS) and added the following to my configuration.yaml file:
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
The nanoCUL is seen my VirtualBox and given to the container. I can see the device has been created via the terminal.
I don’t seem to get any decode - nothing in the logs yet. So am wondering if the ramses_rf is also installed when ramses_cc is installed
I’m pretty confused now so here are some basic questions:
Has evohome_cc become ramses_cc?
Is evohome_rf the same as ramses_rf?
Does the installation of ramses_cc also install ramses_rf (if installed via HACS)?
I tried to install ramses_rf manually using:
git clone https://github.com/zxdavb/ramses_rf
cd ramses_rf
pip install -r requirements.txt
The cloning worked, but I cannot do a “pip install” and python is not installed on the image I am using for HA
(My HA instance is running on VirtualBox running on a Mac). Installed 30 days ago.
Home Assistant 2022.9.7
Supervisor 2022.10.0
Operating System 9.0
Frontend 20220907.2 - latest
So how is ramses_rf installed on a VirtualBox image? - no python or pip?
I was thinking I would need to start from scratch and rebuild the HA on a new VirtualBox instance from the ground up to allow for python to work, but the HA information for installing seems to always go back to downloading a VirtualBox image which I already have…
I also have the following directories:
/custom_components
/custom_components/ramses_cc
/custom_components/ramses_rf
/custom_components/ramses_rf/ramses_rf
Configuration.yaml passes and the restart works fine. At each change/add I shutdown HA and rebooted the VirtualBox image.
I am receiving two things in the log file:
Logger: ramses_rf.protocol.schemas
Source: custom_components/ramses_cc/coordinator.py:154
Integration: RAMSES RF (documentation, issues)
First occurred: 13:00:29 (2 occurrences)
Last logged: 13:00:29
Best practice is exactly one gateway (HGI) in the known_list: []
Logger: ramses_rf.protocol.transport
Source: runner.py:119
First occurred: 13:00:29 (2 occurrences)
Last logged: 13:00:29
Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
This leads me to think that ramses_rf is in fact installed and maybe I should just delete the following:
/custom_components/ramses_cc
/custom_components/ramses_rf
/custom_components/ramses_rf/ramses_rf
Assuming once ramses_rf is working and decoding messages, they will go to the log file tagged by ramses so I can continue to identify and then filter and use this information.
Oh yeah FWIW - I have Honeywell Total Connect Comfort (Europe) installed and working. The comment in the installation WiKi for ramses_cc seems to say this will not conflict, with the proviso that you will see more Entities (I’ve no problem with that (now)).
In the end my goal is to work out the following
- When does the boiler fire - I’d like to know boiler firing times and durations
- Why does the boiler fire - how could I change how zones are configured to save
These two things I cannot get from the built-in HA Honeywell integration. This is why I got interested in this project and as its been around a while also thought it would be mature to use.
Any help gratefully appreciated.
For completeness. This is the device I purchased:
Yes.
Yes.
Yes.
Just install ramses_cc via HACS - that’s all you need to do.
You don’t need to have anything else.
Correct. You can ignore that warning for now.
Don’t delete that one.
Are you getting a packet log? Have you configured one? Maybe post your yaml here?
You shoudl be able to do that. The quality of the data will be if you have a BDR, or an OTB.
What version of evofw3 are you running on it? Did you select the correct board type when you installed teh firmware? See: ghoti57/evofw3: Major overhaul of evofw2 Evohome listening software to use asynchronous radio mode (github.com)
Thanks for the reply!
Looks like I complicated things by not just following the wiki installation steps from the start 
.
I have removed the following:
/custom_components/ramses_rf
/custom_components/ramses_rf/ramses_rf
The only thing left is:
/custom_components/ramses_cc
and have restarted.
Am turning on various parts of the heating and will carry on looking in the logs…
FYI -
My yaml lines (for now) are set as:
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
ramses_rf:
enforce_known_list: false # if not true, still enforces the block_list
disable_discovery: false
disable_sending: false # do not transmit any packets, ever
enable_eavesdrop: false # can be used to create an initial system schema
packet_log: packets.log
For the nanoCul programming, I used the code from here:
https://raw.githubusercontent.com/ghoti57/evofw3_avr/master/package_evofw3_boards_index.json
(So, I think that is the updated one you mention.)
Is there a way to query the nanoCul to see if it in fact is flashed properly and working?
packets.log looks like this now:
2022-10-10T01:08:12.111802 # ramses_rf 0.20.36
2022-10-10T13:00:29.395081 # ramses_rf 0.20.36
2022-10-10T14:30:39.981323 # ramses_rf 0.20.36
That’s all for now…
It appears the USB dongle is not picking up any packets.
You’ll have to get others to help you with that - maybe the wrong board type when you flashed, maybe something with your VM? Sorry: I Dunno.
The most important for me is ch_water_pressure this was always working
One issue is that the gateway is not receiving any response from the OTB when it asks the OTB a question. It does, however, receive packets from the OTB that are sent to the controller.
Please:
- PM me your configuration.yaml
- tell me what USB dongle you have
The data you want is there - it would be a matter of working out how to get it.
Nanocul with evofw3
Hi all,
I’m new to the Home Assistant project and forum, and have just finished installing a central heating system around the evohome controller. I’ve been using the ramses_rf library together with the dongle from Indalo-Tech with the evofw3 firmware to understand how the evohome controller communicates with all other components in the system. My set-up:
- HCE80 underfloor heating controller with HRA80-antenna
- OpenTherm bridge connected to a boiler
- Evohome Touch as central controller and acting as a zone temperature sensor
- Other zones are equipped with T87RF wireless thermostats
The HCE80 switches underfloor heating circuits through MT4 motors with auxiliary contacts. The circuits are on three different floors and each floor has its own distributor and recirculation pump. Since the HCE80 can switch only one pump, the auxiliary contacts of the MT4 are used to turn on the right pump when a circuit is opened by the HCE80.
The only downside of the HCE80 is that it has no anti-seize functionality to periodically open the valves of a circuit and switch the pump during longs periods without any heat demand.
My question is:
Would it be possible to open circuits connected to the HCE80 through a wireless command from the dongle, without any heat demand being present? A hardware solution with a relay and a timer would also work, but I’d prefer a software based solution if possible. I’d like to contribute code to make it work, if I could get some guidance in the right direction.
Many thanks in advance.
Best,
Viktor
If my memory serves me correctly (away from my notes at the moment) there are two alternative pin outs, and you need to ensure you select the correct one for your board
Hello,
I have a setup similar to your except that my MT4 valves do not have auxiliary switches (I didn’t know it existed, just discovered this with your post, thanks 
).
In my case the pump I have on each distributor (on each floor) are conneted via a zwave plug which I activate o/off if the zone is currently heating or not via an automation. In my automation I have a timer which starts the pump once every week in case the pump has not turned at all during the week.
I don’t think it is possible at the moment to send packet to artificially open an actuator without having the boiler firing up thinking that there is a heat demand.