Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

No - you can have both integrations at the same time - they are compatible. They do different things, too, so are complimentary (i.e. you may still want to run both even if you get ramses_cc working).

I do not test/dev with Windows - but WSL works OK (I do my test/dev of WSL2/Ubuntu). Others may suggest a Windows solution.

In Linux, I use:

dbonnes@raspberrypi ~/c/ramses_rf (refactor)> tail -f /dev/ttyUSB0

# evofw3 0.7.x
061  I --- 34:021943 --:------ 34:021943 30C9 003 000848
029 RQ --- 01:145038 10:048122 --:------ 3EF0 001 00
043 RP --- 10:048122 01:145038 --:------ 3EF0 009 000010000000020A64
088 RQ --- 34:136285 01:145038 --:------ 000A 001 05
029 RP --- 01:145038 34:136285 --:------ 000A 006 051001F40DAC

Note: the above will only test Rx. It is quite common for these units - for various reasons - to Rx, but not Tx (e.g. using the wrong bootloader in the Arduino IDE).

You could also check out https://github.com/ghoti57/evofw3/wiki

No - you have to add the repo manually. There is a wiki, and it includes installation instructions.

Note: it is ramses not rameses (Residential Application Management System… or some-such).

I have fully re-written the protocol stack used by ramses_rf - months & months of work… Thus, a new version of ramses_cc will be released soon-ish.

It will address/resolve some of the intractable issues with the existing code.

2 Likes

Thanks very much for advice. Will give it a go. Appreciated.

Is a possible use case to turn the pump of the underfloor heating on and off with a shelly (or similar) instead of using a zone valve?
I noticed during a underfloor heating pump failure that hardly any water goes into the floor.

I am curious whether using a shelly instead of using a bdr91 is already implemented.

You should be able to do this just using regular HA automation, i.e. when a particular zone changes state, e.g. idle to heat and vice/versa, then trigger a relay on, e.g your shelly.

I run multiple pump circuits this way, the BDR91 is only connected to the heat source to trigger global heat demand.

Hi, I have been trying to get this to work for some time.

I keep getting the following error on HA startup

Error during setup of component ramses_cc

13:19:09 – (ERROR) ramses_cc (custom integration)

Best practice is exactly one gateway (HGI) in the known_list: []

13:19:09 – (WARNING) ramses_cc (custom integration) - message first occurred at 13:19:09 and shows up 2 times

I have this in the Configuration.yaml
ramses_cc:

serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
packet_log: ~/home-assistant/.config/packet.log

The only other things I have plugged into my Pi are a Dresden Zigbee bridge and a USB to Sata adapter for my SSD

Any advice?

The integration suffers greatly because:

  • it would benefit greatly from having good documentation
  • it doesn’t have good documentation

If anyone is willing to make a commitment and can liaise with me to create documentation for this integration, please PM me.

The above isn’t really an error - it should be a warning. It shouldn’t really stop the integration from working.

In reality, it is saying there are two devices with a device id starting with 18: (one of which is the USB dongle).

Solution: create a good known_list - see the wiki.

The new version of ramses_rf handles this issue completely differently.

Other than this error message, do you have any issues?

The above looks OK.

Good to know that it works.
So in this case you only have a temperature sensor in a zone?

Maybe this makes it clearer: I have 5 pumps which each serve 1 or more radiator zones - so each zone is a sensor and multiple TRV’s. Evohome takes cares of the TRV’s and global heat demand through a single BDR91. When a zone is triggered (from my perspective an HA thermostat state), automation will trigger the relevant pump for that zone. This saves me energy - the original setup had the BDR91 triggering both heat demand and all the pumps together.

I’m not 100% on your automation (maybe you might post the YAML here?), but it wouldn’t be uncommon for the zone sensor to have measured_temp < setpoint, but all the TRVs have their valves closed (i.e. water circulates around the zone, but does not enter the radiators).

You may want to consider turning on the pumps (are they pumps or valves?) if:

  • system heat_demand > 0 (so the heat source is providing heat), and
  • max(heat_demand of all TRVs) > 0 (so at leave one TRV has it’s valve open)

Usually the former is true if the latter is true.

Got the same problem here! Remote is working but can’t see any fan info in HA for my MVS-15 unit. @nickasdf did you fix this issue?

Its indeed a little more complicated: each zone automation has a condition to check that relay_demand on the BDR91 > 0 and that the demand relay is actually on. Also automations on the controller state itself, e.g. if the whole system was off, away mode etc will trigger zone automations to trigger pumps where necessary, if the controller switches off, then turn off all pumps…its actually quite a bit of YAML.

Seems to me that you’re on top of it!

OK, thanks.

I dont seem to log anything though. There is no packet log created.
I assumed the radio dongle was not working.
How do I know what to put in the ‘Known_List’ if I dont see anything in the log?

Is there a new version of ramses_RF I was unaware! How do I update!

Without a known_list (and assuming you don’t enforce_known_list: true - it will accept packets from all devices. It is OK do do this until you know the device ID off all your devices.

Sorry, I misled you before:

Is actually saying you should really specify one - and only one - HGI in your known_list. But if you don’t things will probably be OK - you will certainly get packets in your packet log.

If your packet log remains empty, and your configuration is only:

ramses_cc:
  serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  packet_log: ~/home-assistant/.config/packet.log

… which is valid (but not necessarily correct), and you don’t get any other errors…

a) change it to (only):

ramses_cc:
  serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  packet_log: packet.log

b) and check your serial port.

Other than that, where did you get the USB dongle? What is your set-up (e.g. are you using a VM)? Have you read the wiki?

Did you install via HACS?

Excellent, changing the path to the packet.log did the trick and for some reason I don’t seem to have the HGI error anymore.

I guess I just need to work out which are my devices and not my neighbours now!

I got the USB dongle from the link recommended in the FAQ and readme
I meant to add my HA instance is a Rasp Pi4 running HASS

This is the strongly recommended option:

Other solutions will be much cheaper, but the quality can be very variable - many people have bought one of these, after spending (wasting?) money on alternatives.

Sadly, they’re currently out of stock.

[ No: I am not on a commission. ]

1 Like

Yep, thats what I bought from indalo-tech!
I have had it a while as I have a busy work/home life and not had the time to play until now with this kit.
I presume working out which Evohome components are which is a case of trial and error.
How long should I leave it before creating the known_list?

Have a look at the wiki - mostly section 2- configuration.

In most cases of evohome, you only need to wait a few minutes after rebooting HA - but I would generally give it 24h

1 Like

Will this custom component allow me to read the on / off state of a bdr91t honeywell relay in am evohome setup?

I want to detect if a pump is being switched on/off.

Yes, it looks like this in HA. I use the feature to monitor 3 port valves that are used for boiler demand (ignore the incorrect label in picture)