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

The evohome integration shows a shaded are for each zone’s heat demand (upper graphs) - TBH, this is a bit of an educated guess. evhome_rf does it accurately (lower graphs):

Note the temps in the upper graphs are the room (zone) temps, no the TRV (device) temps.

This one compares a room with a thermostat, to one without:

In the left graph, the 34: device is a round thermostat in the zone, and the room temp overlays it 100% - the 01: device is a TRV.

In the right graph, the thermostat is in the same room, but is not part of the zone, so the zone temp is coming from the TRV.

Sorry, but for some reason, target temps are not graphing properly, so aren’t included.

@zxdavb Ok trying to spin this up with an HGI80 connected to a PiZero.

Using the following on the PiZero to give me an RFC2217 Serial server

https://pyserial.readthedocs.io/en/latest/examples.html#single-port-tcp-ip-serial-bridge-rfc-2217

Then use the following config for HA

evohome_rf:
  port: rfc2217://10.0.10.125:8989

But that’s as far as I’ve got.

@GadgetUK I think the best thing (to get RFC2217 going) is to concentrate on getting the client library working first, then go from there, something like:

git clone https://github.com/zxdavb/evohome_rf 
cd evohome_rf

python3 -m venv venv
source venv/bin/activate

python client.py -p rfc2217://10.0.10.125:8989
  

Note this is the client library, not the custom component.

If you need to, you can chat with me at:

Otherwise:

  • did you enable logging in HA, and
  • what do the logs show?
grep ~/.homeassistant/home-assistant.log | grep evohome

Many lines of the following in the logs…

2019-12-03 21:59:52 DEBUG (MainThread) [custom_components.evohome_rf] Status = None

That is a message from the custom component - not from the client. You need to really run the client by itself, until we get this serial-over-net working.

OK, here is proof that the shaded are in the evohome climate cards is inaccurate.

The upper card is evohome, the lower card is evohome_rf. Note the red ‘arrow’ pointing to a time where the zone is clearly receiving heat.

1 Like

Wow, was planning on doing this exact same thing on the short term. Great to see someone is working on this already.

Will buy a HGI80 and test the integration soon.

Please continue, I’m also going to join.
Now busy with other topics…

So I think I’m about at the point where I’m ready to give this a shot… I’m running hass.io and would prefer not to install anything directly on the OS for my hass.io machine, but keep the machine “docker only” to ensure pristine-ness ;-). Would it be possible to run evohome_rf remotely? Is it a server or just a library? If not, where would I install it, within the homeassistant docker container?

Just be aware:

  • HGI80s will be the most expensive option - but they will be the most compatible/reliable
  • other options will be cheaper and can also be used for neat tricks like emulating a TRV (or even a controller) - see the ‘or similar’ in the top post

I have a HGI80, but I have ordered one of these (not yet arrived):

1 Like

Currently, evohome_rf is a custom component (it will be mainlined at some distant point in time). It uses the evhome client library (below), which itself uses pyserial-asyncio:

I have a fear that the async version of pyserial doesn’t work with RFC2217!

@GadgetUK DId you get my message about RFC2217?

Yes, trying to decide what the best way to move forward is.

I think moving back to a non-async version of pyserial would be a mistake, especially in the longer term (so won’t be doing that).

I have pushed a new version of teh library, and the custom_component - don’t bother with older versions.

So it sounds like it’s not possible to install evhome on a remote machine then, correct? Should I install it inside the docker container for homeassistant under hass.io?

You can create a separate instance of HA & install the evohome_rf custom_component within that… or just add the custom_component to your existing HA - it should not cause much drama.

I suggest getting the client working first, before trying the custom_component.

The main requirement is that the USB port has be available as a local device, say \dev\ttyUSB0

Hmm, I have an old version of hassbian on a currently unused Pi which might be better suited to just being a testbed for this for now, though I would eventually want to run it on hass.io (but I suppose this won’t be an issue when it goes official as the libraries will just be included in the distribution along with the passthrough for USB to the container, at least it works for me with Zwave). Only problem is that it hasn’t been upgraded for a long time and they’ve now discontinued hassbian.

How recent of a version do you want me to test it on?

Also, will there be any issue with running this on one hass instance and my production evohome setup on another?

Needs to be latest version of HA - 0.102.

No issues i can think of

The custom component includes a manifest.yaml which instructs HA to install the appropriat client library.

I am dev/test on 0.102 - recent versions may work.

Not really. Also, evohome_rf is ready-only, for now.

In truth, I think there is no reason to avoid putting this custom_component in your live version of HA (although I can also appreciate why people would want to avoid this) - this will allow you to compare date, etc. between evohome and evohome_rf.