I don’t mind putting it on my live hass.io instance, but I’m just not sure how to go about it… Is it enough just to install the custom component? Will hass.io take care of installing the needed libraries and arranging the passthrough from the docker container to the HGI80’s USB device on the OS level? Am I just overthinking it? I just don’t want to break anything so I want to be sure I’m doing it properly.
I am running both integrations in one instance of HA.
Just install the custom component - it tells HA what libraries to install (or it should, anyway). The pass through is beyond me, I’m afraid - the integration expects to see /dev/ttyUSB0 or similar.
If it ‘breaks’ HA, just remove the custom component.
Okay will try it. How are you running HA out of curiosity? Just straight on the OS with no containers?
All my systems are dev environments running in vmware ESXi VMs (Ubuntu), or LXC containers (OpenWrt).
Just add a custom_components folder to your config directory, and put evhome_rf (the repo is called evohome_cc) in a folder under that called evohome_rf`, see the readme, here:
Don’t get confused: the repo is called evohome_cc, but the folder should definitely be custom_components/evohome_rf
I’ve been giving this a try but don’t seem to be able to get it to work.
When setting up the custom component, I saw it pulled in the evohome lib. Added ptvd & serial and all error’s where gone, but however no data was returned. Always None. Starting the evohome_rf manually gives tons of data going through so the nano and cc1101 are working properly. When restarting HA I do see a:
Dec 14 22:05:03 hassbian hass[12175]: 2019-12-14 22:05:03 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Dec 14 22:05:03 hassbian hass[12175]: Traceback (most recent call last):
Dec 14 22:05:03 hassbian hass[12175]: File "/srv/homeassistant/lib/python3.7/site-packages/evohome/__init__.py", line 140, in start
Dec 14 22:05:03 hassbian hass[12175]: self._output_fp = open(self.output_file, "a+")
Dec 14 22:05:03 hassbian hass[12175]: PermissionError: [Errno 13] Permission denied: 'packets.log'
I’ve touched packets.log in the evohome python path and in the custom components dir and set it to 777 but it never succeeds … any idea where it’s trying to create it and under which user?
HA is running in a virtual env as homeassistant.
Hi @Tjeerd,
Thanks for testing. I have addressed this issue.
I have updated both the custom_component and the client library - please fetch the latest version of each repo.
Please change your configuration.yaml as follows:
evohome_rf:
serial_port: /dev/ttyUSB0
packet_log: /home/zxdavb/packets.log
Note that port has changed to serial_port.
The specific values for serial_port and packet_log are up to you.
ptvsd has been removed. pyserial-asyncio has now been added as a dependency.
Let me know how you get on!
That did the trick! data is coming in now.
Woot! you’re the first person beside me to have it up and running - I presume you have a HGI80?
To answer your question:
This system ‘learns’ by:
a) eavesdropping RF packets - it has to wait for particular packets to be sent before it knows certain useful things, like the controller ID - it treats the first one it sees as your controller (so if your neighbour has one…)
The list of devices (controller, HR92s, T87RFs, CS92, BDR91s, etc) is enumerated over time, most will be picked up in one sync cycle, approx 3 mins.
b) sending queries to devices that it discovers (not all devices -especially battery-powered devices will respond to useful queries) - some data (e.g. battery levels) is sent only once every 24h - so it can only use method a) for that data
The Climate/WaterHeater entities you’re used to seeing in HA (when you use the supported, RESTful integration): the System (which has a 1-1 relationship with a controller), the DHW (as CS92), and the Zones are extrapolated from this data - but not yet exposed to HA via this integration.
HA doesn’t (really) deal with devices so much as entities. All of the above is implemented as a Sensor or a BinarySensor - there are no Climate / WaterHeater entities (you can use the RESTful version of evohome fro that), but I intend to at a future time.
Yes, there is some controller data missing, but this is more operating mode that sensor data.
Currently we are in the proof of concept stage - the eventual plan would be to replace the RESTful API with a functional superset that does not require the evohome system to access the Internet at all.
… or even replace the controller altogether with HA?
Please feedback any questions you may have, issues you find, etc.
Specifically:
sensor_00.demand is an orphan - it is not the controller, nor a zone (a zone’s demand appears to be the highest of all it’s constituent devices)
sensor_FC.demand is the system demand (of heat) - this directly affects the TPI cycle - it appears to be the highest of all zone demand.
Well-spotted! Without the exact figure, I cannot say 100% what’s going on, but here are two reasons I know of when a zone / zone device may call for heat even though the zone temp is above its setpoint:
- is it still in the dead band (less than 0.5C above the setpoint temp)
- it is pre-heating the zone
Note the call for heat (shaded area) in the RESTful version of evohome is under-represented - I am planning to remove it - the only way to get that data will be to use this integration.
Nah, I couldn’t get the HGI80 here for a reasonable enough price so I went with a nano and CC1101. It was my goal to remove complete internet connectivity from the controller even though it works ok, I am not happy with something that is dependant on something 3rd party. As for getting rid of the controller all together, I am not a big fan of that, as an option it would be awesome I guess but I’d rather live by enhancing and adding then removing the basics of controlling things that my wife is used to 
It would be nice to have complete local control either from the controller or from the your component.
I’ve used this before: https://github.com/smar000/evohome-Listener
The implementation is ok through MQTT but fails to receive / decode all messages. Not sure yet that is because last night I’ve added a high gain antenna. I am running this branch for the nano: https://github.com/ghoti57/evofw2/tree/fifo this allows me to send messages as well.
The component works rather nice!
sensor_FC.demand is not picked up though.
A quick glance also shows that the controller is broadcasting periodically the setpoints and temps for all zones in numerical order. Perhaps we can steal the controller temp from that one?
Dec 15 00:40:21 hassbian hass[1520]: 2019-12-15 00:40:21 INFO (MainThread) [evohome.logger] 2019-12-15T00:40:21.915176 MSG: || --- | I | | CTL:132956 | | >broadcast | sync_cycle | 003 | FF069A || {'device_id': '01:132956', 'countdown': 169.0}
Dec 15 00:40:21 hassbian hass[1520]: 2019-12-15 00:40:21 INFO (MainThread) [evohome.logger] 2019-12-15T00:40:21.985056 MSG: || --- | I | | CTL:132956 | | >broadcast | setpoint | 012 | 00080... || [{'00': {'setpoint': 20.5}}, {'01': {'setpoint': 18.5}}, {'02': {'setpoint': 22.0}}, {'03': {'setpoint': 5.5}}]
Dec 15 00:40:22 hassbian hass[1520]: 2019-12-15 00:40:22 INFO (MainThread) [evohome.logger] 2019-12-15T00:40:22.056604 MSG: || --- | I | | CTL:132956 | | >broadcast | temperature | 012 | 00090... || [{'00': {'temperature': 23.19}}, {'01': {'temperature': 20.02}}, {'02': {'temperature': 21.29}}, {'03': {'temperature': 21.58}}]
00 = controller temp in this case that controls the living room TRV instead of the TRV itself.
These temps should match the TRV reported temps that should be picked however with my nano and cc1101 I am not sure if I receive all messages. Finding a way to overload those temps over the TRV’s reporting temps would be nice. I noticed that in the graphs I have some dead spots.
Next week I’ll spend some more time to dig through messages.
Auto populating works fine for now but I am not sure if you can stick to it when you also want to tie in the controller / parent zones etc. From the data I found it doesn’t look like it’s broadcasting the relationships or zone order from the controller itself.
I see the nano/cc1101 as the best solution for people, mainly on the basis of price/availability.
Presently, it is known to drop a lot of packets (say 25% - I have both a HGI80, and a nanoCUL/cc1101), and I think radio isn’t as sensitive as a HGI80, so that may be why your FC demand isn’t being picked up? Have a look at your packet.log file for errors, “Packet structure is not valid”.
I am working with the devs of the nano/cc1101 firmware - they are doing good work there -
I expect the nano/cc1101 to become more reliable.
The plan is broadly:
a) add sensors complementary to the (current) RESTful version of evohome integration
b) replace the RESTful integration altogether (so you can stop your controller from accessing the Internet if you want)
c) replace the controller (this is a long way off)
I chose go direct, rather than via MQTT, I guess that is the main difference between that code and mine. Also, I believe my code decodes more packet types (and there are some I’ve yet to add - schedules / fault logs / opentherm).
The client library already does this - its just that the custom component currently chooses not to expose it to HA.
To be clear, this is zone 00, and not a device temp. Specifically, there is no way to get the controller temp that I know of, but you can get the temps of the zones. And, if one of the zones is using the controller as a temperature sensor, then you’ll get that temp, but the distinction of a zone’s vs a sensor’s temp is important, if you think about it.
There is no way of knowing 100% where Zone 00’s temp came from.
Because I wasn’t clear on this distinction - I am planning a major re-write of the client library before progressing with any development of the HA custom component.
You can auto-populate climate entities, no problem. In any case, I intend to save them in the HA DB, so if you restart HA, you won’t have to wait fro them to re-appear.
This data is available to harvest, it just takes some work - you can’t simply ask the controller for it, you have to work it out by eavesdropping - having said that, I see its not working at the moment (see ‘parent zone’, below) - I will fix it soon enough.
I think your right about the dropped packets. I see a bunch of manchester encoding errors coming by from time to time. I was wondering wether it was because of the nano or interference from my alarm panel. I know that an empty battery in one of the HR92’s makes the alarm panel go bananas ( it causes the RF-Portal to be flooded and since that is merely a transparent device, it’s buffer overflows ).
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*
2019-12-15T18:41:01.346790 --- RP --- --:------ --:------ *ERR_MANCHESTER_ENCODING*
2019-12-15T18:41:01.414583 --- RP --- 44:000769 *ERR_MANCHER
2019-12-15T18:41:01.478125 *E
I’ve been following the development of nano code for over a year now but don’t see much movement … was thinking there’s not enough interest in it.
Thanks for your work!
They’re active again - the last change to the firmware repo I’m using was 2h ago.
BTW, I’ve worked out why the parent zone isn’t appearing in the device state attributes - will submit a fix soonish.
What firmware are you using? I’ve received my cc1101 stick and flashed it with the https://github.com/ghoti57/evofw2 firmware. It seems to be receiving messages now.
Still looking out for a good deal for a HGI-80, they seem to be very expensive and not easy to find.
The current recommendation - and this is a fast-moving target - is: https://github.com/ghoti57/evofw2/tree/fifo
Note the specific fifo branch (which is currently < 24h since last commit)
I’ve my HGI80 (~70EUR; could not get cheaper…).
And - as I wrote in earlier post - want to connect it to ‘Hometronic’ system (main unit - HCM200D) together with ‘hass.io’.
I have ‘hass.io’ installed on ‘Proxmox’ on the same ‘Proxmox’ I have ‘Debian Buster’.
Now I’m unsure how to proceed…
What I did up to now:
- installed ‘evohome_rf’ on my ‘Debian’;
- copied all the files to ‘custom_components/evohome_rf’.
- tryied to create entry in ‘.yaml’…
But I stop at the ‘serial_port: /dev/ttyUSB0’ entry…
Not sure which port/name I should use.
Any idea?
Up to now I had no need to use USB port for ‘hass.io’ or for ‘Debian’…
@dariusz I am very keen to see how you get on.
I have no ideas- I have used VMware ESXi & even Oracle VirtualBox, but never ProxMox.
Generally, you have to get the Host’s USB device into the VM, a quick Google search gives:
https://pve.proxmox.com/wiki/USB_Devices_in_Virtual_Machines
Then i will show up in Debian as (likely) /dev/ttyUSB0
In my case it is ‘lxc’, so I’ll try with >> THIS << manual…
But later-on…
I need to read more about ‘Proxmox’ configurations, adding USB, etc,…
It was bargain… Owner was using it with ‘Tahoma’ integration. But no longer interested to continue this project…
Well done - I someone else (who knows much more about this than me) saying good things about hometronic and the chances of success of integrating it with my code.