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

@zxdavb Thanks for reply.
I educated myself little bit more about dockers.
This time I have checked all the commands inside docker and I got:

plmicia@brix_hassio:~$ sudo docker exec -it homeassistant pip list | grep serialpyserial                         3.1.1
pyserial-asyncio                 0.4
sphinxcontrib-serializinghtml    1.1.4
voluptuous-serialize             2.3.0

plmicia@brix_hassio:~$ sudo docker exec -it homeassistant pip list | grep evohome
evohome                          0.0.8
evohome-async                    0.3.5.post1
plmicia@brix_hassio:~$ sudo docker exec -it homeassistant dmesg | grep tty
[    0.000000] console [tty0] enabled
[    2.031511] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    2.223480] tty tty61: hash matches
[    6.894828] usb 1-3.4: TI USB 3410 1 port adapter converter now attached to ttyUSB0
plmicia@brix_hassio:~$ sudo docker exec -it homeassistant python -V
Python 3.7.7

screen command inside docker also gives me good results.

Everything is looking good but why it’s not working? Did I forget something obvious?

I also changed line in configuration.yaml to homeassistant.custom_components.evohome_rf: debug - no difference anyway :-(.

Are there any other (more detailed) logs, where I could debug Home Assistant?

Try this in you configuration.yaml:

logger:
  default: info 
  logs:
    homeassistant.custom_components.evohome_rf: debug
    evohome: debug

From the first line, you’ll see in home-assistant.log things like:

home-assistant git:(dev) cat ~/.homeassistant/home-assistant.log | grep evohome_rf

2020-04-13 16:42:34 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for evohome_rf which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
2020-04-13 16:42:37 WARNING (MainThread) [custom_components.evohome_rf] Store = {}
2020-04-13 16:42:37 WARNING (MainThread) [custom_components.evohome_rf] Config =  OrderedDict([('serial_port', '/dev/ttyUSB0'), ('packet_log', '/home/dbonnes/packets.log')])
2020-04-13 16:42:37 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=evohome_rf>
2020-04-13 16:43:31 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event platform_discovered[L]: service=load_platform.sensor, platform=evohome_rf, discovered=>
2020-04-13 16:43:31 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.evohome_rf
2020-04-13 16:43:31 WARNING (MainThread) [custom_components.evohome_rf.sensor] Found a Device (STA), id=34:064023, zone=None
2020-04-13 16:43:53 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event platform_discovered[L]: service=load_platform.sensor, platform=evohome_rf, discovered=>
2020-04-13 16:43:53 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.evohome_rf

From the second line, you’ll see to STDOUT:

16:47:41.940 || VNT:168090         | GWY:082155         |  I | message_31e0     | 00000000   || {'unknown_0': '0000', 'state': False, 'unknown_1': '00'}
16:48:06.081 || CTL:145038         | BDR:237335         | RQ | actuator_enabled | 00         ||
16:48:08.075 || CTL:145038         | BDR:237335         | RQ | actuator_enabled | 00         ||
16:48:10.084 || CTL:145038         | BDR:237335         | RQ | actuator_enabled | 00         ||
16:48:10.355 || STA:064023         | <announce>         |  I | temperature      | 000906     || {'temperature': 23.1}

What do you get from: cat ~/.homeassistant/home-assistant.log | grep evohome_rf

I am getting this:

plmicia@brix:~$ cat /usr/share/hassio/homeassistant/home-assistant.log | grep evohome_rf
2020-04-13 18:22:58 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for evohome_rf which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
2020-04-13 18:23:30 INFO (MainThread) [homeassistant.setup] Setting up evohome_rf
2020-04-13 18:23:31 WARNING (MainThread) [custom_components.evohome_rf] Store = {}
2020-04-13 18:23:31 WARNING (MainThread) [custom_components.evohome_rf] Config =  OrderedDict([('serial_port', '/dev/ttyUSB0'), ('packet_log', '/usr/share/hassio/share/packets.log')])
2020-04-13 18:23:31 INFO (MainThread) [homeassistant.setup] Setup of domain evohome_rf took 0.2 seconds.

And the output from these two (from inside the container):

ls /dev/ttyUSB0
tail /usr/share/hassio/share/packets.log

I think ('serial_port', '/dev/ttyUSB0'), is wrong. Either it is a different port, or not there at all.- my fault for not throwing a decent error in such cases.

plmicia@brix:~$ sudo docker exec -it homeassistant ls /dev/ttyUSB0
/dev/ttyUSB0

Still no such file

ttyUSB0 looks to be right.

  • I can see data with screen command,

  • with dmesg | grep tty I receive correct results @ ttyUSB0 when HGI80 is connected or disconnected

In the mean time I installed fresh Ubuntu Server and HA with docker again, to be sure I did not messed anything during previous trails - unfortunately no difference :frowning: .

Can you do the above from within the docker container?

Yes and this gives me the same results as in host.

Then I am stuck.

Anyone else can help?

Hi! 1st thing, thx a lot for this effort!

I just got myself an HGI80, but am I not suppose to “pair” it with the controller? I noticed a button on the HGI80, but manual doesn’t mention it, and controller doesn’t seem to offer to pair anything else than valves, boiler, and water tank.

Is it then correct that the HGI80 allows you to eavedrop all communications around?

Thank you

Hi Michal,

I am running almost the exact same config as you (hass.io installed on ubuntu server 18.04 lts running on an intel host). If you look at my activity in this thread, you can see I was overthinking how it would work on hass.io but it turned out to be super easy. Hass.io passed the hgi-80 through without any special configuration on my part and it just worked like any other custom component.

Anyhow, this is my config (not too exciting, but you should make sure to choose a folder that is seen by hass.io with the correct relative path in hass.io like /share/. You may just want to copy the below word for word, as I think your /usr/share path that you are using will be an invalid path to hass.io from inside the container. It looks like you are using the path on the host rather than the path in the container. I hope that’s your issue.

evohome_rf: 
  serial_port: /dev/ttyUSB0
  packet_log: /share/packets.log

All I had to do is plug the hgi-80 in to my server, I’m not sure I even did the pip install evohome. If I did, I did it on the bare host. Basically the completely standard install instructions should work for hass.io.

Did you install hass.io from the “install on a generic linux host” instructions here or did you do something strange like make a docker container and then install hass.io inside that docker container (you know hass.io runs in a docker container already, right? So you wouldn’t want to install it inside another docker or you’d have nested dockers and that would be a mess).

You do not need to pair the hgi80. There is no security at all with the evohome RF protocol!

You do not need to pip install evohome, the custom component will do that via it’s manifest.

Good luck.

@plmicia, I’m not sure about Docker, but I have it fully working with Podman (which offers many improvements over Docker). Here is my working Ansible snippet to create the container:

    - name: "Create container"
      become: yes
      become_user: home-assistant
      command:
        argv:
        - "/usr/bin/podman"
        - "create"
        - "--name=home-assistant"
        - "--network=host"
# note that podman will only save host major and minor ID of device and dest path, original device name provided below is not saved
# https://github.com/containers/libpod/issues/4550
# https://www.thegeekdiary.com/how-to-set-custom-device-names-using-udev-in-centos-rhel-7/
        - "--device=/dev/zwave:/dev/zwave"
        - "--device=/dev/hgi80:/dev/hgi80"
# if the user only has access rights via a group, accessing the device from inside a rootless container will fail. The crun(1) runtime offers a workaround for this by adding the option --annotation run.oci.keep_original_groups=1
#        - "--annotation=run.oci.keep_original_groups=1"
        - "--env-file=/home/home-assistant/.env"
        - "--volume=/home/home-assistant/config:/config"
        - "homeassistant/home-assistant:stable"

Here is my udev rule to setup hgi80:

SUBSYSTEM=="tty", ATTRS{idVendor}=="10ac", ATTRS{idProduct}=="0102", SYMLINK+="hgi80", OWNER="root", GROUP="home-assistant"

Then HA is configured that way:

evohome_rf:
  serial_port: /dev/hgi80
  packet_log: /config/packets.log

I hope it helps!

Yes, you can tell if your neighbour is having a shower, on holidays, etc.

The protocol is called RAMSES-II, and is based upon the Residential Network Protocol at the RF layer. AFAICT, there is no authentication/confidentiality in the protocol by default, if at all.

So unfortunately, it is not limited to eavesdropping. You can play havoc with your neighbour’s system if you choose - rename zones, turn heating on/off, change their schedules, etc. With evofw3, you’ll be able to impersonate the controller, and thus do a lot worse than that.

Because of the above, I have added blacklisting / whitelisting to the underlying library, so that you can ignore your neighbour’s devices. BTW, non-Honeywell kit also use this protocol - for example, my ventilation system (from Nuaire) does.

It seems >95% of the evohome portion of the RAMSES-II protocol is now decoded, including OpenTherm - although the documentation is still a WIP.

Before next winter (I hope), it will be possible to have evohome integrate with HA, without needing any internet access - you can drop your TCC account!

Regarding the client library that the HA integration uses to eavesdrop these packets, layer 1 (packet validation, black/white-listing) is finished, layer 2 (parsing of packet payloads into JSON messages) is 90-95% complete, and layer 3 (system state) is still a WIP - say 50% complete.

If anyone wants to have a play with the library, the refactor branch of the repo is way ahead of (but incompatible with) the version of the library used by HA.

I have been working with some great guys who are coming up with evofw3 an alternative to a HGI80 using a arduino base - it will be cheaper, and offer more functionality.

Out of curiosity, what do you think the effect on battery life of the TRV’s is when using HGI-80 custom component in addition to the standard evohome integration? Does it double the polling on the TRV’s?

There is no effect - battery-operated devices do not listen, except once per sync_cycle (approx 3 mins), and I’ve never managed to get any on them to respond to a HGI80.

I may be able to get them to listen to a nanoCUL device running evofw3, but that is a WIP.

1 Like

I have been trying to find somewhere I can buy an HGI80 so I can have a play with this but no luck so far. Drawing a blank in Google is a new experience! I have a standard Evohome system (ie the Wifi controller with the colour screen) and a 12 zone setup, so keen to try this new CC out. Can anyone share a link for the USB RF receiver I need?

Of course, it is possible I am misunderstanding and I just need a Wifi-enabled Pi - but I assumed the receiver would need to connect to my HA hardware.

Apologies if this has already been covered - if so, please just post a link to the relevant posting.

Thanks
Steve

It’s all in this thread, but worth putting here

You’ll need this hardware (about £30), and this firmware (uploaded using Arduino IDE).

Make sure the HW is 868 MHz, and not 433 MHz:

1 Like

Hi guys,

I’m interested in controlling Evohome from Home Assistant. I’ve held off for this project over a year (due to other priorities) and was initially going to do this on Domoticz. However I just have a few questions about doing this in Home Assistant.

  1. Is it possible yet to configure a climate device that controls the Evohome zone thermostat?
    I have a temperature sensor in every zone (custom, non Evohome) that needs to be paired as the zone thermostat in Evohome. In Domoticz this is possible.

  2. Like others, I too have problems configuring the HGI80 on a Raspberry Pi, with the same errors about firmware and not a single thread anywhere shows the solution. Anyone know?

[   15.244937] usb 1-1.1.2: Direct firmware load for ti_usb-v10ac-p0102.fw failed with error -2

This firmware is nowhere to be found and everyone that seems to have fixed it never shared their solution…

You don’t need an HGI-80 to control the Evohome climate zones. Have you tried the standard Evohome (non HGI80) component yet?