OK, version 0.30.1 just released - I believe it fixes all report bugs thus far.
Please report more bugs!
This bug can be ignored:
AttributeError: 'NoneType' object has no attribute 'send_frame'
I updated to 0.30.1.
I have ‘unavailable’ in the Orcon HRC sensors:
sensor.32_139773_exhaust_temperature
sensor.32_139773_indoor_temperature
sensor.32_139773_supply_temperature
sensor.32_139773_outdoor_temperature
sensor.32_139773_remaining_time
The data is present in the logs
2023-11-14 00:40:33.244 INFO (MainThread) [ramses_rf.dispatcher] || 32:139773 | | I | hvac_state | 00 || {'hvac_id': '00', 'fan_info': 'speed 2 temporary override', '_unknown_fan_info_flags': [0, 0, 0], 'air_quality': None, 'co2_level': None, 'indoor_humidity': 0.52, 'outdoor_humidity': 0.53, 'exhaust_temp': 13.3, 'supply_temp': 18.5, 'indoor_temp': 19.75, 'outdoor_temp': 12.51, 'speed_capabilities': ['low_med_high', 'timer', 'auto', 'pre_heater'], 'bypass_position': 0.0, 'exhaust_fan_speed': 0.37, 'supply_fan_speed': 0.37, 'remaining_mins': 14, 'post_heat': None, 'pre_heat': 0.0, 'supply_flow': 30.25, 'exhaust_flow': 30.52}
Also five startup HA core errors:
Logger: ramses_tx.parsers
Source: runner.py:188
First occurred: 00:30:07 (4 occurrences)
Last logged: 00:42:36
I --- 32:131922 32:139773 --:------ 22F1 003 000504 < Support the development of ramses_rf by reporting this packet (mode_idx > mode_max)
###
Logger: ramses_rf.entity_base
Source: runner.py:188
First occurred: 00:21:56 (3 occurrences)
Last logged: 00:22:12
No response for task(22F8|RP|32:139773): throttling to 1/6h
No response for task(2210|RP|32:139773): throttling to 1/6h
No response for task(313E|RP|32:139773): throttling to 1/6h
###
Logger: ramses_tx.message
Source: /usr/local/lib/python3.11/site-packages/ramses_tx/message.py:280
First occurred: 00:21:59 (1 occurrences)
Last logged: 00:21:59
RP --- 32:139773 18:072982 --:------ 2210 042 00FF00FFFFFF0000000000FFFFFFFFFF00FFFFFF0000000000FFFFFFFFFFFFFFFF000000000000020800 < AssertionError(Support the development of ramses_rf by reporting this packet)
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/ramses_tx/message.py", line 261, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/parsers.py", line 173, in wrapper
result = fnc(payload, msg, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/parsers.py", line 1350, in parser_2210
assert payload in (
^^^^^^^^^^^^
AssertionError: Support the development of ramses_rf by reporting this packet
###
Logger: ramses_tx.transport
Source: runner.py:188
First occurred: 00:20:03 (1 occurrences)
Last logged: 00:20:03
/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?)
###
Deze fout is ontstaan door een aangepaste integratie.
Logger: ramses_tx.protocol
Source: custom_components/ramses_cc/coordinator.py:141
Integration: RAMSES RF (documentation, issues)
First occurred: 00:20:03 (1 occurrences)
Last logged: 00:20:03
PortProtocol: QoS has been disabled
sensor.32_139773_exhaust_temperature
sensor.32_139773_indoor_temperature
sensor.32_139773_supply_temperature
sensor.32_139773_outdoor_temperature
sensor.32_139773_remaining_time
The unavailable sensors are not found in the logs. I find a lot of
INFO (MainThread) [custom_components.ramses_cc.sensor] Found a Sensor for 32:xxxxxx
notifications, but no notification for the sensors above.
THanks for the pointer to State Attrs, I am now able to identify the seperate TRV’s. I am now updating to relevant name and location and will then look at creating known devices, I am still trying to understand fully the config yaml.
My packet log is 27000 entries per day, obviously I dont want to past that in here.
Really appreciate your help on such a fantastic project.
Frist of all, thanks for the analysis!
In the configuration menu I can see that there’s only one zone, the BDR is paired as the zone valve and the OTB is also paired as the OTB and the Evohome controller is the sensor. Nothing special. Do you think this missconfiguration can cause that the OTB stops sending the boiler output temperature and the DHW temperature after a few hours?
This is a breaking change. They are now called:
sensor.32_139773_exhaust_temp
sensor.32_139773_indoor_temp
sensor.32_139773_supply_temp
sensor.32_139773_outdoor_temp
sensor.32_139773_remaining_mins
I will rename them back to what they were…
I have made my recommendation.
I pushed a new version of ramses_rf and the implication was that there was a bug in the code (which was quite likely). I have since explained to you - in some detail - that there is nothing wrong with the code, and your system appears mis-configured.
The ‘stops sending after a few hours’ is likely due to poor reception. You can try moving the dongle closer to the OTB, if you like.
If you are not willing to enact my recommendation - which is completely OK by me - I am not sure I can help you any more.
Hi,
I have an electric (dry) UFH system controlled by two CM927 thermostats which control three HC60NG relay units (one of the thermostats is bound to two of the relays).
I have an SSM-D2 and I’ve been working through the ramses_cc and ramses_protocol wikis.
I’ve got the SSM-D2 picking up the traffic and I can see the Relay demand, Mix zone config, Zone setpoint and System datetime packet types in the packet log.
I am now trying to set up the faking and have got as far as “Step 2: Ensure the device is instantiated”.
A schema was automatically generated with both thermostats in an orphans_heat list which I added to the configuration. The automatically generated schema also included a main_tcs property with the value None but when I tried to add this to the configuration, it complained that it was invalid. Should I even be trying to add the schema to the configuration given that it is automatically generated anyway?
At this point, I don’t know if I have done everything necessary for the set-up of the faking and I don’t know how to check or test it. When it says that the devices will be instantiated (created), does it mean that they will then show up under Settings > Devices & Services > Devices in the UI? There is nothing there currently.
Under “Using faked devices”, it says “you then use the appropriate service call to cause the faked device to broadcast the relevant packet”. How do I set this up?
Thanks,
Jonathan
Welcome!
The good new is that I am about to focus on faking / binding, once we iron out the current round of bugs introduced by the refactored client, ramses_rf.
In many ways, that was why the lower layers of ramses_rf were re-written.
You haven’t said what you’re trying to fake, but I assume its a temperature sensor?
Currently, only sensors (temp, CO2, Humidity), and (HVAC) remotes are supported - actuators will come.
This is the correct move - AFAIK, there is no discovery with CM927s. It will serve to a) instantiate these devices as sensors.
I don’t think it will b) create any climate entities, only sensors.
Please confirm a) & b) are both true. Are the CM927s mains powered? I would be interested to see one of your packet logs (you can PM me a link).
Don’t add main_tcs to your schema, it serves no purpose.
There is a difference between faking and instantiation.
The schema controls whether a device is instantiated (created) - invariably at startup of HA; the known_list controls how a device s instantiated - what happens if it is instantiated.
So, “impersonation” is faking a real device that is being instantiated because it is in the schema, its packets are in the cache, or it is simply ‘talking’.
Pure “faking” is when the device only exists in the schema and is instantiated because of that.
First thing is to get the devices to appear.
Thanks for the help David!
Sorry, a little more background would have been useful. I’m on a time of use tariff (Octopus Agile) and I want to use home assistant to make use of the daily tariff data to automatically determine the best times to run the heating. So I’m guessing that I need to impersonate the CM927’s so that the SSM-D2 can send the heat demand packets to achieve this (and perhaps some of the other packets for system integrity? - not sure if they would be needed or not).
So on the HA overview page there is a Binary Sensor section with this…
12:xxxxxx battery_low Normal
12:yyyyyy battery_low Normal
18:zzzzzz status OK
and a Sensor section with this…
12:xxxxxx temperature Unavailable
12:yyyyyy temperature Unavailable
Is this all of the device instantiation that is expected?
They are not.
Sure.
Multiple controllers can bind to a BDR91… If the HCG90NG can do the same, then I’d simply use ramses_cc to bind a fake controller to each, so that it can invoke a call for heat.
Impersonating an active CM927 wouldn’t work, as it would be calling for (say) 0% heat demand, overruling your faked call for 100%.
Impersonating a deactivated CM927 (i.e. turn off the physical device) would be doable, but would be a lot of work at this stage.
How would this be different from impersonating an active CM927? Wouldn’t there still be a conflict?
That was the intention since the CM927 can’t use the tariff data. I don’t see how I could achieve the overall goal of tariff data-driven heating control if the CM927’s remained active.
With a BDR91 - it takes the highest of all the heat demands that it is given (so the CM927 could invoke a call for heat when you don’t want one…).
Anyway, having looked at your packet logs - it is really simple… You could relatively easily turn off your CM927s and replace them with HA automations.
They only send:
- 313F - periodic: datetime sync packets (with current dt)
- 1030 - periodic: mixvalve config packets (probably never need to change, but could)
- 1100 - periodic: DHW config packets (not used?)
… and: - 0008 - periodic/on-demand: relay demand packets (0-100%)
would be a learning curve for you…
The send packet service will take care of the 1030/1100 packets. Same for 313F, but teh payload needs to have the current dt, see:
OK, version 0.30.2 just released.
This bug should have been fixed:
I have ‘unavailable’ in the Orcon HRC sensors:
sensor.32_139773_exhaust_temperature
sensor.32_139773_indoor_temperature
sensor.32_139773_supply_temperature
sensor.32_139773_outdoor_temperature
sensor.32_139773_remaining_time
Note that these entity_ids will have changed, but the unique_ids will not:
sensor.32_139773_exhaust_temp was _exhaust_temperature
sensor.32_139773_indoor_temp was _indoor_temperature
sensor.32_139773_supply_temp was _supply_temperature
sensor.32_139773_outdoor_temp was _outdoor_temperature
sensor.32_139773_remaining_mins was _remaining_time
The above may affect automations, etc., but you will noy lose historical data.
Please report more bugs!
I changed my frontend entity id’s, working ok, thanks.
I will 
Starting up Home Assistant Core with ramses 0.30.2 I stll have some warnings and one error:
Logger: ramses_rf.entity_base
Source: runner.py:188
First occurred: 15:24:14 (3 occurrences)
Last logged: 15:24:29
No response for task(2210|RP|32:139773): throttling to 1/6h
No response for task(22F8|RP|32:139773): throttling to 1/6h
No response for task(313E|RP|32:139773): throttling to 1/6h
I don’t know what this means.
32:139773 is my Orcon HRC425
Logger: ramses_tx.message
Source: /usr/local/lib/python3.11/site-packages/ramses_tx/message.py:280
First occurred: 15:23:14 (3 occurrences)
Last logged: 15:24:14
RP --- 32:139773 18:072982 --:------ 2210 042 00FF00FFFFFF0000000000FFFFFFFFFF00FFFFFF0000000000FFFFFFFFFFFFFFFF000000000000020800 < AssertionError(Support the development of ramses_rf by reporting this packet)
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/ramses_tx/message.py", line 261, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/parsers.py", line 173, in wrapper
result = fnc(payload, msg, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/parsers.py", line 1350, in parser_2210
assert payload in (
^^^^^^^^^^^^
AssertionError: Support the development of ramses_rf by reporting this packet
32:139773 is my Orcon HRC425
18:072982 is the USB dongle SSM-D2
Logger: ramses_tx.transport
Source: runner.py:188
First occurred: 15:22:20 (1 occurrences)
Last logged: 15:22:20
/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?)
I don’t know the meaning of this warning.
Logger: ramses_tx.parsers
Source: runner.py:188
First occurred: 15:22:19 (3 occurrences)
Last logged: 15:22:19
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: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)
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)
32:097277 Orcon CO2 sensor zone 1
32:097710 Orcon CO2 sensor zone 2
32:139773 Orcon HRC425
63:262142 Unknown
Deze fout is ontstaan door een aangepaste integratie.
Logger: ramses_tx.protocol
Source: custom_components/ramses_cc/coordinator.py:176
Integration: RAMSES RF (documentation, issues)
First occurred: 15:22:19 (1 occurrences)
Last logged: 15:22:19
ReadProtocol: sending has been disabled
Deze fout is ontstaan door een aangepaste integratie.
Logger: ramses_tx.protocol
Source: custom_components/ramses_cc/coordinator.py:141
Integration: RAMSES RF (documentation, issues)
First occurred: 15:22:19 (1 occurrences)
Last logged: 15:22:19
PortProtocol: QoS has been disabled
This is not really an error - it is warning you that the FAN didn’t supply an answer to this RQ.
Some ventilations units will, most will not.
It is logspam, really and will be removed at some future stage.
‘by reporting this packet’ means that this packet is seen often but is not decoded in full - or at all - because it’s contents are not well-understood.
I generally ask people with these packets to provide me with 24 hour packet logs, and every so often I go through them for hints. If I learn anything, I improve the corresponding parsers.
I have added USB dongle auto-detection. It isn’t working on your system…
What platform are you running on?
This is a broadcast (device id) address.