Wow!!! Very impressive. Perhaps that should go on the wiki.
nope, letting it run for some time does not solve it for me, been running at least 24h now. I’ll do a refresh of the nanocul later, but I flashed it only 2 or 3 days ago with the latest fw, so don’t think that’s gonna help. But assumptions are etc, so will give it a try
Just out of curiosity, I deleted the various Entities, uninstalled and reinstalled the plugin, restarted HA on the hour at 18:00.
It took until 18:47 for the first ‘name’ (Living Room) to be populated/retrieved/scanned/something-or-other for me… the others then followed shortly after.
2021-02-15 18:47:13 DEBUG (MainThread) [custom_components.evohome_cc] Params = {'system': {'mode': {'system_mode': 'auto', 'until': None}, 'language': None, 'heating_control': {}}, 'stored_hotwater': None, 'zones': {'00': {'name': 'Living Room', 'mode': {'zone_idx': '00', 'mode': 'follow_schedule', 'setpoint': 24.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}},
Prior to this, it just showed:
{'name': None,
I can’t seem to get the zone names to appear,
evohome_rf uses three distinct means for collecting data, such as zone temps, etc.
- schema file (broken at the moment)
- eavesdropping (it captures the packets between the controller and other devices)
- discovery (by sending a packet to a controller asking a quesion)
For a typical system, discovery takes 2 minutes (not, say, 47 minutes).
If you don’t any zone names (discovery isn’t working) and a name appears when you push the button on a TRV (specifically a HR82UK) (eavesdropping is working), then your evofw3/nanoCUL is not sending packets & you need to check your settings when you flash the firmware.
25% seems a bit high - what are others getting?
My system is 0.1%
Think you might be right, seem to be seeing a similar problem to the below - my understanding, is that they suspect the nanoCUL is not sending packets. I see the same with evohome_cc, an override does not change the zone temp and yet I can see all zone temperatures, etc.
If you look in the HA log, you will see at lot of messages with EXPIRED:
21:30:07.782 PktProtocolQos.send_data(RQ|01:145038|0418|0A): boff=1, want=RQ|01:145038|0418|0A, tout=2021-02-15 21:30:07.881995: RE-SENT (1/3)
21:30:08.238 PktProtocolQos.send_data(RQ|01:145038|0418|0A): boff=2, want=RQ|01:145038|0418|0A, tout=2021-02-15 21:30:08.438305: RE-SENT (2/3)
21:30:09.093 PktProtocolQos.send_data(RQ|01:145038|0418|0A): boff=3, want=RQ|01:145038|0418|0A, tout=2021-02-15 21:30:09.492816: RE-SENT (3/3)
21:30:10.750 PktProtocolQos.send_data(RQ|01:145038|0418|0A): boff=3, want=RP|01:145038|0418|0A, tout=2021-02-15 21:30:10.745596: EXPIRED
2021-02-15 21:30:16 WARNING (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:215029|3EF1|00): boff=1, want=RQ|13:215029|3EF1|00, tout=2021-02-15 21:30:16.528318: RE-SENT (1/1)
2021-02-15 21:30:17 ERROR (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:215029|3EF1|00): boff=1, want=RP|13:215029|3EF1|00, tout=2021-02-15 21:30:17.126126: EXPIRED
2021-02-15 21:30:17 WARNING (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:246213|0008|00): boff=1, want=RQ|13:246213|0008|00, tout=2021-02-15 21:30:17.459575: RE-SENT (1/1)
2021-02-15 21:30:17 WARNING (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:246213|3EF1|00): boff=1, want=RQ|13:246213|3EF1|00, tout=2021-02-15 21:30:17.888515: RE-SENT (1/1)
2021-02-15 21:30:17 ERROR (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:246213|3EF1|00): boff=1, want=RQ|13:246213|3EF1|00, tout=2021-02-15 21:30:17.888515: EXPIRED
2021-02-15 21:31:06 WARNING (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:246213|0008|00): boff=1, want=RQ|13:246213|0008|00, tout=2021-02-15 21:31:07.068531: RE-SENT (1/1)
2021-02-15 21:31:07 WARNING (MainThread) [evohome_rf.transport] PktProtocolQos.send_data(RQ|13:246213|3EF1|00): boff=1, want=RQ|13:246213|3EF1|00, tout=2021-02-15 21:31:07.336557: RE-SENT (1/1)
This is bad news:
21:20:44.166 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=1, want=RQ|01:204708|10E0|00, tout=2021-02-15 21:20:44.266409: RE-SENT (1/3)
21:20:44.204 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {}
21:20:44.611 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=2, want=RQ|01:204708|10E0|00, tout=2021-02-15 21:20:44.810766: RE-SENT (2/3)
21:20:44.636 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {}
21:20:45.443 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=3, want=RQ|01:204708|10E0|00, tout=2021-02-15 21:20:45.843070: RE-SENT (3/3)
21:20:45.485 || HGI:003618 | CTL:204708 | RQ | device_info | 00 || {}
21:20:47.090 PktProtocolQos.send_data(RQ|01:204708|10E0|00): boff=3, want=RP|01:204708|10E0|00, tout=2021-02-15 21:20:47.086022: EXPIRED
Note the code: 10E0.
The point is: there is a difference between all Tx failing, and some pkts failing - and 0008 / 3EF1 can fail, even when everything else is OK.
packets that are 100% expected to work are 0004, 0005, 000C, 2309, 2E04, 30C9…
This may or may not be relevant, but I have an HGI80 connected to Domoticz and I’m seeing the same symptoms. Reading of the devices is perfect, but when you try to set anything (temperature, mode) then Domoticz thinks it has done it, but after a few minutes the Domoticz device’s values jump back to match the real-world controller. I thought I was going crazy and it was perhaps just my setup - this 100% used to work at some point, but I guess an update broke things. I’ve no idea when because I only tend to Domoticz for monitoring and not controlling.
I’ve also noted that my control via evohome_cc is not working either (I did think it was working, but was probably not paying attention as Home Assistant is new to me) - if I set a temperature on an entity with the arrows on the card then the value in the textbox disappears, eventually updated again to match the controller’s values.
Looks like I have the same issue… And it seems it is (?) related to HGI80… As I also use HGI80.
great! only thing missing is the Arduino tool config is this setting:
bootloader: “old bootloader”
the standard bootloader setting gives a failure in my case.
Ok, removed the Evohome_cc integration, did a clean pip install, same problem as the first time: I follow the instructions to the letter, and the install puts an Evohome_cc folder in custom_components, containing another custom_components folder with an Evohome_cc folder in it containing the python files. Moving the python files to the /config/custom_components/evohome_cc folder solves the problem, I can restart and after adding the Evohome_cc settings to configuration.yaml the integration works. But still no zone names, not even after an hour. Did a refresh of the nanocul with (again) the 0.6.7 evofw3 firmware, still no zone names after appr 30 minutes.
What am I doing wrong?
Using core-2021.2.3 Hass supervised in a docker on ubuntu 20.04.1 LTS.
We seem to suspect that the devices are not transmitting, have a quick read on the ~10 post above this.
And then:
Names not appearing, potentially, seems to be a symptom of the device not TX-ing.
yeah, that’s why I removed the integration and did a fresh install, and reflashed the nanocul with Arduino IDE set up like mentioned in earlier posts (although I notices my settings were already correct). Reflashing the nanocul should be the solution for the not transmitting problem, correct?
Packet logging set to debug, this is wat I get (still no zone names in HA):
2021-02-17T09:24:53.546972 091 RP — 10:071257 01:161604 --:------ 3220 005 00C0110000
2021-02-17T09:24:53.729004 071 RQ — 01:161604 10:071257 --:------ 3220 005 0000120000
2021-02-17T09:24:54.071116 092 RP — 10:071257 01:161604 --:------ 3220 005 00C01201B3
2021-02-17T09:24:54.729391 070 RQ — 01:161604 10:071257 --:------ 3220 005 0080190000
2021-02-17T09:24:55.150521 090 RP — 10:071257 01:161604 --:------ 3220 005 00401941F0
2021-02-17T09:24:55.328575 070 RQ — 01:161604 10:071257 --:------ 3220 005 00801A0000
2021-02-17T09:24:55.929721 071 RQ — 01:161604 10:071257 --:------ 3220 005 00801C0000
2021-02-17T09:24:56.246866 090 RP — 10:071257 01:161604 --:------ 3220 005 00C01C2FD7
2021-02-17T09:24:56.765994 091 RP — 10:071257 01:161604 --:------ 3220 005 004073031E
2021-02-17T09:24:57.460247 088 I — --:------ --:------ 10:071257 1FD4 003 00D6AF
2021-02-17T09:25:08.779028 070 I — 01:161604 --:------ 01:161604 1F09 003 FF0532
2021-02-17T09:25:08.810073 072 I — 01:161604 --:------ 01:161604 2309 027 0006400105DC0208020305DC0405140505DC0803E80908340A05DC
2021-02-17T09:25:08.833045 071 I — 01:161604 --:------ 01:161604 30C9 027 00078A01072F0207C90306C70406600507E50804AD0907D70A0707
2021-02-17T09:25:09.211155 082 I — 04:167390 --:------ 04:167390 30C9 003 0004BC
2021-02-17T09:25:13.727776 071 I — 01:161604 --:------ 01:161604 3B00 002 FCC8
2021-02-17T09:25:20.211949 082 I — 04:167390 --:------ 01:161604 1060 003 08FF01
2021-02-17T09:25:20.222891 083 I — 04:167390 --:------ 04:167390 1060 003 00FF01
2021-02-17T09:27:53.775511 082 I — 04:046807 --:------ 01:161604 3150 002 025A
2021-02-17T09:28:00.209626 082 I — 04:167390 --:------ 04:167390 30C9 003 0004C4
2021-02-17T09:28:28.939221 089 I — --:------ --:------ 10:071257 1FD4 003 00D6B6
2021-02-17T09:28:39.362721 074 RQ — 01:161604 10:071257 --:------ 3EF0 001 00
2021-02-17T09:28:41.259413 079 I — 04:122195 --:------ 04:122195 30C9 003 0009AF
2021-02-17T09:28:44.351393 081 I — 04:017582 --:------ 01:161604 3150 002 0100
2021-02-17T09:28:50.209359 083 I — 04:167390 --:------ 01:161604 2309 003 0803E8
2021-02-17T09:28:54.706917 066 I — 22:057582 --:------ 22:057582 0008 002 0090
2021-02-17T09:28:56.706546 065 I — 22:057582 --:------ 22:057582 0008 002 0090
2021-02-17T09:29:20.710674 083 I — 04:167390 --:------ 01:161604 1060 003 08FF01
2021-02-17T09:29:20.720830 081 I — 04:167390 --:------ 04:167390 1060 003 00FF01
I’m using HR92 TRV’s, pressing the button on those only turns on the display light, what can I do to trigger these? I turned the knob to set a temporary temperature on them, still no zone names.
thanks again.
If you set a temperature override/change in HA, does it actually make it to Evohome?
If not, the core problem is the device not transmitting - as far I’m aware, people in a similar situation (myself included) have not found a fix.
In the post of the evofw3 github page, I think, all of the people posting bought the same nanoCUL from the same seller on eBay - this may or may not be relevant, i.e it’s possible there is a dodgy hardware batch. Some who made their own device with components, did not see the problem as far as I recall.
I recently bought a new nanoCUL ( 1 week old) and it seems to be working on and off … I do noticed that I have high value reception, value what could mean that there is a bad reception.
Ok, looks like it’s working, maybe I was to impatient, because zone names are appearing in “entities” now. Also I maybe overlooked them because it is cluttered with these entities (probably 9 zones x 4 sensors/binary), can I delete those or hide them?
04:122187 battery
binary_sensor.04_122187_battery
Honeywell RF (RAMSES II protocol)
04:122187 heat_demand
sensor.04_122187_heat_demand
Honeywell RF (RAMSES II protocol)
04:122187 temperature
sensor.04_122187_temperature
Honeywell RF (RAMSES II protocol)
04:122187 window
binary_sensor.04_122187_window
Honeywell RF (RAMSES II protocol)
04:122191 battery
binary_sensor.04_122191_battery
Honeywell RF (RAMSES II protocol)
04:122191 heat_demand
etc
I noticed that the climate.* entities were named, the corresponding battery, window and heat_demand were not - not sure if that’s just me.
But I believe the climate entities SHOULD be named within about a minute, when evohome_cc queries the controller - if it can’t transmit, or the transmit from the nanoCUL is not received by the controller because of poor reception, then it takes longer as it has to sniff rather than query.
P.S. If you wrap your logs in the code formatting </>, from the menu bar, it’s easier to read 
When you are posting, it will help everyone if we use some basic formatting - such as the back-ticks when the text is from a log file:
2021-02-17T09:24:53.546972 091 RP — 10:071257 01:161604 --:------ 3220 005 00C0110000
2021-02-17T09:24:53.729004 071 RQ — 01:161604 10:071257 --:------ 3220 005 0000120000
For example, the lines above are preceded by 3 back-ticks & the word text, and followed by another 3 back-ticks like so:
```text
… log lines here …
```
Also: there is a wiki to read & edit - can I encourage people to contribute to it, and I will ‘tweak’ if if required. Please sign-post others to it contents as often as you can - this will make life easier for everyone & save me having to write things multiple times.
If I post a response here - perhaps someone can update the wiki: https://github.com/zxdavb/evohome_cc/wiki
Those nanoCULs that appear listen-only - it appears they are the exact same one I have (i.e. same eBay item number, pictures look the same), and is the one recommended above:https://www.ebay.co.uk/itm/372221622516 - I can say that the vendor has consistently been a good actor, so I am not sure what is happening there.
The reasons why it is not performing properly is being investigated by the firmware dev, here: https://github.com/ghoti57/evofw3/issues/6
There is another device in the works that may perform better: https://www.automatedhome.co.uk/vbulletin/showthread.php?6366-Introducing-the-HGI80-alternative-the-latest-DIY-kid-on-the-block
The only other viable alternative is a HGI80, and these are rare/expensive.
Things with evohome_cc is a bit messy at the the moment** (for those of you who pull directly from the evohome_rf repo), but I plan to push a new pair today.
See: https://github.com/zxdavb/evohome_cc/wiki/Tips-for-the-configuration.yaml-file
There are new features arriving, that I suggest you take advantage of. In addition, support for full schemas will come, which will help this limited to eavesdropping (listen-only) mode.
If you want help, you have to present information in a way that makes it easy for others to help. That includes collecting good logs & posting them in a good format, above.
At the moment, you’re required to produce packet logs for this integration to work:
evohome_cc:
serial_port: /dev/ttyUSB1
config:
packet_log: /folder/packet.log
… this obligation will be dropped in future, when the code becomes stable.
People can always PM me 24 hour log files >24 hour log - they help me to improve the parsers (some stuff is still not fully understood), and - more importantly now - make evohome_rf more resilient.
To see how to check if your nanoCUL is transmitting OK, see: https://github.com/zxdavb/evohome_cc/wiki/How-to-check-your-nanoCUL-is-transmitting-OK
Could people update that wiki with data for:
- what path to use for the packet log for a given install type
- how to read that file
Missing zone names are an indication that RQ\0004 packets are not getting a RP from the controller - you need to know if that is being caused by a) a problematic (listen-only) nanoCUL,or; b) poor radio reception.
See the wiki, above for tips on how to do tell the difference. One trick is to press teh button on a HR92UK TRV, which will cause it to send an RQ/0004 packet & evohoem_rf can eavesdrop it, and *evohome_cc will then display it in HA.
Obviously a) does not apply to HGI80s.
1 Like