Upgraded and all appears stable thank you
I just installed ramses_cc version 0.31.6.
It seems my configuration was not completely correct and have corrected some errors (mainly by simplyfying my configuration). However, at least one issue remains although it seems the integration is working well. Any ideas how to solve this?
The error message is:
2024-02-01 00:36:21.747 WARNING (MainThread) [ramses_rf.gateway] GATEWAY: Restoring a cached packet log...
2024-02-01 00:36:21.773 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback Controller._handle_msg(RP --- 01:026...6 0404001039C9)
Traceback (most recent call last):
File "/usr/local/lib/python3.11/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.11/site-packages/ramses_rf/device/heat.py", line 329, in _handle_msg
self.tcs._handle_msg(msg)
File "/usr/local/lib/python3.11/site-packages/ramses_rf/system/heat.py", line 600, in _handle_msg
super()._handle_msg(msg)
File "/usr/local/lib/python3.11/site-packages/ramses_rf/system/heat.py", line 498, in _handle_msg
self.get_htg_zone(msg.payload[SZ_ZONE_IDX], msg=msg)
File "/usr/local/lib/python3.11/site-packages/ramses_rf/system/heat.py", line 558, in get_htg_zone
zon._handle_msg(msg)
File "/usr/local/lib/python3.11/site-packages/ramses_rf/system/zones.py", line 620, in _handle_msg
self._sensor = self._gwy.get_device(dev_id, parent=self, is_sensor=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/gateway.py", line 362, in get_device
dev.set_parent(parent, child_id=child_id, is_sensor=is_sensor)
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 1027, in set_parent
parent._add_child(self, child_id=child_id, is_sensor=is_sensor)
File "/usr/local/lib/python3.11/site-packages/ramses_rf/entity_base.py", line 749, in _add_child
raise exc.SystemSchemaInconsistent(
ramses_rf.exceptions.SystemSchemaInconsistent: 01:026398_04 (RAD) changed zone sensor (from 01:111111 (CTL) to 04:014793 (TRV): None) (hint: try restarting the client library)
2024-02-01 00:36:21.787 WARNING (MainThread) [ramses_rf.gateway] GATEWAY: Restored, resuming
My config is:
ramses_cc:
# serial_port: /dev/ttyACM0
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
packet_log:
file_name: packet.log
rotate_backups: 28
ramses_rf:
enforce_known_list: true
enable_eavesdrop: false
# turn on later
restore_cache: true
# 01:145038: # Temperature control system (e.g. evohome)
01:026398: {} # looks like a new number, added {}
# system:
# appliance_control: 13:019795 # BDR
# appliance_control: 10:123446. (see error below)
# zones:
# "04": {sensor: 01:111111}
known_list:
18:204301: { class: HGI } # ? Active gateway (USB or BDR91, Evohome touch)
01:026398: { alias: "Controller" }
04:014773: { alias: "N" } # TRV n
04:145139: { alias: "S" } # TRV s
04:145175: { alias: "W" } # TRV w
04:014793: { alias: "C" } # TRV c
04:145159: { alias: "A" } # TRV a
05:197404: { alias: "W" } # Temperature sensor
01:145038: # evotouch?
13:019795: { alias: "CV relay" } # BDR91
13:198915: { alias: "Zone valve" } # BDR91, zone valve
22:197404: # sensor
30:069468: {class: FAN} # suggestion from David
# 10:123446: # no OT bridge
01:111111: #
Installed 0.31.6 with no problems. Good data on all Opentherm sensors except ch_max_setpoint and dhw_setpoint but they are essentially static values on my system anyway.
Those two sensors are showing intermittent data:
I have tried it out, still the issue of setting a temperature for eg 4 zones and only 1 zone is adapted. Service call:
- service: climate.set_temperature
target:
entity_id:
- climate.margot
- climate.dressing
- climate.slaapkamer
- climate.febe
data:
temperature: 5
Log entries:
2024-02-01T11:11:54.749463 095 W --- 18:005567 01:223036 --:------ 2309 003 0701F4
2024-02-01T11:11:54.773573 095 W --- 18:005567 01:223036 --:------ 2309 003 0901F4
2024-02-01T11:11:54.796573 095 W --- 18:005567 01:223036 --:------ 2309 003 0601F4
2024-02-01T11:11:54.819548 095 W --- 18:005567 01:223036 --:------ 2309 003 0A01F4
2024-02-01T11:11:54.838314 045 I --- 01:223036 --:------ 01:223036 2349 013 0A01F404FFFFFF0012010207E8
2024-02-01T11:11:54.850516 045 I --- 01:223036 --:------ 01:223036 2309 003 0A01F4
2024-02-01T11:11:54.862608 045 I --- 01:223036 18:005567 --:------ 2309 003 0A01F4
With 0.22.40 this used to work.
Please try this:
ramses_cc:
ramses_rf:
disable_qos: FalseThis is a known issue, and I am comfortable not addressing it for now.
IMO, not a bug with 0.31.x (but let’s see…).
TIP: for consistency, faked room sensors should start 03: (starting with 01: could cause issues, unless it is also the controller):
So, it seems you used a faked sensor for a while, but:
Error doing job: Exception in callback Controller._handle_msg(RP --- 01:026...6 0404001039C9)
Appears to be a packet like:
2024-02-01T00:36:21.773000 ... RP --- 01:026398 18:xxxxxx --:------ 000C 006 0404001039C9
… which, when decoded says:
# {'zone_idx': '04', 'device_role': 'zone_sensor', 'devices': ['04:014793'], 'zone_type': '04'}
It seems you’re storing a packet cache (the following is edited for readability):
00:36:21.747 ... GATEWAY: Restoring a cached packet log...
00:36:21.773 ... Controller._handle_msg(RP --- 01:026...6 0404001039C9)
01:026398_04 changed zone sensor from 01:111111 to 04:014793)
00:36:21.787 ... GATEWAY: Restored, resuming
What I would do is restart HA with all caching disabled, and go from there.
For me it is still an issue.
Added it and stays the same, 2 changed and 2 didn’t change.
Log extract:
2024-02-01T13:17:51.685084 095 W --- 18:005567 01:223036 --:------ 2309 003 0601F4
2024-02-01T13:17:51.714182 095 W --- 18:005567 01:223036 --:------ 2309 003 0A01F4
2024-02-01T13:17:51.729139 045 I --- 01:223036 18:005567 --:------ 2309 003 0601F4
2024-02-01T13:17:51.749049 095 W --- 18:005567 01:223036 --:------ 2309 003 0901F4
2024-02-01T13:17:51.776891 095 W --- 18:005567 01:223036 --:------ 2309 003 0701F4
2024-02-01T13:17:51.792989 045 I --- 01:223036 18:005567 --:------ 2309 003 0901F4
Hmmm. that should have fixed it - can you raise an issue on Issues · zxdavb/ramses_cc · GitHub please
That way, I won’t forget it.
For now, send each individually, with (say) 3 second gap between - post that yaml in the issue too?
Do I need to add a delay of 3 seconds for all sequential calls?
Yes, a delay after every call, except the last.
I have tidied up your YAML a little, can you do the rest of it - the spaces need to be exact. You can use an anchor so you DRY.
- service: climate.set_temperature
target:
entity_id:
- climate.margot
data:
temperature: 5
- delay: &delay
hours: 0
minutes: 0
seconds: 3
milliseconds: 0
- service: climate.set_temperature
target:
entity_id:
- climate.dressing
data:
temperature: 5
- delay: *delay
- service: climate.set_temperature
target:
entity_id:
...
I’ve fixed the spacing in the issue. For other calls eg ramses_cc.reset_zone_mode also a delay is recommended?
Upgraded to 0.31.6 and all working as normal
I also experienced the issue of only the first zone temp setting in with automations where 2 or 3 zones are set sequentially.
Adding a 5 sec delay between each solved that problem
Tried with the delay removed after the upgrade, but only first entry would work
Only if it results in multiple API calls - i.e. multiple entities.
Understood, just reporting what I saw. Those two are static for me anyway so of little interest. The rest of the OTB sensors including the ones I’m most interested in are all showing good data after 24h
I need the sniff of the codes from the CO2 an/or Humidity remote. I have no idea what they are as I do not have either of them. do you have that dump. I will then play and see what I can do.
Can anyone else step in and help with this?
We need a packet trace of a DRI-ECO-RH / DR-ECO-CO2 binding to a Nuaire PIV.
If not - I can do for humidity, but it will detract from other work.
1 Like
Updated to 0.31.6 and report back the logs after restarting HA.
I have an Orcon HRC450 with two CO2 switches connected to the zone valve.
Logger: ramses_tx.parsers
Source: runner.py:188
First occurred: 10:05:20 (3 occurrences)
Last logged: 10:05:20
I --- 32:097277 63:262142 --:------ 10E0 038 000001C8510D0167FEFFFFFFFFFF0B0207E3564D532D3135434D313700000000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 32:097277 (device type 32 not known to have signature: 0001C8510D0167FEFF)
I --- 32:139773 63:262142 --:------ 10E0 038 000001C8A2050367FEFFFFFFFFFF1D0807E6564D442D3135524D5338362D3200000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 32:139773 (device type 32 not known to have signature: 0001C8A2050367FEFF)
I --- 32:097710 63:262142 --:------ 10E0 038 000001C8510D0167FEFFFFFFFFFF0B0207E3564D532D3135434D313700000000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: 32:097710 (device type 32 not known to have signature: 0001C8510D0167FEFF)
Deze fout is ontstaan door een aangepaste integratie.
Logger: ramses_rf.gateway
Source: custom_components/ramses_cc/broker.py:120
Integration: RAMSES RF (documentation, issues)
First occurred: 10:05:20 (2 occurrences)
Last logged: 10:05:21
GATEWAY: Restoring a cached packet log...
GATEWAY: Restored, resuming
Logger: ramses_rf.dispatcher
Source: runner.py:188
First occurred: 10:35:39 (5 occurrences)
Last logged: 10:37:06
RP --- 32:139773 18:072982 --:------ 22E9 004 0096C800 < PacketInvalid(RP --- 32:139773 18:072982 --:------ 22E9 004 0096C800 < Unexpected code for src to Tx)
RP --- 32:139773 18:072982 --:------ 22E0 004 004CE61E < PacketInvalid(RP --- 32:139773 18:072982 --:------ 22E0 004 004CE61E < Unexpected code for src to Tx)
RP --- 32:139773 18:072982 --:------ 22E5 004 0074C800 < PacketInvalid(RP --- 32:139773 18:072982 --:------ 22E5 004 0074C800 < Unexpected code for src to Tx)
RP --- 32:139773 18:072982 --:------ 3222 004 00060100 < PacketInvalid(RP --- 32:139773 18:072982 --:------ 3222 004 00060100 < Unexpected code for src to Tx)
I --- 32:139773 32:131922 --:------ 31E0 004 00000000 < PacketInvalid( I --- 32:139773 32:131922 --:------ 31E0 004 00000000 < Unexpected code for src to Tx)
A part of my ramses_cc.yaml:
# WTW Orcon
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
restore_cache:
restore_schema: true #false bij instellen, default true
restore_state: true #false bij instellen, default true
#scan_interval: 120 # default 60
packet_log:
file_name: packet.log
rotate_backups: 7
ramses_rf:
enforce_known_list: true # if not true, still enforces the block_list
enable_eavesdrop: false # can be used to create an initial system schema
use_native_ot: prefer # always, prefer (default), avoid, never
orphans_hvac:
- 32:139773 # Orcon HRC425
- 32:131922 # Orcon zone valve
- 32:097277 # Orcon REM/CO2 sensor zone 1 slapen
- 32:097710 # Orcon REM/CO2 sensor zone 2 wonen
- 35:097277 # Orcon fake REM zone 1 slapen
- 35:097710 # Orcon fake REM zone 2 wonen
- 37:139773 # Orcon Fake REM gekoppeld HRC425
known_list:
# 18:000730: # Ramses USB dongle (sentinel device: do not add!!)
# class: HGI
# _note: SSM-D2
18:072982: # Ramses USB dongle
class: HGI
_note: SSM-D2
32:139773: # Orcon HRC425
class: FAN
_note: Orcon WTW
32:131922:
class: HVC # Orcon zone kleppen
32:097277: # Orcon CO2 sensor 1 | Zone 1: slapen
class: CO2
scheme: orcon
32:097710: # Orcon CO2 sensor 2 | Zone 2: wonen
class: CO2
37:139773: # Fake remote gekoppeld aan 32:139773: Orcon HRC425
class: REM
scheme: orcon
faked: true
commands:
uit: " I --- 37:139773 32:139773 --:------ 22F1 003 000007" # uit
away: " I --- 37:139773 32:139773 --:------ 22F1 003 000107" # away
low: " I --- 37:139773 32:139773 --:------ 22F1 003 000207" # speed 1
medium: " I --- 37:139773 32:139773 --:------ 22F1 003 000307" # speed 2
high: " I --- 37:139773 32:139773 --:------ 22F1 003 000407" # speed 3
auto: " I --- 37:139773 32:139773 --:------ 22F1 003 000507" # auto ca 30% van speed 3
can anyone help me out, I’m stuck. I’m trying to fake a sensor for my evohome system but I can’t get it to work. I’ve spend hours reading through this thread and trying different things but no luck. My configuration.yaml looks like this:
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
#serial_port: /dev/ttyUSB2
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
restore_cache: false
packet_log:
file_name: /config/ramses_cc.log
rotate_backups: 7
01:079786:
system:
appliance_control: 10:073268
zones:
"00": { sensor: 01:079786 }
orphans_hvac: [32:017542]
known_list:
01:079786: # Controller (woonkamer)
02:032611: # HCE80
04:022506: # Thermostatic radiator valve (sk peter)
04:022508: # Thermostatic radiator valve (badkamer)
04:022510: # Thermostatic radiator valve (slaapkamer bas&bien)
04:022512: # Thermostatic radiator valve (sk emma)
10:073268: # OpenTherm bridge (R8810)
18:262143: # Honeywell Gateway Interface (HGI80, HGS80)
32:017542:
34:006955: # Honeywell Round thermostat (kantoor)
34:006961: # Honeywell Round thermostat (keuken)
34:250925: # Honeywell Round thermostat (hal)
34:250929: # Honeywell Round thermostat (washok)
03:123456: { faked: true }
my automation looks like this:
alias: Kelder update fake sensor
description: ""
trigger:
- platform: state
entity_id:
- sensor.weersensor_kantoor_temperature
- platform: time_pattern
minutes: /15
condition: []
action:
- service: ramses_cc.put_room_temp
data:
entity_id: sensor.03_123456_temperature
temperature: >-
{% if states('sensor.weersensor_kantoor_temperature') == 'unavailable'
-%}
{{ None }}
{%- else -%}
{{ states('sensor.weersensor_kantoor_temperature') | float }}
{%- endif %}
- delay: "00:00:01"
- service: homeassistant.update_entity
data: {}
target:
entity_id: sensor.03_123456_temperature
mode: single
i’ve added the sensor to my evohome ATC928G3000. If I look at the logs 03:123456 isn’t showing anywhere. Any help would be greatly appreciated
Have you looked at the wiki? It’s not perfect, but is rather extensive-
For example, in section 5.1, we have:
03:123456: {class: THM, faked: true}
where you have:
03:123456: { faked: true }