It is an easy enough thing to do - will change install/upgrade instructions for those not using HACS.
Dunno - are the upsides great enough?
Difficult for me to know to be honest, without knowing what % of people use HACS, my assumption is that quite a lot do though, and for those this would make the barriers to entry a lot lower.
Benefits would be:
- getting more testers (possibly)
- this will probably need doing down the line anyway when this is ready for HACS
OK, seems reasonable.
If someone is willing to add the installation instructions on the wiki - Iāll make the changes.
1 Like
Presently, Iām stuck in the middle of a refactorā¦
Iām happy to update the wiki - with the caveat Iāll need to do it myself first to fully understand it 
And thanks!
Installed a nanoCUL and modules without too much issues; hardest was figuring out the packets.log path in the config (still not sure if itās correct, canāt find the file, but it all seems to work). Results followed quickly, and also allowed me to troubleshoot one misbehaving zone. A sensor in one room showed a different output format an identical unit in another room. Rebinding it seemed to solve this, and has so far fixed the issue.
Hello David,
My boiler is connected to valves controlled by the HM80 valve controller. It works fine but this system can only be controlled by the CM67RFMV Chronotherm thermostat which is infamously known for his faulty screen. I would like to remplace it by implementing a Raspberry Pi version of this thermostat. I found your evohome_cc and evohome_rf repos on GitHub and I was wondering if they could work with a 868MHz dongle on a Pi.
Thank you for your help.
Hi @zxdavb - any idea when youāll be able to do the HACS changes? Just weighing up whether to wait for my install or just go with the current method (as my nanoCUL 30 day returns policy is coming up )
I am sorry, I made an architectural decision that turned out to be a mistake, and I am only just getting back on top of that refactor - you shouldnāt expect anything before the end of the weekend, and HACS will be after that.
The short answer is yes, but I will need help from yourself to make this happen. The way forward would be to put a generic linux on the Pi, with the dongle, and run HA in a dev environment so that we can test/dev together.
Then your can switch to HASSOS later on - I fully expect you can replace the controller altogether, in time.
I am quite happy to help with this - let me know. First step to set up the platform.
I am constantly surprised by the number of misconfigured system we see!
I think the system could do a lot more internal sanity checking than it does, as well as giving more debugging options. My issue was ājustā adding an Y87RF added to an existing zone. It seemed to work in all appearances, but trigged all sorts of weird behaviour (zone shutting off (5 degrees, off symbol) randomly, probably as some sort of fail-safe error mode). While the solution (unbind, delete, and recreate) would have been my next step regardless, actually seeing the output of the Y87RF being different was interesting.
It might be possible for me to help you. I have to mention that I currently only have the HM80 valve controller and the Chronotherm thermostat. I donāt have Evohome equipments such as an Evohome wifi controller.
My final goal would be to be able to add the thermostat in Apple HomeKit through HomeAssistant. According to what I found on the Internet, an expensive option would be to buy the Evohome wifi controller and then add it to HomeBridge (which I already use). Is it still possible for me to help you without the wifi controller ?
You wont need any evohome controller. The ultimate goal is to get that functionality without having to buy one (this is a long way off, though).
You want to use your own thermostat, and integrate it with HA/homekit to drive a HM80 (with the CM67RFMV turned off) - that should be doable, we just have to make it happen. Could probably get the system to fake itself as the CM927, so that if HA wasnāt working, all youād have to do is turn the CM67RFMV on.
Having evohome_xx drive a BDR91A is next on the to-do list - the HMO will be able to leverage that functionality.
I have never yet had the opportunity to test against a HM80 - you can help with that.
Another feature is to have evohome_xx present a thermostat to evohome as if it was proper Honeywell (Resideo) kit.
Once I can do those two things, I think weāll be stealing a bunch of users off Domoticzā¦
As I said before, all this will take more than a few weeks. First step is to eavesdrop the conversation between the CM67RFMV and the HMO, and then probe the HM80. I might have to tweak a few things (parsers, etc.) off the back of that.
Beware: there are many reasons why evohome may do this legitimately, especially if youāre running the very lastest (beta) firmware (which Iād recommend).
Just running without advanced features enabled, on the latest non-Beta image; iāll look into that.
Dear zxdavb, thank you for your hard efforts. I am using the latest version 0.43 and it is working great. I have noticed a small bug, sometimes after a restart the min_temp and max_temp in some zones are not setup properly (logs show zone_config:None}. As a result of that it is not possible to set the target temperature. After performing a number of restarts it gets back to the normal state. However, it seems that if the min and max_temp are not transmitted correctly initially, evohome_cc keeps ignoring them. Could you not set up the default values 5 and 35 in zone_config?
Thank you in advance
That is a good idea - I will make that happen.
I am planning to save state across restarts of HA - this will help, and it will be used in preference to the above (for those who have non-default min/max temps)ā¦
Finally, the controller sends an array of zone_config every hour, so this missing data should be picked up then - all you have to do is wait!
(BTW, evohome_cc does not re-request missing data, nor does it refresh stale data - the intention is for it to do so).
In any case, because the RF protocol uses datagrams, I had added QoS to evohome_rf - it does three transmits (two retries) by default before it gives up waiting for an expected response. The relative āreproducibilityā of your bug makes me suspect your USB dongle isnāt getting the best receptionā¦
Is is a HGI80, or a nanoCUL?
Can you look at the packet logs & tell how many RQ\zone_config packets there are before the corresponding RP (or just PM me a copy of it).
@property
def min_temp(self) -> float:
"""Return the minimum target temperature of a Zone."""
if self._evo_device.zone_config:
return self._evo_device.zone_config["min_temp"]
return 5.0
Thank you for your answer, I have edited climate.py adding the default values.
I have a complex configuration, but probably is good for debugging. I have a hgi80 connected to a domoticz system and a nanoCUL connected to hass.io. There is an external antenna attached to the nanoCUL in order to enhance transmission. The systems are at different locations (different stocks), so I hope no direct RF-interference. The reason for additionally buying a nanoCUL was that I didnāt want to abandon my domoticz configuration before I was sure that I could perform the same tasks with hass and evohome_cc/evohome_rf. After all nanoCUL is cheap and easy to find compared to HGI80.
I am also having a second nanoCUL usb dongle, which I was planing to install at a vacation house.
After your post I started realising that my problem was sending packets from my nanoCUL dongle (I didnāt receive zone config, because my evohome_cc could not request them and at the same time I was not able to change temperature/mode from evohome_cc). Receiving packets was not a problem even from the HR92 thermostats being installed far away from my dongle. I can confirm the sending problem, because I could get the zone-configuration after restarting domoticz, which probably asks for zone-configuration from the controller after booting up. The sent zone-configuration was subsequently received from evohome_cc and afterwards it was displayed correctly, changing Temp was still failing). I flashed my second nanoCUL with the lates evofw3 and after replacing the old nanoCUL evohome_cc, is fully functional again.
(I could also rule out that there was an antenna problem, because my external antenna works with the new nanoCUL dongle).
So, my hypotheses are:
- either there is a hardware problem with my first dongle
- or there is some kind of 1%/h RF-duty cycle implemented in the evofw3 firmware. The problem appears always after continuous restarts, which probably increases the sending rate of the dongle, which reaches the duty cycle limit and afterwards all sent packets are blocked out. In this case a refresh state after HA rebooting would be very helpful in order to avoid unnecessary RF transmission above the DC.
I can probably find out after re-flashing the old nanoCUL and testing again.
I have sent you all my packets before replacing the dongle, please keep into consideration that debugging for evohome_cc was configured only in the last 8hours (before logging was setup as warning only)
I am always available for any additional debugging you may need.