Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

Share your Projects!
3659

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:

3660

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!

3661

I changed my frontend entity id’s, working ok, thanks.

I will :slight_smile:

3662

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
3663

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.

3664

‘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.

3665

I have added USB dongle auto-detection. It isn’t working on your system…

What platform are you running on?

3666

This is a broadcast (device id) address.

3667

These can be ignored.

3668

Thanks for the update, I’ll try to reconfigure the whole system.

One more question: can you help me with this error:

Traceback (most recent call last):
  File "/home/wonders/ramses/ramses_rf/client.py", line 10, in <module>
    from ramses_cli.client import main
ModuleNotFoundError: No module named 'ramses_cli'

I get this if I try to run the ramses_rf client from command line to parse the log file. I’m doing this on a Ubuntu 22 with Python 3.10. Am I trying with a wrong Python version? I cloned the git repo and installed the requirements with pip.

3669

This is likely my fault.

For now, you can do:

source venv/...
cd ~/ramses_rf
pip install -e ~/ramses_rf
cat packet.log | python client.py parse
3670

I have fixed this it will get into 0.30.3.

try:
    from ramses_cli.client import main

except ModuleNotFoundError:
    import os
    import sys

    sys.path.append(f"{os.path.dirname(__file__)}/src")

    from ramses_cli.client import main

if __name__ == "__main__":
    main()

You can edit client.py like so, if you like.

3671

Thanks, I’ll try it when you push it to gitlab.
I tried the other method, but unfortunately it looks like python 3.10, which comes with Ubuntu 22.14 is too old for this package:

ERROR: Package 'ramses-rf' requires a different Python: 3.10.12 not in '>=3.11'

I’ll try to get a newer python!

3672

I follow HA - the minimum level for HA is 3.11.

add (dont replace) python 3.11 to your system, and then:

python3.11 -m venv venv
source venv/...
pip install -e ramses_rf
``
3673

Many thanks for looking through the logs. Great to know that what I’m trying to do is achievable!

I’ve tried using the send_packet service that’s documented under advanced_features in the wiki but I haven’t been able to exactly replicate the packets that are being sent by the CM927 (possibly because I can’t set the source device ID?).

Am I looking at the wrong send_packet service or is there something else that I need to do to get this to work?

3674

I have a NUC with Proxmox VE installed on it.
Homeassistant is installed as a VM on Proxmox.

ramses_cc.yaml has a line (from proxmox root directory) to find the usb dongle:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00

usb-SparkFun_evofw3_atmega32u4-if00 is a symlink to …/…/ttyACM0 (/dev//ttyACM0).

On Proxmox ramses_cc is in:
/homeassistant/custom_components/ramses_cc
and
/config/custom_components/ramses_cc (config is a symlink to /homeassistant)

3675

@zxdavb Thanks for the feedback of my log items. I am learning!

3676

The 0.30.2 releases states “implementation for RAMSES II over MQTT with evofw3-esp”.

I can’t find anything related to evofw3 supporting MQTT. Anybody knows what’s new here? Goal is to run evofw3 over WiFi+MQTT?

3677

Before that, it says:

ramses_rf, has been extensively refactored, and provides opportunities for many improvements to ramses_cc.

The key word here is opportunity.

Before, I couldn’t replace the transport layer, which is serial IO, with one which is MQTT. Now I could.

Unfortunately, the difference between the two was months of work.

Anyway, I am now waiting for the evofw3 dev to provide me with a new dongle that will run MQTT-over-WiFi. That product will create lots of useful opportunities.

Once I get one, development will start - I think it will be pretty straight-forward.

1 Like
3678

Upgraded from 0.22.40 to 0.30.2 and upgraded without any issues. No borken sensors, devices or automations
image

Will continue to monitor and test for any issues and report
Many thanks for your great work