Massive thanks to @zxdavb now have Evohome up and running in it’s own dedicated instance of HA.
Lets see what the next 24 hours brings in terms of data 
Just to says - if you are hoping I might help you, please include logs with your question, or PM them to me via some means, see: How to configure packet logging
I suggest from startup of HA, for about 10 minutes.
@dariusz there were issues in your log files other than those I mentioned - please send me up-to-date logs if you like.
New version of evohome_cc pushed - v0.5.8, using evohome_rf v0.5.8:
2021-02-21 17:07:14 WARNING (MainThread) [custom_components.evohome_cc] evohome_cc v0.5.8, using evohome_rf v0.5.8 - versions match (this is good)
Just pulled the new version!
Looking good.
Is there any way within the configuration.yaml file to include valve names ?
I am not sure what you mean.
In the same way that the controller is mapped to a specific device ID, be able to do the same for locations, rather than having to rely on learning the name eg.
schema:
controller: 01:0xxxxxx
lounge: 04:0554xx
Short answer - Yes, but I am not planning for people to use this feature (just look at the schema in the HA log).
TL;DR:
The HA ID of evohome devices is based upon its device ID (04:123456).
The HA ID of evohome zones is similar, but is a combination of controller ID, and zone_idx ( (01:123456_02)). Evohome zones are the only things with names, in the sense that - unless you change it via HA - this is their default friendly name.
In evohome, TRVs do not have names, only a device ID and parenthood. In HA, they have identifiers (unique_id, entity_id), friendly names, and attributes…
The parenthood of a device (e.g. what zone a TRV is a child of) is configurable via the schema - but this is not recommended by me, it favour of using discovery, simply because it may not be truth. Note the ID of a zone is a zone_idx, not a zone name.
In fact, it is common for people to find that their system is not configured the way they thought (!) - the most recent example I can think of is @phdelodder (I don’t think he’ll mind me saying).
In future, evohome_cc may leverage this feature across reboots of HA to reduce startup time (which currently is approx 2 mins).
Some people are having issues with their gateways not sending RQs - this will cause the issue you infer, above, but will also cause many other issues too (and so I question the value in the workaround you describe)…
My question to you is: what are you hoping to achieve - maybe we can find a better solution?
That’s true, on my side there where also issue, TRV’s not properly linked…
Adding persistency between reboots would be a nice addition indeed, first look at stabilizing and making in feature complete. Eg adding opentherm sensor, adding the custom service calls, …
I went back to version 5.5 as with 5.8 I cannot get any control over temperatures, especially HomeKit which did not seem to work anymore.
This was my 5.8 config:
evohome_cc:
scan_interval: 60
serial_port: /dev/ttyUSB0
config:
packet_log: /config/packet.log
enforce_allowlist: True
max_zones: 8
schema:
controller: 01:089644
allow_list:
- 01:089644
- 04:198610
- 04:201726
- 04:209836
- 04:209837
- 04:209838
- 04:209885
- 22:122681
- 13:085332
- 13:176228
The HA log indicates some errors too:
2021-02-22 08:25:13 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Controller, id={"01:089644": {"controller": "01:089644", "system": {"heating_relay": null}, "orphans": ["04:209837", "04:209838"], "stored_hotwater": {}, "underfloor_heating": {}, "zones": {"00": {"heating_type": null, "sensor": null, "devices": []}, "01": {"heating_type": null, "sensor": null, "devices": []}, "02": {"heating_type": null, "sensor": null, "devices": []}, "03": {"heating_type": null, "sensor": null, "devices": []}, "04": {"heating_type": null, "sensor": null, "devices": []}, "05": {"heating_type": null, "sensor": null, "devices": []}, "06": {"heating_type": null, "sensor": null, "devices": []}}}}
With 5.5 this is:
021-02-22 08:29:59 INFO (MainThread) [custom_components.evohome_cc.climate] Found a Controller, id={"01:089644": {"controller": "01:089644", "system": {"heating_control": "13:176228", "orphans": []}, "ufh_controllers": {}, "stored_hotwater": null, "zones": {"00": {"heating_type": "zone_valve", "sensor": "22:122681", "devices": ["13:085332"]}, "01": {"heating_type": "radiator_valve", "sensor": "04:209837", "devices": []}, "02": {"heating_type": "radiator_valve", "sensor": "04:201726", "devices": []}, "03": {"heating_type": "radiator_valve", "sensor": "04:209838", "devices": []}, "04": {"heating_type": "radiator_valve", "sensor": "04:209885", "devices": []}, "05": {"heating_type": "radiator_valve", "sensor": "04:209836", "devices": []}, "06": {"heating_type": "radiator_valve", "sensor": "04:198610", "devices": []}}}}
Also the packet log of 5.5 starts with a lot of RP/RQs, whereas with 5.8 that is not there. I use a HGI80.
Thanks David, really helpful to get that viewpoint.
The issue that I have currently is that the only way I get friendly names is to press the button the TRVs the auto population appears to be broken for my setup. Hopefully logs gathered over the past 8-10 hours can provide some insight.
With warmer weather I’m now in a position to start tinkering with the Evohome system a little more.
@Glanerbronx please PM me a set of logs so I can investigate.
A HA log, and a packet log - https://github.com/zxdavb/evohome_cc/wiki/4.-Troubleshooting
OK, there is a bug affecting HGI80s that stops them from transmitting - investigating.
4 Likes
Is there a ‘buy me a beer, coffee’ or ‘donate to my preferred charity’?
Seem to have ironed out my TX issues with the nanoCUL, see this and subsequent posts if you’re having similar issues, things been working pretty well for the last 24 hours.
Bug found - fix coming for HGI80s that don’t Tx most packets… version 5.9
I don’t need coffee (I have a good machine here), but I have just bought another £80 of evohome kit for test/dev, and I need to buy a OTB to test/dev against too…
If anyone wants to contribute to that, then PM me for a paypal transfer?
2 Likes
Fix pushed - feedback is welcome
Still not getting friendly name auto discovery with a HGI80. Just bundling up some logfiles
My fault - forgot to push a file - try pulling evohome_cc again pls
1 Like
That appears to have fixed it.
Working as expected, auto discovery populates names within a couple of minutes