Look for errors in your fault log please.
After updating from 0.30.4 to 0.30.5 I restarted HA and Ramses_cc did not start.
In the logbook I found:
Deze fout is ontstaan door een aangepaste integratie.
Logger: custom_components.ramses_cc.coordinator
Source: custom_components/ramses_cc/coordinator.py:130
Integration: RAMSES RF (documentation, issues)
First occurred: 10:52:49 (1 occurrences)
Last logged: 10:52:49
The config schema is not minimal (consider minimising it)
and
Logger: homeassistant.components.remote
Source: helpers/entity_platform.py:361
Integration: Afstandsbediening (documentation, issues)
First occurred: 10:52:52 (1 occurrences)
Last logged: 10:52:52
Error while setting up ramses_cc platform for remote
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 361, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/ramses_cc/remote.py", line 51, in async_setup_platform
[RamsesRemote(broker, device) for device in discovery_info["remotes"]]
File "/config/custom_components/ramses_cc/remote.py", line 51, in <listcomp>
[RamsesRemote(broker, device) for device in discovery_info["remotes"]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ramses_cc/remote.py", line 82, in __init__
self._commands: dict[str, dict] = broker._known_commands.get(device.id, {})
^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'RamsesBroker' object has no attribute '_known_commands'
Version 0.30.4 was not available in the version dropdown to download Ramses_cc to the old and working version 0.30.4 again so I had to restore my backup.
The 34 is the T87RF thermostat. I have seen a reference to an 03 being a thermostat, perhaps a HCW82, but in a WiKi page that is labelled as defunct. So perhaps that is your HCF82.
Have you looked at the attributes of the schema - entity binary_sensor.01_xxxxxx_schema ?
This is a silly mistake by me - I will fix it tonight.
It should be sufficient to simply re-install the older version via HACS.
This is not an error - it is a warning regarding best practice.
I would be grateful if you could post the ramses_cc: section from your configuration.yaml.
This is deprecated - look instead at the schema on the 18:xxxxxx device.
I installed v0.30.4 and started getting the same issue of ānameā becoming null after some time. A few hours ago wanted to downgrade to the previous version but saw v0.30.5 available, so installed that and restarted HA. The issue of name becoming null is still happening for me.
Here are lines from the ramses_cc: section in my configuration.yaml:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
scan_interval: 60
restore_cache:
restore_schema: false
restore_state: true
ramses_rf:
#enforce_known_list: true # if not true, still enforces the block_list
disable_discovery: false
disable_sending: false # do not transmit any packets, ever
enable_eavesdrop: false # can be used to create an initial system schema
#use_native_ot: prefer
packet_log:
file_name: /config/ramses_packet.log
rotate_backups: 7
known_list:
01:081257: # EvoHome Evotouch - Honeywell Evohome Controller
13:151403: # EvoHome BDR91 - Appliance Control
13:151270: # EvoHome BDR91 - Hot Water Valve
13:151097: # EvoHome BDR91 - Heating Valve
07:026484: # EvoHome CS92 - Stored Hot Water Sensor
34:164569: # EvoHome Y87RF - Underfloor Heating - Study/Office
34:164633: # EvoHome Y87RF - Underfloor Heating - Landing + wc
34:164619: # EvoHome Y87RF - Underfloor Heating - Kitchen & Dining
34:164567: # EvoHome Y87RF - Underfloor Heating - Living Room
34:164617: # EvoHome Y87RF - Underfloor Heating - TV Room
04:128745: # EvoHome HR92 - Radiator Valve - Main Bedroom
04:017473: # EvoHome HR92 - Radiator Valve - Kids Bedroom
04:144005: # EvoHome HR92 - Radiator Valve - Upstairs Landing
04:144011: # EvoHome HR92 - Radiator Valve - Guest Bedroom
18:201474: # Evohome Gateway
01:081257:
system:
appliance_control: 13:151403
zones:
"00":
_name: Study
class: underfloor_heating
sensor: 34:164569
actuators: []
"01":
_name: Landing + WC
class: underfloor_heating
sensor: '34:164633'
actuators: []
"02":
_name: Kitchen + Dining
class: underfloor_heating
sensor: '34:164619'
actuators: []
"03":
_name: Living Room
class: underfloor_heating
sensor: '34:164567'
actuators: []
"04":
_name: TV Room
class: underfloor_heating
sensor: '34:164617'
actuators: []
"05":
_name: Main Bedroom
class: radiator_valve
sensor: '04:128745'
actuators:
- '04:128745'
"06":
_name: Kids Bedroom
class: radiator_valve
sensor: '04:017473'
actuators:
- '04:017473'
"07":
_name: Upstairs Landing
class: radiator_valve
sensor: '04:144005'
actuators:
- '04:144005'
"08":
_name: Guest Bedroom
class: radiator_valve
sensor: '04:144011'
actuators:
- '04:144011'
Here is entity ā climate.ramses_cc_01_081257_01ā as an example, and its attributes:
hvac_modes: auto, heat
min_temp: 5
max_temp: 35
target_temp_step: 0.1
preset_modes: none, temporary, permanent
current_temperature: 20
temperature: 19
preset_mode: none
zone_idx: 01
heating_type: underfloor_heating
mode:
mode: follow_schedule
setpoint: 19
config:
min_temp: 5
max_temp: 35
local_override: true
openwindow_function: true
multiroom_mode: false
schema:
_name: null
class: underfloor_heating
sensor: '34:164633'
actuators: []
params:
config:
min_temp: 5
max_temp: 35
local_override: true
openwindow_function: true
multiroom_mode: false
mode:
mode: follow_schedule
setpoint: 19
name: null
schedule: null
schedule_version: null
icon: mdi:radiator
supported_features: 17
So been progressing on getting this setup.
Been working mainly on the EvoHome kit in wait on the Nuaire work. (although quick question on that one)
This is my nuaire and I see this error alot in the logs (config in second question)
2023-12-12 15:31:27.614 INFO (MainThread) [ramses_rf.dispatcher] RQ --- 18:071184 30:081993 --:------ 2210 001 00 < Invalid code for 30:081993 (FAN) to Rx/Tx: 2210
This is my Config. I believe I should be minimising it a bit as I am overstating my schema? i take it I just need the sensor of each zone? the accuators should auto create?
# RF Configuration
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00 #SSM-D2 Rev B
packet_log:
file_name: ramsespacket.log
rotate_backups: 7
#restore_cache:
# restore_schema: true
# restore_state: false
01:198631: # Evohome Controller
system:
appliance_control: 13:100513
stored_hotwater:
sensor: "07:038573"
hotwater_valve: "13:244215"
heating_valve: null
zones:
"00":
_name: Living room
class: radiator_valve
sensor: 01:198631
actuators: [04:019338]
"01":
_name: Entrance
class: radiator_valve
sensor: 04:019328
actuators: [04:019328]
"02":
_name: Bathroom
class: radiator_valve
sensor: 04:020242
actuators: [04:020242]
"03":
_name: Utility Room
class: radiator_valve
sensor: 04:020244
actuators: [04:020244]
"04":
_name: Bedroom
class: radiator_valve
sensor: 04:020246
actuators: [04:020246]
"05":
_name: Spareroom
class: radiator_valve
sensor: 04:020240
actuators: [04:020240]
"06":
_name: Extension
class: electric_heat
sensor: 22:015026
actuators: []
orphans_hvac: [30:081993, 32:222222, 63:262142]
known_list:
18:071184: { class: HGI } # SSM-D2
01:198631: # EVO Home Controller
13:100513: # BDR91 CH Control
13:244215: # BDR91 HW Control
07:038573: # CS92 HW Temp Sensor
04:019338: # HR91 TRV Living Room
04:019328: # HR91 TRV Entrance
04:020242: # HR91 TRV Bathroom
04:020244: # HR91 TRV Utility Room
04:020246: # HR91 TRV Bedroom
04:020240: # HR91 TRV Spare Room
22:015026: # DTS92 Extension Temp Sensor TRV
30:081993: { class: FAN } # Nuaire PIV}
32:222222:
class: REM
faked: true
commands:
normal: " I --- 32:222222 30:081993 --:------ 22F1 003 00020A"
boost: " I --- 32:222222 30:081993 --:------ 22F1 003 00030A"
heater_auto: " I --- 32:222222 30:081993 --:------ 22F1 003 000A0A"
heater_off: " I --- 32:222222 30:081993 --:------ 22F1 003 00090A"
# bind: " I --- 32:222222 30:081993 --:------ 1FC9 001 00"
# Virtual DRI-ECO-4S
ramses_rf:
enforce_known_list: false # if not true, still enforces the block_list
# disable_discovery: false
# disable_sending: false # do not transmit any packets, ever
enable_eavesdrop: false # can be used to create an initial system schema
I also seem to not see battery status of 07:038573: # CS92 HW Temp Sensor. There is no Homeassistant references to data coming in and the packet.log I see 2 way communications. I am receiving temp data fine from it.
Let me know if you need anything more.
Seems that the 03 entities are indeed the HCF82 sensors.
For some reason they donāt display any values, they are always unavailable although they do work as a sensor for the rooms they are in.
I donāt think a CS92 broadcasts its battery status - at least Iāve never seen mine do it.
No improvement on climate zone names or min/max on 0.30.5, Iām afraid.
Earlier today I updated to 0.30.5 and did a clean restart (restore_cache = false).
The names populated after a while - as expected - but now a few hours later they are all āramses cc 01 ā¦ā again. Based on past experience, I expect they will re-populate again for a while, given time.
The min_temp and max_temp attibutes are also still null after a restart.
I have released 0.30.6 that addresses this issue.
As a rule, donāt ever disable your state cache, it is going to make your issue more likely. Instead, try:
ramses_cc:
restore_cache:
restore_cache: true
restore_schema: false
Is anyone else having this issue? I cannot reproduce it.
My CS92A defintely Tx is battery status:
00:44:02.298 || 07:045960 | | I | device_battery | || {'battery_low': False, 'battery_level': None}
1 Like
Please send me a 24h packet log.
This I am seeingā¦ watch this space!
Hmmm trying to think if the main controller ever knowsā¦. Maybe not.
What broadcast is it that I should look for?
Maybe I am missing something. How is everyone consuming there entities created. Is it all just custom cards? Or is there something I can missing?
Before I go down the rabbit hole of building some custom cards.
Seeing the same thing in the 0.30.5 with the disappearing of the names.
My Cache Config:
restore_cache: true