It looks like your duty cycle is blown - the HGI80 will no longer transmit until it resets itself, or it is reset (disconnected from / reconnected to USB).
ramses_rf is pretty pushy - that is why the cache is so important - without it, it sends lots of packets in a short time, and multiple back-to-back restarts of HA can exceed the limit imposed by the HGI80.
If you’re using a Honeywell HGI80, don’t do multiple-back-to-back restart of HA with
restore_state: false
All, I am only interested if a sensor is permanently unavailable not temporarily / infrequently unavailable.
Your system is misconfigured (below is slightly edited for readability):
(venv) dbonnes@vm-builder ~/c/ramses_rf (master)> cat .secrets/lloyda/2021-11-21.log | grep 'RP.* 000C ... 0[03]' | tail -2 | python client.py -ns parse
...
08:54:42.127 || CTL:185426 | HGI:136212 | RP | zone_devices | 0008 || {'zone_idx': '00', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': ['04:003278', '04:003222', '04:003192']}
08:54:43.957 || CTL:185426 | HGI:136212 | RP | zone_devices | 0308 || {'zone_idx': '03', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': ['04:003286', '04:003192']}
TRV 04:003192 is an actuator in two different zones.
You will have to destroy & re-create the zone that shouldn’t have that TRV in it.
The nature of evohome is that it is very easy to have a misconfigured system.
If I notice an error in your system configuration, that does not necessarily mean the rest of it is fine. It is up to you to check
A big hint would be something like this in your log files:
Inconsistent state: 04:003192 (TRV) changed parent: 01:185426_00 (radiator_valve) to 01:185426_03 (radiator_valve), (try restarting the client library)
When my system is back in service i will send you a log. I misread your message. I use a arduino nano for evofw.
Can all those with issues upgrade to 0.16.12 and we’ll try to sort these issues out using that version…
For unavailable sensors, I am only interested if sensors are permanently unavailable, and I’m not concerned if they’re unavailable at times (the RF protocol has no QoS).
I am interested in all zone issues.
You need to use this logging:
logger:
default: warn
logs:
homeassistant.core: debug
# custom_components.evohome_cc: info
custom_components.evohome_cc.sensor: info
ramses_rf.message: info
ramses_rf.protocol.message: info
I need a fresh restart of HA that runs for at least an hour. I need the HA log, the packet log(s), and your configuration of evohome_cc in configuration.yaml.
To be clear, the HA log, and the corresponding packet log must include the restart of HA.
You must have restore_state: false if you have changed your evohome’s configuration (added/removed a zone, added/removed/moved a device).
Please PM with the above, and a clear description of what is going wrong. Please don’t say: “I’m having the same problems as everyone else”, or “I’ve got unavailable sensors” - your message will be ignored, sorry.
The better job you do of the above, the more likely it will be that it is your system I’ll look at first.
Thanks. Yes spotted that this morning and deleted both zones. Not setting restore_state to false caught me out at first, but now sorted.
This version has fixed all my errors and warnings.
Thanks for the hard work.
Someone has kindly sent me a packet log that does not satisfy the above criteria.
To be clear, the HA log, and the corresponding packet log must include the restart of HA.
Please now use 0.16.12 - it has increased logging that will highlight those with poor reception.
In your logs you may see:
WARNING ... [ramses_rf.protocol.transport] ... QoS: IS_EXPIRED (giving up) ...
WARNING ... [ramses_rf.entities] ... Sending now deprecated for 01:000730 ...
Liking the new display detail on the schema.
Has shown up an interesting potential zone config error (although it is working fine). This zone should have two actuators.
'04':
_name: Bedroom
heating_type: radiator_valve
sensor: '04:003434'
devices:
- '04:003434'
- '04:003202'
_sensor: '04:003434'
_actuators:
- '04:003202'
'05':I should start by saying that _sensor & _actuators are calculated differently from the other two.
Importantly,
devicesincludes actuators & sensors too.
Without your latest packet log, I cannot be sure, but - this appears to show that 04:003434 is configured as a sensor for zone 04 (the Bedroom zone), but not as an actuator.
It is definitely working as an actuator. I’m not too worried about this, but do you want to see the packet log?
I’m sure its working as an actuator - it’s just not doing it optimally. For example, the zone’s heat demand will not be correctly calculated by the controller because it will not listen to that actuator (and same for evohome_cc).
Other issues may present themselves - I wont know for sure without checking the packet log.
To fix this, simply re-bind it to the zone as an actuator - if you don’t know which one of the two is which, just re-bind both - that wont break anything - you’ll have to restart HA with restore_state: false
Please do send me a packet log - it must include a restart of HA.
This is what happens:
06:02:54.309 || TRV:003286 | CTL:185426 | I | heat_demand | 03 || {'zone_idx': '03', 'heat_demand': 0.0}
06:03:15.516 || TRV:003286 | CTL:185426 | I | heat_demand | 03 || {'zone_idx': '03', 'heat_demand': 1.0}
06:03:15.914 || CTL:185426 | | I | relay_demand | F9 || {'domain_id': 'F9', 'relay_demand': 1.0}
The heat demand for an actuator in a zone changes, and it results is an increased/decreased call for heat.
In your case, the demand from the incorrectly configured controller will be ignored.
11:04:32.986 || TRV:003434 | CTL:185426 | I | heat_demand | 04 || {'zone_idx': '04', 'heat_demand': 0.43}
11:04:34.305 || TRV:003202 | CTL:185426 | I | heat_demand | 04 || {'zone_idx': '04', 'heat_demand': 0.42}
However, you’re lucky in that they only ever appear to be 1-2% apart!
Hi,
I’m trying to get a stable setup.
At first I thought that it had to do with bad reception of the evofw3 stick, so I extended it so it now is next to the controller.
The TVR are now logging data in evohome_cc (except the unit in the attic/zolder, but that is possible due to 2 concrete floors 
)
But I’m still seeing strange things in H.A. (what trigger me in the first place).
With standard thermostat entities they sometimes gray out (like slaapkamer)
While the simple thermostat card stays oke (int = evohome-online entities, the others are evohome_cc)
I’m now generating a set of files (packet.log & homeassistant.log & config & schemas and a log of sniffer which is more central in the house).
Any suggestions of what to check?
Is your stick tunable? If so, try to tune it.
Running 0.16.11 some climate zones go into undefined after a while. Eg climate.febe.
binary_sensor.18_005567_config:
schema:
controller: '01:223036'
system:
heating_control: '10:040239'
config:
enforce_known_list: true
known_list:
- '01:223036': {}
- '10:040239': {}
- '04:231770': {}
- '04:231772': {}
- '04:231774': {}
- '04:231776': {}
- '04:050559': {}
- '04:155445': {}
- '04:155403': {}
- '04:081849': {}
- '04:155443': {}
- '04:155407': {}
- '04:155551': {}
- '04:155533': {}
- '04:155537': {}
block_list:
other_list: 12:138834, 13:189944
_is_evofw3: null
friendly_name: 18:005567 (config)
Sorry - not sure - someone else can help?