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

[Beeny (Benny)]

No faked sensors set up at the time.

I am struggling to get the BDR91 relays for CH and DHW to reconnect to controller. Everything else has gone back after a power cycle

[iMiMx (iMx)]

You don’t have any de-ionisers by any chance do you?

The only time I ever had anything similar, and it wiped out z-wave and Hue as well, was when we’d just got a new de-humidifier, with a de-ioniser.

… still not 100% sure this is/was the cause, but electrically charged particles I could see how it might be, as it was returned

[Beeny (Benny)]

No de-ionisers too.

I have changed all the batteries and rebound the relays and all seems good at moment. Hopefully this was just a coincidence.

Remind to all to remember to change your batteries before it’s too late.

[zxdavb (David Bonnes)]

@Minh

Hi David,

I’ve come across your nice solution and have been trying to make it works, however I couldn’t get pass the point of loading the component in the first place

I’m currently having my HA up via docker. I checked out the repository, retrieved the evohome_cc in custom_components and deploy it to the corresponding location in HA

I use:

• HA OS (as an ESX VM): use HACS (add a custom repo), and
• HA core: cd .config; git pull GitHub - zxdavb/ramses_cc: HA integration for CH/DHW and HVAC systems that use the RAMSES II RF protocol .

(venv) dbonnes@vm-builder ~/c/evohome (master)> cd ~/home-assistant/.config/
(venv) dbonnes@vm-builder ~/h/.config (master)> ls custom_components/evohome_cc/
binary_sensor.py  climate.py  config_flow.py  const.py  __init__.py  manifest.json  __pycache__/  schema.py  sensor.py  services.yaml  version.py  water_heater.py

You do not need to install ramses_rf (was called evohome_rf until yesterday) with either method - that is specificed in the manifest.json file.

Perhaps you could provide a log file?

[zxdavb (David Bonnes)]

@DanRP

  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 455, in async_schedule_update_ha_state
    self.hass.async_create_task(self.async_update_ha_state(force_refresh))
AttributeError: 'NoneType' object has no attribute 'async_create_task'

Will have a look.

[zxdavb (David Bonnes)]

@stuiow

Are there plans to make use of the outside sensor on the evohome display with this project? its the only reason why i still run my instance of Domoticz

Yes. I am quite keen for people to have no excuse to stay on Domoticz, when they could be using HA instead

Could you PM me a copy of a packet log, taken when you re-bind your weather sensor to the controller to evohome using Domoticz? You will need to turn any device filtering off in the configuration.yaml.

Or better still - if you can manage:

python client.py -rr listen /dev/ttyACM0 -o packet.log

Ideally, doing this for 24h would be great, to catch all the packets the weather sensor might send - but the binding is the main thing.

I have 100’s of MBs of packet logs, but I don’t have a copy of any of that.

[zxdavb (David Bonnes)]

@Beeny

I have been running the initial Faked sensor release. Controller has lost connection to all devices. Never had a problem like this with evohome.

I am sorry, I cannot see how evohome_cc / ramses_rf could cause this.

I have done a lot of crazy things here whilst developing ramses_rf & never saw that behaviour…

Do send me packet logs if you have them, and I will take a look.

[sOckhamSter]

Hi @zxdavb

I’ve just put in a pull request for a tiny code tweak. It allows users to create an optional configuration parameter:

evohome_cc:
  ...
  advanced_override: true

If this parameter exists and is set to true, the behaviour of set_temperature in climate.py is ZoneMode.ADVANCED. If the parameter doesn’t exist or is false, previous behaviour is maintained. I see this as a temporary measure until you have completed the development of profiles. It means I don’t have to keep manually editing your code every time I update it. I hope this request is ok for you to approve.

[zxdavb (David Bonnes)]

That’s great! I have made a review. Please install & run pre-commit too.

[sOckhamSter]

Ah… I think I may need a little hand-holding with that please? I was pleased with myself for managing to put in a pull request but I’m afraid I’ve no idea how to do what you’re now asking!

Update: After Googling that, I’m assuming pre-commit is something I’d need to install in a development environment… only issue is I don’t have a development environment with git installed as such! I made the changes manually in my local installation on Home Assistant, tested, then branched your repo on Github and pasted my changes in before making a pull request. I don’t have a local clone or anything like that running.

[sOckhamSter]

@zxdavb ok, I figured out pre-commit! It made a few changes in accordance with your policy file so I’ve revoked my original pull request and put a new one in. Hopefully that’s ok for you now?

[zxdavb (David Bonnes)]

Well done with pre-commit.

I am not sure why you closed the first PR? You can just commit/push any changes to a PR, without the need for a new one.

[sOckhamSter]

I’ll remember that for the next time then… I’ve no idea what I’m doing, just clicking things until it did what I wanted

[zxdavb (David Bonnes)]

I need someone with an evohome external/outside sensor to provide a packet log please.

A real Honeywell sensor, not a Domoticz faked sensor.

Please PM me.

[DanRP]

@zxdavb David, 12 zones all being controlled by faked sensors using Xiaomi Mijia temperature and humidity sensors. The uniformity of a rooms temperature is definitely improved versus the HR91’s. Any plans to allow more than one fake sensor to be applied to a zone? This is a great enhancement!!

[zxdavb (David Bonnes)]

@DanRP

David, 12 zones all being controlled by faked sensors using Xiaomi Mijia temperature and humidity sensors. The uniformity of a rooms temperature is definitely improved versus the HR91’s.

That’s great - we’d always expect TRV sensors to suffer from their non-optimal location & their proximity to their radiator.

@DanRP

Any plans to allow more than one fake sensor to be applied to a zone?

No - evohome expects only one device nominated as the sensor per zone.

You could have multiple sensors, and send the average of those to evohome_cc to fake.

[DanRP]

@zxdavb

No - evohome expects only one device nominated as the sensor per zone.

I was thinking in the same way you can have multiple room zone? In this case the bound HR91’s act independently of one another.

[TheMystery (Johnny)]

Can you explain how you set it up?
I have some aqara zigbee and some sensors attached to an esp with esphome which I can use for this but the above explanation was not really clear for me.

[DanRP]

@TheMystery

Can you explain how you set it up?

With the Zigbee sensors setup and reporting their values within HomeAssistant:

• Long press Settings on the EvoHome controller
• Select Zone Configuration
• Select your zone
• Select Temperature Sensor
• Select Remote Sensor
• Select Yes to override the previous sensor bindings
• The controller will now ask you to bind the temperature sensor
• From HomeAssistant call the RAMSES RF: Create Sensor service, the EvoHome controller will acknowledge the “fake” sensor is now bound.
• Repeat for other zones.

Now that the “fake” sensor(s) are bound, you need to write an automation which calls RAMSES RF: set_zone_temp service passing the current value of the Zigbee sensor(s).

In my case, I have an automation running every 4 minutes, which updates the zones.

[TheMystery (Johnny)]

Oké clear, do you have an example of the automation how you use your own sensor?
The given example from a few days ago sets an manually given temperature.