I’ve also just updated from 0.22.40 to 0.30.2. No issues seen and no config changes needed.
Just a basic Evohome setup: evofw3, 17 TRVs, 4 round thermostats, 1 boiler relay.
Thanks @zxdavb!
An evohome (TCC) zone consists of one temperature sensor (usually a thermostat, that can change the zone setpoint) and one or more actuators (usually TRVs, if radiators, or UFH zones, or BDR91s as relays, etc).
In the case of a radiator zone, the heat demand for that zone is the maximum of the heat demands of the constituent TRVs.
So you will see a heat_demand for the zone, with the zone name:
- Bedroom 2 heat_demand (that’s it’s friendly name, the unique id would be
sensor.01_123456_00_heat_demand, or similar)
… and another for each TRV:
sensor.04_123456_heat_demand(or similar)
Of course, if your zones only have one TRV, you may fail to appreciate that the relationship is 1-many, and not 1-1, and wonder why you have two sensors for the same thing.
Let me know if I haven’t explained that well enough.
You will see teh zone heat demand in the contoller UI, under settings.
Running the latest version now on an SSM-D2 from Indalo.
I got the following message as a warning:
Logger: ramses_tx.transport
Source: runner.py:188
First occurred: 13:15:23 (2 occurrences)
Last logged: 13:15:23
/dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00: the gateway type is not determinable, will assume evofw3 (check you have the rights to enumerate USB attrs?)
And…
The active gateway 18:072720: { class: HGI } (by signature) SHOULD be in the known_list
I thought I had the right gateway in my list already (you told me which one it was supposed to be a year ago @zxdavb).
So I added this additional gateway and now (of course) it says
This error originated from a custom integration.
Logger: ramses_tx.schemas
Source: custom_components/ramses_cc/coordinator.py:141
Integration: RAMSES RF (documentation, issues)
First occurred: 13:15:15 (3 occurrences)
Last logged: 13:15:15
Best practice is exactly one gateway (HGI) in the known_list:
An empty known_list was provided, so it cant be used as a whitelist (device_id filter)
It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True
I am using a known_list though so not sure what’s going on there. Maybe it’s ignoring it because I have 2 gateways in there now (and I don’t know which one is the right one 
it was all working fine before so…).
The funny thing is this error remains if I take out my “previous” gateway from the known_list.
That was really useful thank you. I was wondering why I had so many numeric entries as well as the friendly names. Are there any plans to create a hierarchy with an integration entry and device entries with all the entities hanging off the latter?
1 Like
I have been using Ramses since a few weeks now in combination with the SSM-D2. In short: very happy with it and nice to understand the device which doesn’t have any display. I have a Orcon HRC-425 combined with 2 CO2 remotes placed in the bedroom and kitchen.
Next step is to create a ‘fake’ climate-card which utilises all these values with GitHub - jcwillox/hass-template-climate: ❄️Templatable Climate Device for Home Assistant, Supports Running Actions On Service Calls., however it is currently bugged unfortunately. It then allows me to use this card as a remote in the same layout as all thermostats.
Also, would be nice to understand the position of the 2 valves through Ramses. Not sure if this is possible at all in the future.
1 Like
As a rule, please provide the exact version number, thanks.
Please describe your setup - would you be running in a VM?
Nonetheless, the next version of ramses_rf will handle this better, if you continue to use the serial/by-id path.
The point is: ramses_rf needs to know what type of gateway you have, so it adjust appropriately for the foibles of each.
In any case the code has changed since then…
The most useful thing you could do is post your known list for me to review - make sure it is from ramses_cc: down. Other than that, I’m guessing…
Fair enough.
Version: 0.30.2
System: Home Assistant Blue
Config:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00 #/dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
#packet_log: /config/custom_components/ramses_cc/packet.log
restore_cache: true
advanced_features:
message_events: None
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
01:205114:
system: { appliance_control: "10:030051" }
zones:
"01": { sensor: 01:205114 } # Main controller
known_list:
"10:030051":
#Gateway
#"18:205572": { _note: HGI80 } << my gateway before update
"18:072720": << my gateway as advised by the warning
"01:205114": { _note: Controller }
#Badkamer 1
"04:164227":
#Woonkamer
"04:014696":
"04:014708":
"04:014710":
# Badkamer 2
"04:014712": #Valve
"34:018143": #Thermostat
# H Slaapkamer
#"03:256014": { faked: true } #Fake sensor for AC
"04:164247": #Valve
# L Slaapkamer
"04:122639":
# R Slaapkamer
"04:079671":
Hi David, just upgraded to 0.30.2 from 0.21.40. Have similar logs to maesnator. Indeed running in a VM (on Synology DSM.) The gateway is uniquely and correctly specified in the known list. i.e. configuration.yaml was not changed after the version upgrade. Some short log output right after restart:
/dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00: the gateway type is not determinable, will assume evofw3 (check you have the rights to enumerate USB attrs?)
14:50:34 – (WARNING) runner.py
ReadProtocol: sending has been disabled
14:50:30 – (WARNING) RAMSES RF (custom integration)
PortProtocol: QoS has been disabled
14:50:30 – (WARNING) RAMSES RF (custom integration)
Best practice is exactly one gateway (HGI) in the known_list: []
14:50:30 – (WARNING) RAMSES RF
From your earlier response, are you suggesting that by not using by-id for the USB device may lead to a better identification of the device type?
This one may be more interesting:
Source: /usr/src/homeassistant/homeassistant/runner.py:145
First occurred: 14:50:34 (1 occurrences)
Last logged: 14:50:34
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/ramses_rf/helpers.py", line 84, in schedule_fnc
await execute_fnc(fnc, *args, **kwargs)
File "/usr/local/lib/python3.11/site-packages/ramses_rf/helpers.py", line 76, in execute_fnc
return await fnc(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 426, in _poll_discovery_cmds
await self.discover()
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 514, in discover
if msg := await send_disc_cmd(hdr, task): # TODO: OK 4 some exceptions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 472, in send_disc_cmd
result = await asyncio.wait_for(
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/asyncio/tasks.py", line 489, in wait_for
return fut.result()
^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/gateway.py", line 809, in async_send_cmd
pkt = await super().async_send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/gateway.py", line 314, in async_send_cmd
return await self._protocol.send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 638, in send_cmd
await super().send_cmd(cmd)
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 519, in send_cmd
return await super().send_cmd(cmd, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 378, in send_cmd
return await self._send_cmd(cmd, **kwargs) # type: ignore[func-returns-value]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 385, in _send_cmd
await self._send_frame(str(cmd))
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 486, in _send_frame
await super()._send_frame(frame)
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 195, in wrapper
await fnc(self, frame, *args, **kwargs)
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 447, in _send_frame
await super()._send_frame(frame)
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 121, in wrapper
await fnc(*args, **kwargs)
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 433, in _send_frame
await super()._send_frame(frame)
File "/usr/local/lib/python3.11/site-packages/ramses_tx/protocol.py", line 389, in _send_frame
self._transport.send_frame(frame)
^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'send_frame'
Also noticed the preset_mode going to null on the zone entitities (e.g. climate.evohome_cc_01_201047_00) after a couple of hours
After updating to the latest release, no config changes, bog standard BDR91 setup:
- I have lots of ‘sensor.xx_xxxxxx_oem_code’ unavailable entities, reasonably sure these are ‘new’
- Cannot determine gateway, same as other reports:
/dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00: the gateway type is not determinable, will assume evofw3 (check you have the rights to enumerate USB attrs?)
… other than that, all seems well so far, entities retained their IDs (hurrah), automations seem to work still. Looking good.
Running a Supervised install:
* Core 2023.11.2
* Supervisor 2023.11.3
* Operating System Debian Bullseye
* Frontend 20231030.2
I would be grateful if everybody did not confuse my terse replies with rudeness - I am just short of time. Please forgive me.
The whole idea is that there is only one of me… many of you… please do what you can to help me.
(and ‘the latest version’ will mean nothing to others who read your post in the future)
Your config is not useful to me - learn to use your triple-backquotes, so I can see the spacing.
… but you should be doing this:
known_list:
18:072720: class: HGI
This issue is - that for HVAC - there are 18: devices that are not gateways.
I am sorry that this is not clear enough:
The active gateway 18:072720: { class: HGI } (by signature) SHOULD be in the known_list
Ah! this is interesting!
I have added code to work-around this issue. You have to use:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
or the SSM-D2 equivalent.
The warning is expected with a VM - it was not expected with HA Blue.
By necessity, as explained above, 0.30.x is much fussier about these things - someone is welcome to edit the wiki.
Is it? See above.
On what HW please - see above.
SSM-D2
ramses_cc:
....
serial_port:
port_name: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
baudrate: 115200
.....
known_list:
18:068121: {class: HGI} # SSM-D2 Dongle
NUC-like-box.
Have you added the HA account to the dialout group?
Supervised installs run as root.
I assure you no rudeness was implied or perceived. Apologies if my statement led you to believe otherwise. I am not a native English speaker and was under the assumption that “fair enough” is a neutral saying.
You’re right. I’ve updated my previous post.
Thanks, it seems to work since the warning in question is no longer showing now.
Good to know!
Apologies if I misunderstand but I am already using this code? Or are you saying you made changes and I should await an update?
Thanks for everything you’re doing David. I’d like to express my gratitude with a donation but am unable to find any pay address on your github. Can you send me one?
I noticed I’m now getting the following warning:
This error originated from a custom integration.
Logger: custom_components.ramses_cc.schemas
Source: custom_components/ramses_cc/schemas.py:491
Integration: RAMSES RF (documentation, issues)
First occurred: 09:00:37 (1 occurrences)
Last logged: 09:00:37
Using a merged schema (cached schema is not a superset of config schema), if required, use 'restore_cache: restore_schema: false'
I’ve tried to disable restore_cache, restart, enable it again and restart.
This still gives me the same warning.
I also have the merged schema warning. one-off setting restore_schema: false removed the warning on restart, although it did re-appear on a subsequent restart with the flag commented out.
restore_cache:
restore_schema: false
resetting the schema also fixed the disappearing preset_mode for me.
I had to put curly brackets around ‘class’ for the 18: device, yaml wouldn’t pass validation otherwise:
known_list:
18:071950: {class: HGI}
@maesenator I wasn’t referring to you - I was referring to me! 
Sorry for not being clear - it has been added to master, but will be in the next release.
These comments are directed at all, and not just the person I respond to - that can alter the nuance slightly. Here, the ‘you’ is more plural (e.g. American ‘you all’) than singular.
To be clear, it is either:
known_list:
18:071950: {class: HGI}
… or:
known_list:
18:071950:
class: HGI
… but not:
known_list:
18:071950: class: HGI