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

I have just send you a pm with the file and my config

Hi David, after several restarts the issue was resolved for the “Badkamer Boven”. It now shows (Idle) properly. However, unfortunately the other zone (Hoofd Slaapkamer) isn’t working. It refuses to register my HR92 :frowning:

image

I will PM you my packet log

My Dutch friends may be able to translate this for me:

0 = min. potm.
0 = min. van min. potm.
0 = min. fan
100 = max. potm.
100 = max. van min. potm.
100 = max. fan

It refers to a number between 0-100 (i.e. a percentage).

The hint is: it has got to do with HVAC (a fan?)

For the benefit of others - I believe this system to be mis-configured, but the issue only became apparent when the zone sensor was faked. Solution: re-bind the missing TRV.

@maesenator will tell us if I am wrong!

Potm could be a short of potentiometer. A variable resistor. Could it be the minimum and maximum speed setting?

When I saw the question before I read your comment I had exactly the same idea, no idea what it otherwise would be.

and the ‘van’?

Van means “of”. 0 = min. van min. potm would be: 0 = minimum of minimum potentiometer

I have got an itho fan. So it could be a fan indeed.

Solved. I forgot I had hard coded the fake sensor in the 04 zone in my yaml file. I had to comment out the config for this zone, restart hass, bind a new fake sensor, look in my evohome_cc file for the new ID and then change the config in yaml and then restart again :wink:

Old post

Alright, so I reassigned the HR92 to the zone and it solved my problem. However, this introduced a new problem: The zone is no longer using the fake sensor to report the temperature.
Unable to configure the zone to go back to the fake sensor I decided to use the service evohome_cc.create_sensor to pair a new one to the zone. The evohome system indicated that the pairing went successful, but unfortunately the zone keeps reporting the temperature from the HR92.
It doesn’t matter if I call the evohome_cc.set_zone_temperature service, the temperature of the zone doesn’t change.
This is also obvious from the below screenshot because the temperature shows a decimal and I am trying to submit a whole number.

My evohome_cc file now looks like this for zone 04, so it shows that the HR92 has indeed now paired correctly and that the fake sensor is also there (in fact, this sensor’s ID hasn’t changed!).
So, even though my previous problem has been solved, I believe the situation is now worse because the fake sensor for this zone is pretty important :stuck_out_tongue:

                        "04": {
                            "heating_type": "radiator_valve",
                            "sensor": {
                                "device_id": "03:256031",
                                "is_faked": true
                            },
                            "devices": [
                                "03:256031",
                                "04:164247"
                            ]
                        },

image

Can anyone with an OpenTherm bridge, who knows how, please do the following:

  • checkout the latest otb_support branch of zxdavb\ramses_rf
  • execute the equivalent of:
python client.py monitor /dev/ttyUSB0 -x "RQ 01:123456 1F09 00" -o packet.log

And send me the packet log after running for 10-15 minutes?

I will, do i have to replace the current component?

So, release 0.10.10 just pushed - lots of changes for OpenTherm bridges (and many other small fixes).

If you want to improve support for OpenTherm Bridges (R8810A), please send packet logs from HA starts, and copies of the .storage/evohome_cc file. Also include a copy of the evohome_cc: section of your configuration.yaml.

If you don’t have OpenTherm, and are un-adventurous, then do not upgrade.

Just updated en after then minutes i have grab the packets log and the evohome_cc file. I have send you a PM.

So, a new release - I recommend it to all people with an OTB.

If should fix many issues (maybe the above?) - please let me know if you have any problem.

If anyone could do the following (where 10:xxxxxx is your OTB’s device ID), I’d be grateful:

python client.py -rr execute /dev/ttyUSB0 -sx 10:xxxxxx -o scan_otb.log

Thank you so much for trying but sorry to say that, while upgraded to the latest version, I still only get the sensors in the image.

I am using the config below:
evohome_cc:
scan_interval: 60
serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
packet_log: /config/custom_components/evohome_cc/packet.log
advanced_override: true
restore_state: false
schema:
controller: 01:133689

Don’t worry - I know what the issue is! A fix is comin.

@hsluis I am hoping the latest release will address your issue. There may be bugs, let us know.

It is an OpenTherm-specific release - non-OT improvements are there, but may not be worth the risk in upgrading just yet - you can always downgrade if you have to.

Note: you couldn’t downgrade evohome_cc before (because ramses_rf wasn’t pinned), but you should be able to now.

1 Like

That worked for me, it’s added 5 new sensors.

Thanks.

Looks very solid for me. With the heating circuit not in operation, all values make sense to me (given that the heater is idle during this time of the year). Really nice to have the ch water pressure and return temperature. The return temperature I am already monitoring via separate sensor, really looking forward to compare both in coming winter.