Guys, I am aware that the controller is not yet exposed via HA - this is on my to do list, but I have some other projects on the go to complete first, including adding functionality to the existing (RESTful) evohome integration.
Having some time tried to startâŚ
I.e. I see âhoneywellâ device on my âIntelNUCâ.
root@Debian10:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp.
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 014: ID 10ac:0102 Honeywell, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I also installed the âccâ in âhass.ioâ.
Plus followed this to install on âDebian LXCâ.
Also I made entry in â.yamlâ.
But not sure what I should do next.
Ex. in âhass.ioâ log I see something like that:
Config = OrderedDict([('serial_port', '/dev/hgi80'), ('packet_log', '/home/zxdavb/packets.log')])
December 20, 2019, 11:04 PM custom_components/evohome_rf/__init__.py (WARNING)
Store = {}
December 20, 2019, 11:04 PM custom_components/evohome_rf/__init__.py (WARNING)
And details:
Log Details (WARNING)
Fri Dec 20 2019 23:04:57 GMT+0100 (Central European Standard Time)
Config = OrderedDict([('serial_port', '/dev/hgi80'), ('packet_log', '/home/zxdavb/packets.log')])
Log Details (WARNING)
Fri Dec 20 2019 23:04:57 GMT+0100 (Central European Standard Time)
Store = {}
P.S. â/dev/hgi80â is device created according earlier mentioned instruction (git) to allowing âusb passthroughâ on âproxmoxâ.
When I have this logging:
logger:
logs:
homeassistant.components.evohome_rf: debug
evohome: debug
I get these log entries (grep evohome):
(venv) dbonnes@vm-builder:~/home-assistant$ cat ~/.homeassistant/home-assistant.log | grep evohome
2019-12-21 10:32:46 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 do experience issues with Home Assistant.
...
2019-12-21 10:32:47 WARNING (MainThread) [custom_components.evohome_rf] Store = {}
2019-12-21 10:32:47 WARNING (MainThread) [custom_components.evohome_rf] Config = OrderedDict([('serial_port', '/dev/ttyUSB0'), ('packet_log', '/home/dbonnes/packets.log')])
2019-12-21 10:32:47 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=evohome_rf>
...
2019-12-21 10:33:03 INFO (MainThread) [evohome.logger] 2019-12-21T10:33:03.204188 MSG: || 047 | RQ | | STA:064023 | CTL:145038 | | zone_config | 001 | 07 || {'zone_idx': '07'}
2019-12-21 10:33:03 INFO (MainThread) [evohome.logger] 2019-12-21T10:33:03.268492 MSG: || 045 | RP | | CTL:145038 | STA:064023 | | zone_config | 006 | 07100... || [{'07': {'min_temp': 5.0, 'max_temp': 35.0, 'flags': {'local_override': True, 'openwindow_function': True, 'multi_room_mode': False, '_bitmap': '0b00010000'}}}]
...
2019-12-21 10:33:09 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event platform_discovered[L]: service=load_platform.binary_sensor, platform=evohome_rf, discovered=>
2019-12-21 10:33:09 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.evohome_rf
2019-12-21 10:33:09 WARNING (MainThread) [custom_components.evohome_rf.binary_sensor] Found a Device (TRV), id=04:189076, zone=None
Donât worry about the WARNING - I do that just so they stick out.
The [evohome.logger] lines are what you want - these are the packets being sniffed.
The Found a Device (STA), id=34:064023, zone=07 lines are HA entities being created.
Some tips:
- confirm you have the device :
ls /dev/hgi80 - set the packet log location correctly - I doubt if
/home/zxdavb/is on your system - can you:
cat homeassistant.log | grep evohome
Do this to check that the HGI80 is working OK:
screen /dev/hgi80 115200
You should see output like this:
045 RP --- 01:145038 34:064023 --:------ 2309 003 070834
074 I --- 04:189076 --:------ 04:189076 30C9 003 0007D8
088 I --- 04:189082 --:------ 04:189082 30C9 003 000957
063 I --- 12:010740 --:------ 12:010740 0008 002 0000
For those using a nanoCUL - the current recommended firmware is: https://github.com/brucemiranda/evofw2/tree/fifo
Note the specific fifo branch (which is currently 2d since last commit)
You will still get the manchester decoding errors - this is not a real problem for us.
2019-12-15T18:39:14.151002 --- RQ --- 22:243559 13:195751 --:------ 2309 003 0008FC
2019-12-15T18:40:29.225940 --- I --- 13:000432 --:------ 13:000432 3EF0 003 00C8FF
2019-12-15T18:41:01.216902 --- I --- *ERR_MANCHESTER_ENCODING*
2019-12-15T18:41:01.281851 --- RP --- *ERR_MANCHESTER_ENCODING*
Firmware works fine when reading the serial port directly. Home-assitant just doesnât want to load the plugin anymore, did work the first time and canât seem to figure out where the error is coming from.
Dec 21 14:19:23 ha hass[4930]: 2019-12-21 14:19:23 ERROR (MainThread) [homeassistant.setup] Setup failed for evohome_rf: Unable to import component
Can you do a:
pip list | grep evohome
pip list | grep serial
You shoudl get 
(venv) dbonnes@vm-builder:~/home-assistant$ pip list | grep evohome
evohome 0.0.7
(venv) dbonnes@vm-builder:~/home-assistant$ pip list | grep serial
pyserial 3.4
pyserial-asyncio 0.4
Maybe something to do with HA - Iâm getting:
2019-12-21 14:31:42 ERROR (MainThread) [homeassistant.setup] Setup failed for cloud: Unable to import component
2019-12-21 14:31:44 ERROR (MainThread) [homeassistant.setup] Setup failed for logbook: Unable to import component
Nvermind, found the issue. Since HA is dropping support for Python 3.6 I had to compile 3.7 from source. I was missing ncurses-devel on my machine, so curses was not compiled in, but is required by the evohome plugin.
Found out by adding some extra hardcoded logging in HAâs setup.py.
Getting some consistent results now 
Still getting lots of errors on the evohome library side though:
Dec 21 18:21:55 ha hass[8177]: 2019-12-21 18:21:55 ERROR (MainThread) [evohome.logger] ASSERT failure, raw_packet = >>> 065 RP --- 10:138822 01:187666 --:------ 3EF0 006 0000100200FF <<<
Dec 21 18:21:55 ha hass[8177]: Traceback (most recent call last):
Dec 21 18:21:55 ha hass[8177]: File "/srv/homeassistant/lib/python3.7/site-packages/evohome/message.py", line 1019, in payload
Dec 21 18:21:55 ha hass[8177]: self._payload = payload_parser(self.raw_payload) if payload_parser else None
Dec 21 18:21:55 ha hass[8177]: File "/srv/homeassistant/lib/python3.7/site-packages/evohome/message.py", line 237, in wrapper
Dec 21 18:21:55 ha hass[8177]: result = func(*args, **kwargs)
Dec 21 18:21:55 ha hass[8177]: File "/srv/homeassistant/lib/python3.7/site-packages/evohome/message.py", line 369, in actuator_enabled
Dec 21 18:21:55 ha hass[8177]: assert len(payload) / 2 == 3
Dec 21 18:21:55 ha hass[8177]: AssertionError
Iâll see if I can find some time next week to dive into the repository and see if I can help on implementing features.
Ignore the ASSERT errors - this is because the code is beta!
They are packets I donât expect to see - if you send me a copy of your packets.log file, I can sort it (eventually).
In your case, I see it an OpenTherm Bridge, which I havenât made any provision for (I donât have an OTB).
There is a new CC (with a corresponding updated client).
So I installed it and it seems to have started right up. Nothing very special needed for hass.io fortunately, other than just to provide a correct relative path for the internal container filesystem (I used /share/packet.log)
Iâve got a ton of sensors to sort through. How do I tell which one is which? Would be interesting to compare them to existing ones⌠I guess I could graph all the old and new ones and compare if thereâs no easy way.
It should (eventually) show the parent zone in the device state attributes. Are you using a HGI80?
There is an issue with the nano firmware where commands canât be sent.
See:
04: is a TRV, and it is in the main room.
Yes, HGI-80.
Okay, the parent_zones are showing as null now, but I will wait and see. No way to tell which sensor is which within a zone once the parent_zone starts populating?
Itâs interesting, some of the TRVâs are showing much higher temps than any of the zones⌠Iâm assuming those are the ones that use external thermostats since they are covered by curtains or in the floor with the convectors.
Each Zone has an âauthorativeâ device that is the zone temp - say a round thermostat. The TRVs temps can vary widly. Have a look at Honeywell evohome via RF (HGI80/HGS80) for an example.
With HA, you can put the zone temp, and teh device temps on the same graph.
The parent zones may take a while - the system has to wait fro the right packet to appear - some of them are only sent once a day.
1 Like
Are u using the very latest version - there was a bug with parent_zones, now fixed.
I cloned it about 2 hours ago so I think so. We will see what happens overnight.
In my case I could not see HGI80 âusbâ on CT Debian installed on âproxmoxâ.
There is an info on âproxmoxâ forum that in case CT usb-devices (with non-free firmware) - it is hardly to get them working⌠In most cases it is not possible to make âUSB-PassthroughââŚ
The only suggested solution is to use VMâŚ
So now I must install âDebianâ as VM. And try againâŚ
Maybe - in future - someone will find/advice solution to have working âHGI80â on CT installed systemsâŚ
Custom serial port config seems to be ignored in the new version. Serial port is passed through as en arg, but is read as a function param. So it always falls back to /dev/ttyUSB0.
Iâve altered the library to the following, which works:
self.serial_port = kwargs.get("serial_port", port_name)
Good spot! Will sort it out.