There are now two ‘active’ releases available:
- 0.16.24: Latest Stable
- 0.16.26: Here Be Dragons
Try 0.16.26, if it causes you causing issues, try downgrading back to 0.16.24.
If there is an issue with the newer release, please report it.
0.16.24 still has the warnings. Rolling back to 0.15.5 solves the problem.
I’ve done the RF comms check on the controller and get 5 flashes from my opentherm bridge.
NOTE: 0.15.5 doesn’t solve your problem (no-one else has reported this issue - they should do so it that is the case) - it merely isn’t logging the issue when it occurs.
In 0.16.26, it is logged as a warning():
logger_send(_LOGGER.warning, "IS_EXPIRED (giving up)")
Whilst in 0.15.5, the it is logged, but as debug():
_logger_send(
(_LOGGER.warning if DEV_MODE else _LOGGER.debug),
f"EXPIRED ({self._tx_retries}/{self._tx_retry_limit})",
)
I moved it from warning to debug, to reduce logspam. However, I had to move it back to warning, because so many people were blaming my code when the issue was simply poor reception.
If you wish, run 0.15.5 with this logging and you will see the EXPIRED messages return:
logger:
default: warn
logs:
ramses_rf.protocol.transport: debug
(my worry wasn’t that the OTB can/cannot hear the controller - my point is that the HGI - and to a lessor extent the controller - can’t hear it)
So why did your controller do these 5 re-transmits?
2021-12-06T15:56:42.451094 053 RQ --- 01:169176 10:051349 --:------ 3220 005 0000050000
2021-12-06T15:56:44.452038 053 RQ --- 01:169176 10:051349 --:------ 3220 005 0000050000
2021-12-06T15:56:46.452975 053 RQ --- 01:169176 10:051349 --:------ 3220 005 0000050000
2021-12-06T15:56:48.651953 053 RQ --- 01:169176 10:051349 --:------ 3220 005 0000050000
2021-12-06T15:56:50.652902 053 RQ --- 01:169176 10:051349 --:------ 3220 005 0000050000
2021-12-06T15:56:52.653866 053 RQ --- 01:169176 10:051349 --:------ 3220 005 0000050000
I guess ramses_rf could be transmitting every time the OTB is doing it’s RP, but I feel this is unlikely - if you insist, you can provide a log file in disable_sending: true & I’ll check for you (but I am doubtful).
Here is a packet from your controller to the HGI80-compatible device:
2021-12-06T15:57:39.065042 053 RP --- 01:169176 18:135447 --:------ 2E04 008 00FFFFFFFFFFFF00
The RSSI is 53 - it appears to be always 53/54 (is 53 above). Here is a packet from the OTB:
2021-12-06T15:46:54.213358 081 RP --- 10:051349 18:135447 --:------ 3220 005 00C01C1500
The RSSI appears to hover around 78-82 (is 81 above), which is much worse.
I take it the reason I’ve not seen these before is that I’ve had disable sending true set for months?
Yes, you got it.
Getting this with 0.16.26, don’t think this has happened before:
Logger: ramses_rf.protocol.message
Source: /srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/message.py:373
First occurred: 3:36:31 AM (4 occurrences)
Last logged: 4:29:36 AM
RP --- 01:201047 18:070162 --:------ 0418 022 004003B0061C04000000C39500CDFFFFFF700037F3CD < AssertionError(unexpected domain_id: 1C)
RP --- 01:201047 18:070162 --:------ 0418 022 004004B0061C04000000C39500CDFFFFFF700037F3CD < AssertionError(unexpected domain_id: 1C)
RP --- 01:201047 18:070162 --:------ 0418 022 004005B0061C04000000C39500CDFFFFFF700037F3CD < AssertionError(unexpected domain_id: 1C)
RP --- 01:201047 18:070162 --:------ 0418 022 004006B0061C04000000C39500CDFFFFFF700037F3CD < AssertionError(unexpected domain_id: 1C)
Traceback (most recent call last):
File “/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/message.py”, line 364, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
File “/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py”, line 132, in wrapper
return fnc(*args, **kwargs)
File “/srv/homeassistant/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py”, line 544, in parser_0418
assert int(payload[10:12], 16) < msg._gwy.config.max_zones or (
AssertionError: unexpected domain_id: 1C
This has nothing to do with 0.16.26 - the parser just has never seen a 1C before & doesn’t know what do do with it…
That would make this an ‘unusual’ fault (a rare type of fault).
To fix this, please look at your fault log in the controller’s UI & tell me what it says for the entry with the date/time of 21-12-07T00:06:27 (you can see the fault occurred this morning).
A screen shot is best, but verbatim text will do.
Thanks.
PS: I would also love to see a packet log (or a copy of your schema).
Hi,
thanks for this project! I’ve just installed it and a SSM-D (thanks again, Peter!) and after a few minutes I got a number of sensors and binary sensors show up in my home assistant, nice! Looking through the IDs, I’m assuming the 13: device is the BDR91 attached to the gas boiler and the 12: device is the room thermostat. Looking into their history I can see the communication working and the relay_demand and active status of the gas boiler seem to match.
The thing I’m missing is how I can control that BDR91 from home assistant, as I’m aiming to replace the cruddy room thermostat unit. I’ve already got TRVs via zigbee on all radiators.
Cheers, David
1 Like
Have you found the re-bind packet log for HB85 / 95? I can not find it anywhere…
Just updated home assistant and have these in the logs.
Source: helpers/entity.py:549
First occurred: 19:42:11 (69 occurrences)
Last logged: 19:47:29
Entity sensor.04_198485_temperature (<class 'custom_components.evohome_cc.sensor.EvoTemperature'>) implements device_state_attributes. Please report it to the custom component author.
Entity sensor.30_079129_boost_timer (<class 'custom_components.evohome_cc.sensor.EvoSensor'>) implements device_state_attributes. Please report it to the custom component author.
Entity sensor.30_079129_relative_humidity (<class 'custom_components.evohome_cc.sensor.EvoSensor'>) implements device_state_attributes. Please report it to the custom component author.
Entity sensor.32_168240_temperature (<class 'custom_components.evohome_cc.sensor.EvoTemperature'>) implements device_state_attributes. Please report it to the custom component author.
Entity sensor.32_168240_relative_humidity (<class 'custom_components.evohome_cc.sensor.EvoSensor'>) implements device_state_attributes. Please report it to the custom component author.
Thanks to those who reported this deprecation warning - a fix is coming.
1 Like
The Stable release now has tag 0.16.30, and includes these fixes, and other code quality improvements.
No - I’d love to speak with someone who’s got one.
Just upgraded to 0.16.30 (from 0.16.26) and integration won’t start.
Setup failed for evohome_cc: Unable to import component: cannot import name 'Platform' from 'homeassistant.const' (/usr/src/homeassistant/homeassistant/const.py)
Have rolled back for now.
Updated to 0.16.30 as well, no issues in logs, started up fine.
I’m sorry, I should have said: you need to be running the latest version of home assistant.
1 Like
OK. Thought I would make what appeared to be the lower risk update first.
Hey all - I’d love to hear about what the community is doing with Evohome around using Home Assistant and/or the Ramses RF component to make it smarter? Anyone doing anything cool with predictive analytics / using other sensors (eg door / window / motion / outside temperature) etc? Or monitoring rates of temperature increase/decrease? Looking to hear from smart people doing cool stuff and steal with pride! 
I have the following automations:
- School day warm the kids rooms
- when door open set to eco mode
- Home/Away/Guest mode
- Homework warm bureau
I have one which reduces the set point 30 mins after the kids turn it up at silly o’clock at night.