Hi, my installer wants to give me this Evohome system: thermostatic valves plus Evohome controller.
Do you recommend it? DOes it integrate well into Home Assistant? Or you recommend other products (I still have time to stop him)
In general, yes, I think so. However, I am finding that demand is often āunavailableā for UFH. (This possibly also happens with other heat emitters. I will upload logs to the Google shared folder as before)
Hello,
I have evohome since 7 years in my house and at that time there was not much choice of systems which could control different zones and different times/days programs. It may be different nowadays (I have not kept up to date with the market on this). I am fairly happy with evohome in general. I find that it is not so āintelligentā sometimes. The system is supposed to learn to start / stop the heating depending on how fast your home is heating / cooling, but I find that in rooms with underfloor heating, the inertia of the UFH is too much for evohome to manage. You end up having to plan to start / stop the heating yourself by programming the hours you want plus or minus a delta that you estimate via trial and errors. Because of this I find the system a bit pricey for what it really is.
That being said, the system is stable, easy to use (even if the interface is a bit cluncky sometimes I find) and has good integration with Home Assistant thanks to the great work done by zxdavb.
You can integrate eveohome via the cloud of honeywell or locally by using a special dongle which can communicate via RF with the system.
Hope this helps with your choice.
thanks, which dongle?
what do you mean?
Yes I do have UFH on ground floor (like 10 zones so I will use 10 valves), and normal heating in first floors.
Just installed a new electric heat pump (xxck Putin gas, no need for gas anymore yeah) that will bring to 38 degrees C, all house has been insulated with EPS 10cm, also new glass windows with 3 layers
He was responding to me - he was reporting an issue with my code, not the evohome system.
Either a HGI80 from Honeywell (rare, expensive), or a dongle running evofw3 (strongly recommended).
You can buy a dongle (an SSM-D2) from here (about Ā£35), or even make one yourself - postage to EU is a bit expensive, thanks to Brexit
1 Like
Because getting a dongle to where is like is both hard and expensive, I want to order the components (CC1101 + arduino nano) and solder them myself.
I am struggling to find any guide on how to do this.
Do you know of any? Thanks!
Ask Pete at GitHub - ghoti57/evofw3: Major overhaul of evofw2 Evohome listening software to use asynchronous radio mode
this donlge will need to be connected to? The machine hosting home assistant, or a new VM?
Do you know the range of this dongle (which RF?)? I ran my Home Assistant on an Intel BUC in which I have also other VM, or can setup another VM for this if needed, but is on another floor where I (will soon) have the thermostatic valves. ANd here we have concrete wall, so need to check if waves go through them
It should be connected to the same VM that is running HA.
Regarding the quality of reception, YMMV.
Minor bug in v0.18.7.
I wrote a while ago about some log errors in a āzone valveā zone. Iāve now re-bound this zone back to āelectric_heatā after some work on my heating system, and can confirm the error persists with the new zone type.
Messages like this are printed every 15 mins, although there appear to be no other ill effects:
Logger: ramses_rf.message
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/message.py:337
First occurred: 9 March 2022, 22:33:27 (762 occurrences)
Last logged: 13:48:24
RQ --- 18:204306 01:225826 --:------ 0008 001 07
<
Corrupt packet: Invalid verb/code for 01:225826 (CTL) to Rx: RQ/0008
These only appear following a restart with restore_cache set to true.
Packet log from yesterday, which includes a restart with restore_cache: true:
The electric_heat zone is zone index 7. (Note in my previous logs this was index 8; I deleted and re-created the zone during re-binding which closed the gap left from a previously-deleted zone.)
I am about to release 0.18.8 - it includes a fix for the above issue, plus others
Currently, I release two tracks of the evohome_cc / ramses_rf pair.
The stable track is now based upon 0.18.7 (and later):
- it only receives bug-fixes (and only ācriticalā bugfixes)
- it should not receive any breaking changes
- it is strongly recommended to run only the latest version of this track
The master track is based upon 0.19.x:
- it will include (new) features not available in the stable track
- it may include some breaking changes
- it may be the best option for you, despite the relative instability of the track (e.g. FANs)
1 Like
Iām running 19.2 and have these errors.
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:219
First occurred: 16 March 2022, 18:35:01 (13 occurrences)
Last logged: 16:50:39
*** sync cycle stats: 0.290, avg: 0.206, lower: 0.052, upper: 0.383, times: [0.22828275400024722, 0.38289679899935436, 0.2594075180004438, 0.08338209399880725, 0.09332698700018227, 0.09497819100215565, 0.05213506900327047, 0.37300565800251206, 0.2902375170015148]
*** sync cycle stats: 0.208, avg: 0.207, lower: 0.052, upper: 0.383, times: [0.22828275400024722, 0.38289679899935436, 0.2594075180004438, 0.08338209399880725, 0.09332698700018227, 0.09497819100215565, 0.05213506900327047, 0.37300565800251206, 0.2902375170015148, 0.20798907499556663]
*** sync cycle stats: 0.114, avg: 0.198, lower: 0.052, upper: 0.383, times: [0.22828275400024722, 0.38289679899935436, 0.2594075180004438, 0.08338209399880725, 0.09332698700018227, 0.09497819100215565, 0.05213506900327047, 0.37300565800251206, 0.2902375170015148, 0.20798907499556663, 0.11446976599108893]
*** sync cycle stats: 0.114, avg: 0.191, lower: 0.052, upper: 0.383, times: [0.22828275400024722, 0.38289679899935436, 0.2594075180004438, 0.08338209399880725, 0.09332698700018227, 0.09497819100215565, 0.05213506900327047, 0.37300565800251206, 0.2902375170015148, 0.20798907499556663, 0.11446976599108893, 0.11401016698800959]
*** sync cycle stats: 0.226, avg: 0.194, lower: 0.052, upper: 0.383, times: [0.22828275400024722, 0.38289679899935436, 0.2594075180004438, 0.08338209399880725, 0.09332698700018227, 0.09497819100215565, 0.05213506900327047, 0.37300565800251206, 0.2902375170015148, 0.20798907499556663, 0.11446976599108893, 0.11401016698800959, 0.22639910799625795]
1 Like
Hello,
Iāve just updated to 0.19.2 (from 0.19.1) and I have the following error:
Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:96
First occurred: 9:59:07 PM (1 occurrences)
Last logged: 9:59:07 PM
Error doing job: Exception in callback SerialTransport._read_ready()
Traceback (most recent call last):
File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.9/site-packages/serial_asyncio/__init__.py", line 119, in _read_ready
self._protocol.data_received(data)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 573, in data_received
self._line_received(dtm, _normalise(_str(raw_line)), raw_line)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 617, in _line_received
self._pkt_received(pkt)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 861, in _pkt_received
self._qos_received(pkt)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 905, in _qos_received
if pkt._hdr == self._rx_hdr: # is the Rx pkt, is (expected) response
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 369, in _hdr
self._hdr_ = pkt_header(self)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 497, in pkt_header
return f"{header}|{pkt._ctx}" if isinstance(pkt._ctx, str) else header
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 358, in _ctx
self._ctx_ = self._idx
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 380, in _idx
self._idx_ = _pkt_idx(self) or False
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 455, in _pkt_idx
raise InvalidPayloadError(
ramses_rf.protocol.exceptions.InvalidPayloadError: Corrupt payload: Packet idx is 04, but expecting no idx (00) (0xAB)
I also have the error log with the stats, but I guess it is not really an error:
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:219
First occurred: 10:00:51 PM (1 occurrences)
Last logged: 10:00:51 PM
*** sync cycle stats: 0.307, avg: 0.307, lower: 0.307, upper: 0.307, times: [0.3065976081416011]
Despite the error, all seems fine.
Let me know if you need anything else
I wouldnt have jumped from domoticz if it werent for this integratiom. Thanks!
Iām running 0.18.8 (latest version through HACS) and it has been running very stable.
It has been running quite stable. Every now and then (maybe once a month) all my entities become unavailable. A restart usually fixes this.
Unfortunately since this morning it now seems to be permanently broken. My entities are unavailable and even after restarting 10 times it remains this way.
I havenāt made any changes other than updating to HASS 2022.4.4 yesterday.
Attached some logging, any help would be greatly appreciated!
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:764
First occurred: 1:05:08 PM (31 occurrences)
Last logged: 2:21:17 PM
PktProtocolQos.send_data(sent=0006|RQ|01:205114): boff=3, want=0006|RP|01:205114, tout=2022-04-14T14:15:10.606: QoS: IS_EXPIRED (giving up) (2/2)
PktProtocolQos.send_data(sent=2E04|RQ|01:205114): boff=3, want=2E04|RP|01:205114, tout=2022-04-14T14:15:16.617: QoS: IS_EXPIRED (giving up) (2/2)
PktProtocolQos.send_data(sent=0418|RQ|01:205114|00): boff=3, want=0418|RP|01:205114|00, tout=2022-04-14T14:15:24.626: QoS: IS_EXPIRED (giving up) (3/3)
PktProtocolQos.send_data(sent=0418|RQ|01:205114|00): boff=3, want=0418|RP|01:205114|00, tout=2022-04-14T14:21:11.490: QoS: IS_EXPIRED (giving up) (3/3)
PktProtocolQos.send_data(sent=2E04|RQ|01:205114): boff=3, want=2E04|RQ|01:205114, tout=2022-04-14T14:21:17.504: QoS: IS_EXPIRED (giving up) (2/2)
Unable to find service evohome_cc.put_zone_temp
Logger: ramses_rf.protocol.transport
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py:516
First occurred: 2:15:22 PM (1 occurrences)
Last logged: 2:15:22 PM
Blocking 18:000073 (is a foreign gateway), configure the known_list/block_list as required
This combination of versions (0.18.8 and 2022.4.4) works for me. Is anyone else having an issue with this combination?
The above is a little odd - has anyone else seen it? Corrupt install? Perhaps try an HACS re-install / or upgrade to 0.19.2?