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

What USB ports do you see under the button ‘Hardware’ in ‘hass.io’?

This will, of course, differ based on the underlying hardware. I’m running on a mac mini, so you’ll see the ports that exist on a mac mini in addition to my 2 usb devices, the HGI-80 at /dev/ttyUSB0, and my Aeotec Zwave Stick at /dev/ttyACM0

serial:
    /dev/ttyS31
    /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
    /dev/ttyS27
    /dev/ttyS6
    /dev/ttyS30
    /dev/ttyS29
    /dev/ttyS7
    /dev/ttyS13
    /dev/ttyS19
    /dev/ttyS25
    /dev/ttyS17
    /dev/ttyS22
    /dev/ttyS10
    /dev/ttyS15
    /dev/ttyS3
    /dev/ttyS4
    /dev/ttyS12
    /dev/ttyS1
    /dev/ttyS5
    /dev/ttyS28
    /dev/ttyS23
    /dev/ttyS8
    /dev/ttyS18
    /dev/ttyS20
    /dev/ttyS14
    /dev/ttyS2
    /dev/ttyS21
    /dev/ttyS26
    /dev/ttyS16
    /dev/ttyS24
    /dev/ttyACM0
    /dev/serial/by-id/usb-0658_0200-if00
    /dev/ttyS11
    /dev/ttyS9
    /dev/ttyUSB0
    /dev/ttyS0
input:
    Power Button
    Video Bus
    Apple Computer, Inc. IR Receiver
    Sleep Button
    HDA NVidia HDMI/DP,pcm=7
    HDA NVidia HDMI/DP,pcm=3
    HDA NVidia Headphone
    HDA NVidia HDMI/DP,pcm=8
    Unicomp Inc Unicomp R7_2_10x_Kbrd_v7_37
disk:
gpio:
    gpiochip496
audio:
    0:
        name: HDA-Intel - HDA NVidia
        type: NVidia
        devices:
            [object Object]
            [object Object]
            [object Object]
            [object Object]
            [object Object]
            [object Object]
            [object Object]
            [object Object]
            [object Object]
            [object Object]

So, it’s been a couple days and parent zones still haven’t shown up, just fyi…

EDIT: Well, I just noticed this in the logs after a reboot, so it does appear to be making the association now, but the information doesn’t seem to be making it into the sensor attributes (?yet)


Found a Device (TRV), id=04:136505, zone=01

1:31 AM custom_components/evohome_rf/sensor.py (WARNING) - message first occured at 1:31 AM and shows up 2 times

Found a Device (TRV), id=04:136513, zone=01

1:31 AM custom_components/evohome_rf/sensor.py (WARNING) - message first occured at 1:31 AM and shows up 2 times

Found a Device (TRV), id=04:136497, zone=07

1:30 AM custom_components/evohome_rf/sensor.py (WARNING) - message first occured at 1:30 AM and shows up 2 times

Found a Device (TRV), id=04:136499, zone=07

Well, looks like installation on ‘Proxmox, has some fault or bug…
Does not matter what I change/set-up/add I always see 4 ports: ttyS0, ttyS1, ttyS2, ttyS3.
But no one of them is useful…

Supporting your super specific proxmox setup seems a little out of scope for this library doesn’t it? There might be better places to try and find help for your specific problem.

Yeah, there’s no issue with installation on Proxmox, there is an issue with Proxmox not properly dealing with your USB devices and passing them through to the VM. I suggest you take it up with the Proxmox folks.

Yes, I was expecting that as a piece of cake… But looks like it is not so easy.
I’ll check with other forums, then return.
Or maybe I’ll find other solution…

I just ordered the needed hardware (CC1101 868mhz) and will test as soon as it arrives. Looking forward to dropping the cloud on Evohome!

1 Like

Hi there,

Tried the libraries as well, great stuff. Thank you David.

I have the following setup:

  • Raspberry Pi 3B
  • Honeywell HGI80
  • Honeywell Gateway to connect to the cloud
  • Home Assistant installation directly on the OS, running in a Python venv

Data is coming in and seems correct. I created some graphs (in Dutch) with the temperature readings from the HGI80 and the Gateway next to each other. They almost match, has to do with roudings I assume.

The only problem I have is that the evohome_rf client seems to have a memory leak. The Pi crashes every 6-8 hours. The memory usage of the RF client increases over time.

The command I use to start the client (running in a screen):

python3 client.py -o /home/homeassistant/evohome_packets.log

Also the -o parameter is not mentioned in your documentation, I discovered it in the code and it does not work without it. Maybe good thing to add.

Hope to see the libs officially integrated in HA!

Regards,

Bobby

The evohome_rf code is in the midst of a significant refactor, and the HA custom_component will follow.

So bugs in the current (master branch) version will not be addressed (although I will check the -o on the new code).

FYI you could try the new client (refactor branch) CLI, but I doubt it will work with the HA custom component:

In your graphs, I plan for the shaded area (call for heat) in the official evohome integration to be removed unless I can find a way to make it more accurate.

The temps are a long story - HA’s official (RESTful) component shows the zone temps, the RF custom component shows device temps - these do not have to match. Specifically, only one of the devices in a zone is used for the zone temperature.

The new code will tell you which of these devices it is, for example, have a look at zone 1 (‘Front Room’) - notice zone 0 is missing a sensor (it is the controller):

{
	"controller": "01:145038",
	"boiler": {
		"dhw_sensor": "07:045960",
		"tpi_relay": "13:237335"
	},
	"zones": {
		"00": {
			"name": "Main Room", "temperature": 20.38,
			"sensor": None, "devices": ["04:056061"]
		},
		"01": {
			"name": "Front Room", "temperature": 20.23,
			"sensor": "34:092243", "devices": ["04:056059", "04:056053"]
		},
		"02": {
			"name": "Kitchen", "temperature": 18.39,
			"sensor": "04:189076", "devices": ["04:189076"]
		},
		"03": {
			"name": "Bedroom", "temperature": 18.83,
			"sensor": "34:064023", "devices": ["04:056057"]
		},
		"04": {
			"name": "Beans Room", "temperature": 17.77,
			"sensor": "34:136285", "devices": ["04:189082"]
		},
		"05": {
			"name": "Noos Room", "temperature": 18.7,
			"sensor": "34:205645", "devices": ["04:189080"]
		},
		"06": {
			"name": "Bathroom", "temperature": 18.67,
			"sensor": "04:189078", "devices": ["04:189078"]
		}
	},
	"thermometers": {
		"34:092243": 20.23,
		"34:136285": 17.77,
		"04:189080": 18.41,
		"34:205645": 18.70,
		"34:064023": 18.83,
		"04:056057": 17.27,
		"04:056059": 19.64,
		"04:056053": 19.75,
		"04:189082": 17.46,
		"04:189076": 18.39,
		"04:189078": 18.67,
		"04:056061": 19.59
	}
}

After long discussion on ‘github.com’ it looks like ‘hass.io’ on ‘proxmox’ is not supporting ‘TI USB 3410 or 5052 serial devices’.
But that is going to be solved - more here…

Some success - after updating to ‘hassOS 4.0’ and the HGI-80 connected I see something like this - see screen.
What next to do?
Remember - I’m using ‘Hometronic Manger HCM-200’ system…

Perfect!

@dariusz As your system is different from an evohome I wouldn’t mind seeing 24-48h of your packets.log file to see if I can learn more about decoding packet payloads - if you’re up for that, PM me a link.

All: I would also like to see any packet logs with a HM80, a HCE80, Opentherm bridge, etc. Or if anyone has a zone that is not a Radiator zone (e.g. UFH, Zone Valve, Electric Zone, etc.)

FWIW, there is a completely new version in development - much better in many ways, and easier to maintain - it will add a lot of functionality including:
a) schedules
b) fault logs
c) more parsers (OTB is on hold, pending logs from someone with OT)

Eventual plan is full functionality without needing the Vendor’s website.

If anyone is interested, I am working on this with some other people:

O.K. Thank you for reply… The system is running. So when more data - I can present.
See few 1st lines:

2020-01-14T19:07:21.838209 095 RQ --- 18:013457 03:217705 --:------ 10E0 001 00
2020-01-14T19:07:21.900230 095 RQ --- 18:013457 01:145038 --:------ 0004 002 0000
2020-01-14T19:07:21.962155 095 RQ --- 18:013457 01:145038 --:------ 000A 001 00
2020-01-14T19:07:22.023840 095 RQ --- 18:013457 01:145038 --:------ 2349 001 00
2020-01-14T19:07:27.457932 046  I --- 04:029297 --:------ 01:023389 3150 002 0000
2020-01-14T19:07:46.460278 051  I --- 04:041701 --:------ 01:023389 1060 003 0FFF01
2020-01-14T19:07:46.521611 049  I --- 04:041701 --:------ 04:041701 1060 003 00FF01
2020-01-14T19:08:02.960734 047  I --- 04:029297 --:------ 01:023389 1060 003 00FF01
2020-01-14T19:08:03.022854 046  I --- 04:029297 --:------ 04:029297 1060 003 00FF01
2020-01-14T19:08:09.458838 045  I --- 04:029113 --:------ 01:023389 1060 003 09FF01
2020-01-14T19:08:09.521280 045  I --- 04:029113 --:------ 04:029113 1060 003 00FF01
2020-01-14T19:08:10.459851 047  I --- 04:029297 --:------ 04:029297 30C9 003 0007DB
2020-01-14T19:08:14.957976 061  I --- 04:042926 --:------ 01:023389 2309 003 040898
2020-01-14T19:08:15.959145 046  I --- 04:029297 --:------ 01:023389 2309 003 00076C
2020-01-14T19:08:30.460338 065  I --- 04:041701 --:------ 01:023389 2309 003 0F07D0
2020-01-14T19:08:32.459507 075  I --- 04:044027 --:------ 04:044027 30C9 003 000856
2020-01-14T19:08:38.460779 088  I --- 04:029184 --:------ 04:029184 30C9 003 0003C5
2020-01-14T19:08:46.960163 045  I --- 04:029182 --:------ 01:023389 2309 003 010640
2020-01-14T19:08:52.960296 087  I --- 04:029184 --:------ 01:023389 3150 002 0A1C
2020-01-14T19:08:55.460405 070  I --- 04:044027 --:------ 01:023389 1060 003 06FF01
2020-01-14T19:08:55.524038 070  I --- 04:044027 --:------ 04:044027 1060 003 00FF01
2020-01-14T19:09:00.155786 049  I --- 01:023389 --:------ 01:023389 3150 002 FC7E
2020-01-14T19:09:04.028795 049  I --- 01:023389 --:------ 01:023389 1F09 003 FF0924
2020-01-14T19:09:04.092224 047  I --- 01:023389 --:------ 01:023389 2309 033 00076C0106400207D00307080408980608340708980807D00906400A03E80F07D0

Looks exactly the same as evohome. Looking forward to 1-2 days’ worth - may offer some insights.

Will provide a package log in a few days. Have both the HCE80 and OTB.

I see the package log is appending when HA is restarted. I’ll sent you a PM with my package log from the past month.

@Captain thanks for that, I see you’ve got UFH & OTB, so that’s great.

Your packet log broke my latest parsing supervisor - so that’s good too - I can make it more resilient from the lessons I’ll learn off the back of that.

There was a plan to have a rolling log - but the updates I was planning to make to the underlying client never eventuated - a big refactor occurred instead. For now, people may want to archive that file every 2-4 weeks or so.

This log is necessary for now, but will be disabled by default at some time in the future.

For those of you without HGI80 - you’ll see a lot of decoding errors - 99% of these don’t occur with a HGI80 - the guys who write the firmware are on the case, and things will improve.

1 Like

I can send you an electric UFH zone. I’m traveling right now but will send it when I get back. I also have some standard radiator TRV’s driving floor convectors if that’s of interest to you. And I have some round thermostats too if you need that.

@scstraus All logs will be gratefully received - the plan is to run them through my parsers, and try and remove any errors.

@Captain has given me a couple of days work, so no rush.

1 Like

I moved the configuration to other machine - does not matter about the reason…
Now I see some notification/error:
cc

What I have wrong?
The files are the latest version from ‘github.com’…
I have such files:

And .yaml settings:

# Evohome
evohome_rf:
  serial_port: /dev/ttyUSB0
  packet_log: /home/config/packets.log
  
  
logger:
  logs:
    homeassistant.components.evohome_rf: debug
    evohome: debug