I see this path: File “/config/custom_components/evohome_cc/ init .py”, I would recommend you change you config to /config/packet.log
I figured out, it was because using docker.
I upgraded now correctly, but operation status (heating or off) is not displayed correctly now.
Thank you once again
updated to evofw3 0.6.6 but now can’t set temperature although i can see the state of each TRV (set temp and actual temp)
I might have messed up the Arduino IDE settings
I have a nanoCUL and the sketch was compiled and uploaded ok and it used to work on this version of evohome_cc before the update
would anyone share their Arduino settings for the nanocul and evofw3 ?
Logger: homeassistant.components.websocket_api.http.connection
Source: components/climate/__init__.py:400
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 21:01:17 (1 occurrences)
Last logged: 21:01:17
[140707769172224]
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 136, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1455, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1490, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 595, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 632, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 544, in async_service_temperature_set
await entity.async_set_temperature(**kwargs)
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 404, in async_set_temperature
await self.hass.async_add_executor_job(
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 400, in set_temperature
raise NotImplementedError()
NotImplementedError
Also getting this error now
Logger: evohome_rf.transport
Source: /usr/local/lib/python3.8/site-packages/evohome_rf/transport.py:619
First occurred: 20:51:08 (497 occurrences)
Last logged: 22:48:50
PktProtocolQos.send_data(RQ|10:032432|3EF1|00): boff=1, want=RP|10:032432|3EF1|00, tout=2021-02-06 22:48:21.512470: EXPIRED
PktProtocolQos.send_data(RQ|10:032432|0008|00): boff=1, want=RQ|10:032432|0008|00, tout=2021-02-06 22:48:49.822954: RE-SENT (1/1)
PktProtocolQos.send_data(RQ|10:032432|0008|00): boff=1, want=RP|10:032432|0008|00, tout=2021-02-06 22:48:50.149374: EXPIRED
PktProtocolQos.send_data(RQ|10:032432|3EF1|00): boff=1, want=RQ|10:032432|3EF1|00, tout=2021-02-06 22:48:50.483484: RE-SENT (1/1)
PktProtocolQos.send_data(RQ|10:032432|3EF1|00): boff=1, want=RP|10:032432|3EF1|00, tout=2021-02-06 22:48:50.811289: EXPIRED
Ich kann auch dieses Problem mit evofw 0.66 bestätigen. Mit evofw 0.64 ist alles wieder normal.
[quote=“Mahmoud-Eid, post:631, topic:151584”]
</s> <s>PktProtocolQos.send_data(RQ|10:032432|3EF1|00): boff=1, want=RP|10:032432|3EF1|00, tout=2021-02-06 22:48:21.512470: EXPIRED</s> <s>PktProtocolQos.send_data(RQ|10:032432|0008|00): boff=1, want=RQ|10:032432|0008|00, tout=2021-02-06 22:48:49.822954: RE-SENT (1/1)</s> <s>PktProtocolQos.send_data(RQ|10:032432|0008|00): boff=1, want=RP|10:032432|0008|00, tout=2021-02-06 22:48:50.149374: EXPIRED</s> <s>PktProtocolQos.send_data(RQ|10:032432|3EF1|00): boff=1, want=RQ|10:032432|3EF1|00, tout=2021-02-06 22:48:50.483484: RE-SENT (1/1)</s> <s>PktProtocolQos.send_data(RQ|10:032432|3EF1|00): boff=1, want=RP|10:032432|3EF1|00, tout=2021-02-06 22:48:50.811289: EXPIRED</s> <s>
[/quote]
These are of no consequence - I don’t have an OTB here to test against - if you want me to look at it, please send a 24h packet log.
They are not the cause of your set_temperature issue.
For anyone using EVOFW3…
Have you read: evofw3/README.md at master · ghoti57/evofw3 · GitHub ?
If you have, you’ll see that there is a Custom Board Manager - if not, please ensure you’re using it, going forward.
Actually, I wonder if the evofw3 is not transmitting… Please check the Arduino settings, Board Manager, etc.
Then, if no better, PM me a packet log.
yeah thanks
I just confirmed it was the evofw3 0.6.6, I uploaded my old sketch using the old settings in Arduino IDE
and It’s working
I have read the readme file for the 0.6.6 and used the custom evorfw board but I think this opens up too many variable settings I am not sure which one I screwed
I used evofw3 board atmega328p SW ,
Bootloader old boatloader
pinout nano
and the Programmer AVR ISP
it uploaded fine but then I got the error
I will try later to update the nanoCUL again but if someone want’s to tell me where I went wrong with these settings please be my guest
thanks
I have also problems with the 0.6.6, i can’t control the temperature.
I am currently reproducing this issue - will feedback here.
Note the latest version of evofw3 is 0.6.7, which is strongly recommended.
It has only just been pushed - I have tested it, and it is working now (0.6.6 is confirmed broken).
I’ve upgraded to evohome_cc/evohome_rf 0.5.5 and evofw3 0.6.7
The good news is the exception I mentioned earlier is gone, though I’m still not seeing the heat demand from one of my TRV’s (04:121033). What I am seeing though is the following error:
2021-02-08 09:30:33 ERROR (MainThread) [homeassistant.components.sensor] Platform evohome_cc does not generate unique IDs. ID 01:192614-heat_demand already exists - ignoring sensor.01_192614_heat_demand
Could this have something to do with it? (01:192614 is my controller’s id)
If it helps, this is the state that is logged:
{
"system":{
},
"devices":{
"04:121025":{
"temperature":16.36,
"setpoint":16.0,
"battery_state":"None",
"enabled":true,
"heat_demand":0.21,
"window_state":"None"
},
"04:121027":{
"temperature":19.27,
"setpoint":"None",
"battery_state":"None",
"enabled":true,
"heat_demand":0.64,
"window_state":false
},
"04:121029":{
"temperature":19.6,
"setpoint":"None",
"battery_state":"None",
"enabled":true,
"heat_demand":0.59,
"window_state":false
},
"04:121033":{
"temperature":16.84,
"setpoint":16.0,
"battery_state":"None",
"enabled":"None",
"heat_demand":"None",
"window_state":"None"
},
"10:015155":{
"actuator_cycle":"None",
"actuator_state":{
"actuator_enabled":false,
"modulation_level":0.0,
"flame_active":true,
"flame_state":"0A"
},
"enabled":false,
"boiler_setpoint":61.3,
"modulation_level":0.0,
"boiler_temp":"None",
"ch_pressure":"None",
"dhw_flow_rate":"None",
"dwh_temp":"None",
"rel_modulation_level":"None",
"return_cv_temp":"None"
}
},
"heat_demand":0.59,
"heat_demands":{
"FC":0.59
},
"relay_demands":{
"FC":0.0
},
"fault_log":{
},
"datetime":"None",
"stored_hotwater":"None",
"zones":{
"00":{
"setpoint":16.0,
"temperature":16.84
},
"01":{
"setpoint":20.0,
"temperature":"None"
}
}
}
Oh and thanks for the effort your putting in to this integration, it’s greatly appreciated!
Updated to the latest version, there happend nothing when i want to set the operation mode (heat/off) also when i change the temperature.
Source: /usr/local/lib/python3.8/site-packages/evohome_rf/transport.py:619
First occurred: 12:36:07 (834 occurrences)
Last logged: 12:49:52
PktProtocolQos.send_data(RQ|01:087939|0418|01): boff=3, want=RQ|01:087939|0418|01, tout=2021-02-08 12:49:49.582087: RE-SENT (3/3)
PktProtocolQos.send_data(RQ|01:087939|0418|01): boff=3, want=RP|01:087939|0418|01, tout=2021-02-08 12:49:51.123424: EXPIRED
PktProtocolQos.send_data(RQ|01:087939|0418|01): boff=1, want=RQ|01:087939|0418|01, tout=2021-02-08 12:49:51.630911: RE-SENT (1/3)
PktProtocolQos.send_data(RQ|01:087939|0418|01): boff=2, want=RQ|01:087939|0418|01, tout=2021-02-08 12:49:52.167129: RE-SENT (2/3)
PktProtocolQos.send_data(RQ|01:087939|0418|01): boff=3, want=RQ|01:087939|0418|01, tout=2021-02-08 12:49:53.203373: RE-SENT (3/3)```I also reported the same bug, 0418 (faultlog request). The faultlog is empty so it keeps looping.
@zxdavb has a already done a fix https://github.com/zxdavb/evohome_rf/commit/22eff8667f9d2c00f8970f3e5e5caf8f0a9fa05a, however I don’t know when there is going to be a new release.
A manual installation solved it on my side.
Please PM me a packet log & I’ll have a look.
It appears I’m too much of a n00b to be allowed to send you PMs on this Disqus 
I’ve uploaded a packetlog of a couple of hours this morning here: https://gist.github.com/niesink/789ccbe73a4da8e93cdc9a4f2602eeec
Thanks for your log. Do you have a nanoCUL, or a HGI80? Regardless, the controller does not respond to any packets from it at all.
Below you can see that there are only RQ s, never RP s. In addition, you can see that it has re-transmitted each RQ 3 times (4 ties total) before it gives up.
If the system cannot ‘discover’ what it needs to know via RQ packets, it has to rely upon eavesdropping, which is what it is doing in your case.
In the first instance, I would locate the controller & the HGI80/nanoCUL closer together.
:
(venv) dbonnes@vm-builder ~/c/evohome (master) [0|1]> cat .secrets/niesink/2021-02-09_07-57-12.log | grep -E 'R.* 18:'
2021-02-09T07:57:14.267336 000 RQ --- 18:140821 01:192614 --:------ 10E0 001 00
2021-02-09T07:57:15.631725 000 RQ --- 18:140821 01:192614 --:------ 10E0 001 00
2021-02-09T07:57:19.221150 000 RQ --- 18:140821 01:192614 --:------ 10E0 001 00
2021-02-09T07:57:19.836444 000 RQ --- 18:140821 01:192614 --:------ 10E0 001 00
2021-02-09T07:57:21.845403 000 RQ --- 18:140821 01:192614 --:------ 000C 002 000D
2021-02-09T07:57:21.954001 000 RQ --- 18:140821 01:192614 --:------ 000C 002 000D
2021-02-09T07:57:22.520913 000 RQ --- 18:140821 01:192614 --:------ 000C 002 000D
2021-02-09T07:57:23.426142 000 RQ --- 18:140821 01:192614 --:------ 000C 002 000D
2021-02-09T07:57:25.477885 000 RQ --- 18:140821 01:192614 --:------ 000C 002 000F
2021-02-09T07:57:25.601157 000 RQ --- 18:140821 01:192614 --:------ 000C 002 000F
2021-02-09T07:57:26.178998 000 RQ --- 18:140821 01:192614 --:------ 000C 002 000F
2021-02-09T07:57:27.061847 000 RQ --- 18:140821 01:192614 --:------ 000C 002 000F
2021-02-09T07:57:28.800861 000 RQ --- 18:140821 01:192614 --:------ 1100 001 FC
2021-02-09T07:57:28.950805 000 RQ --- 18:140821 01:192614 --:------ 1100 001 FC
2021-02-09T07:57:29.389555 000 RQ --- 18:140821 01:192614 --:------ 1100 001 FC
2021-02-09T07:57:30.225635 000 RQ --- 18:140821 01:192614 --:------ 1100 001 FC
...
Ah, interesting insight, thanks for the analysis. I will try to ‘understand’ the packet log a bit better myself.
As for your question: I’m using a nanoCUL, this one to be more specific: https://www.amazon.de/-/en/gp/product/B07T252HR7/ref=ppx_od_dt_b_asin_title_s00
Which is quite close to the controller already (about 1.5 meters, seperated by a thin a wooden wall). The TRV’s are all further away (from both the controller and the nanoCUL) and seperated by at least one stone wall and in some cases over 10 meters. I’m guessing this implies something is wrong with the transmitting side of the nanoCUL or the controller is not accepting/processing it’s requests.
Either way, I will try to move the nanoCUL and controller even closer together to see if this helps.
—
update: moving the nanoCUL and controller closes together didn’t seem to do anything. But then after removing the ignore list parameter from my config and restarting Home Assistant I did receive a response from the controller. Which seemed a bit weird as my ignore list on consisted of the first value mentioned on https://github.com/zxdavb/evohome_cc/wiki/3.-Installation-&-Configuration so it looked like
ignore_list:
- 13:237335
So anyway, I did now receive a response from the controller:
2021-02-10T16:33:51.391044 044 RP --- 01:192614 18:140821 --:------ 000C 012 00000011D8C900000011D8C1
2021-02-10T16:34:08.882669 043 RP --- 01:192614 18:140821 --:------ 000C 012 01000011D8C301000011D8C5
However one of the four TRV’s still doesn’t appear to be sending its heat demand.
Analysing the packet log shows me that all four TRV’s are reporting their temperature (code 30C9):
cat evohome_cc.log | grep ' 04:.*30C9' | sed 's/.* 04://' | sed 's/ .*//' | sort | uniq -c
402 121025
143 121027
171 121029
159 121033
Yet only 3 of them appear to be sending their heat demand (code 3150):
cat evohome_cc.log | grep ' 04:.*3150' | sed 's/.* 04://' | sed 's/ .*//' | sort | uniq -c
151 121025
168 121027
179 121029
I’m starting to think it’s a problem with the TRV and will try to reset/re-bind it to the controller tomorrow.
—
update 2: unfortunately unbinding and rebinding the HR92 to the controller did not fix the not-sending of heat demand by that specific HR92
Is there somewhere I can see the current status of this project? For example, is it possible to set temperature overrides for zones/water? What are the current unavailable features/options?
Getting a bit sick of the constant Honeywell TCC outages 
I have a PR to support the presets of zones, for me it’s stable enough as a full time replacement.
- change temperature of zone
- do preset on controller (away, eco, … )
- head demand sensors
- Open Window sensors
- temperature sensors
I’m using commit of evohome_rf (https://github.com/zxdavb/evohome_rf/commit/22eff8667f9d2c00f8970f3e5e5caf8f0a9fa05a) and the latest version of evohome_cc
1 Like