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

Hi Katagia,

Thanks for your reply.
On your first question, indeed, I want to have it work via wifi and mqtt. As my raspberry pi is already getting full with USB devices that I can’t separate away from it. So I thought this one could be in an other corner on a USB charger.

Interesting about the 2 interfaces. Unfortunately, here it only adds ttyACM0. I did a
ls -al /dev/tty* | wc -l to check if I missed any, but it only goes up from 98 to 99 devices when I plug it in. Wow, didn’t know there were that many tty’s :slight_smile:

Thanks for the explanation on the serial terminal. I installed putty as well, but al it did after I filled in the port and speed (115200) and press OK, was beep. No error message, but also no screen or anything. Just a single beep.

I tried screen after: screen /dev/ttyACM0 115200. But that gave me a black terminal screen with occational gibberish. No nice boot process to watch.
Are my serial settings wrong? That would be the obvious mistake at this point…
What are the correct settings?

Bert

@katagia answer is not helpful.

Most esp32 devices have 2 physical usb connectors.

The first is connected to a serial port via a serial usb chip.

The second is connected directly to a usb interface.

The RAMSES-ESP device Bert has only includes the second interface. It is configured to use the hardware JTAG/serial interface.

In Windows this shows up as two COM ports.

Unfortunately I’m not familiar with h how my device shows up in Ubuntu. Maybe someone who uses the RAMSES-ESP successfully n this environment can confirm which interface they use.

Bert is trying to configure the RAMSES:ESP firmware

Peter added some clarification. I have 2 physical connectors and 2 interfaces. Looks like yours has only one.

The problem with those integrated USB/UART converter is that the terminal programm must open the device as soon as it appears. Putty can’t do that but others. When the terminal is opened after the boot process, the log has been sent and you can’t see it anymore.

Tha’s also the reason why you just see an empty terminal with putty. Just setting the com port should be fine as the baud rate normally is not relevant for integrated UART.

Can you must the “occational gibberish”? Is is something text based?

Did you set Terminal → Local Echo → Force On?
That helps a lot because else you won’t see your own typing.
What happens when you enter “help” and press return?

Hiu Katagia,

I was not even getting there. I don’t get an empty terminal with putty, I can’t even get past the configuration screen. After pressing OK, Putty just beeps, and then nothing…
no error, no console message, nothing.

But I made progress while writing this email.
your local echo explanation helped!! when I run
screen /dev/ttyACM0 115200,echo
I can type reset and I get the boot text

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x40375b2c
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce3810,len:0x48c
load:0x403c9700,len:0x4
load:0x403c9704,len:0x990
load:0x403cc700,len:0x25a0
entry 0x403c9858
# ramses_esp 0.4.9

Now lets get wifi to work :slight_smile:
Thanks a lot!!

Hi,

Today I installed my new Ramses-ESP. It picks up the information of my Evohome system, but every couple of minutes the information of the units is unkown. Is there a setting I missed?

I all, I got quite a bit further. Wifi and MQTT have been configured.
I installed Ramsess_cc. The latest version, 0.42.0
I first tried to configure it in configuration.yaml, following the wiki.
But then the logfile informed me that ramses_cc: in configuration.yaml was depreciated, and I need to use config_flow.
But I am struggling to get a it set up correctly.
I’'m not sure how to configure mqtt there. The config option only mentions a serial port. I filled it in as: mqtt://mqttUser:[email protected]:1883
But I get the following errors in the logfile:

Logger: homeassistant.config_entries
Source: config_entries.py:604
First occurred: 7:35:27 PM (3 occurrences)
Last logged: 7:38:06 PM
Error setting up entry RAMSES RF for ramses_cc
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 604, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ramses_cc/__init__.py", line 94, in async_setup_entry
    await broker.async_setup()
  File "/config/custom_components/ramses_cc/broker.py", line 146, in async_setup
    await self.client.start(cached_packets=cached_packets())
  File "/usr/local/lib/python3.12/site-packages/ramses_rf/gateway.py", line 186, in start
    await super().start()  # TODO: do this *after* restore cache
    ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/gateway.py", line 195, in start
    self._transport = await transport_factory(
                      ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/transport.py", line 1321, in transport_factory
    ser_instance = get_serial_instance(port_name, port_config)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/transport.py", line 1278, in get_serial_instance
    ser_obj = serial_for_url(ser_name, **ser_config)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/serial/__init__.py", line 85, in serial_for_url
    raise ValueError('invalid URL, protocol {!r} not known'.format(protocol))
ValueError: invalid URL, protocol '"mqtt' not known

So obviously my guess was wrong :slight_smile:
So how do you set up an mqtt device with config_flow?

Regards,

Bert

Hi all, Quick update. I toyed with the config some more and it turned out that I had a hash, # in my password. When I converted that to %23, the rest went smoothly. I have a configured device now and a thermostat card to work with!

Hiya, I’ve just installed your zone cards and they are great thank you. Have you shared the hot water card anywhere? I’d love to try it to thanks.

Extract below. Just update the water heater entity (water_heater.01_182924_hw)

image

type: custom:stack-in-card
keep:
  background: "true"
cards:
  - type: custom:button-card
    entity: water_heater.01_182924_hw
    name: |
      [[[ return entity.attributes.friendly_name; ]]]
    show_name: true
    show_state: false
    show_icon: false
    show_label: true
    label: |
      [[[ return entity.attributes.current_temperature + ' °C'; ]]]
    tooltip: >
      [[[ return 'Operation Mode (' + entity.attributes.operation_mode + ') ';
      ]]]
    styles:
      card:
        - height: 100px
      label:
        - font-size: 28px
      name:
        - font-size: 16px
        - padding: 0px 0px 10px 0px
      tooltip:
        - font-size: 12px
  - type: custom:button-card
    entity: water_heater.01_182924_hw
    name: Setpoint
    show_name: false
    show_state: false
    show_icon: true
    show_label: true
    color_type: card
    layout: icon_label
    size: 100%
    icon: |
      [[[
        if (entity.attributes.operation_mode == 'on') return 'mdi:water-plus';
        if (entity.attributes.operation_mode == 'boost') return 'mdi:water-plus';
        else return 'mdi:water';
      ]]]
    label: |
      [[[ return entity.attributes.temperature + ' °C'; ]]]
    tooltip: |
      [[[ return 'Climate Mode (' + entity.attributes.mode.mode + ') '; ]]]
    styles:
      card:
        - height: 36px
        - font-size: 16px
        - color: "#FAFAFA"
        - background-color: |
            [[[
              if (entity.attributes.current_temperature < '5') return 'dimgray';
              if (entity.attributes.current_temperature >= '5' && entity.attributes.current_temperature < '20') return 'steelblue';
              if (entity.attributes.current_temperature >= '20' && entity.attributes.current_temperature < '30') return 'seagreen';
              if (entity.attributes.current_temperature >= '30' && entity.attributes.current_temperature < '40') return 'darkorange';
              if (entity.attributes.current_temperature >= '40') return 'firebrick';
              else return 'indigo';
            ]]]
      tooltip:
        - font-size: 12px

Thanks - working

Hi all,

I am moving forward one step at the time. But I am running into the next issue. My devices in HA keep becoming unknown and then reapearing. In the HA log I see loads of errors. Good thing HA combines similar message:

Logger: ramses_tx.transport
Source: runner.py:189
First occurred: October 8, 2024 at 8:32:08 PM (14282 occurrences)
Last logged: 7:24:47 PM

    MqttTransport(QosProtocol(WantEcho, len(queue)=2)): Discarding write (tokens=-0.74)
    MqttTransport(QosProtocol(WantEcho, len(queue)=1)): Discarding write (tokens=-0.73)
    MqttTransport(QosProtocol(WantEcho, len(queue)=2)): Discarding write (tokens=-0.73)
    MqttTransport(QosProtocol(WantEcho, len(queue)=1)): Discarding write (tokens=-0.72)
    MqttTransport(QosProtocol(WantEcho, len(queue)=2)): Discarding write (tokens=-0.71)

And an other highrunner.

Logger: ramses_tx.protocol_fsm
Source: runner.py:189
First occurred: October 8, 2024 at 8:31:28 PM (29836 occurrences)
Last logged: 7:24:48 PM

TOUT.. = <ProtocolContext state=WantEcho cmd_=000A|RQ|01:205429|00, tx_count=1/4>: echo_timeout=0.5
TOUT.. = <ProtocolContext state=WantEcho cmd_=0008|RQ|13:144633, tx_count=1/4>: echo_timeout=0.5
TOUT.. = <ProtocolContext state=WantEcho cmd_=0004|RQ|01:205429|00, tx_count=1/4>: echo_timeout=0.5
TOUT.. = <ProtocolContext state=WantEcho cmd_=1100|RQ|13:144633, tx_count=1/4>: echo_timeout=0.5
TOUT.. = <ProtocolContext state=WantEcho cmd_=000C|RQ|01:205429|000F, tx_count=1/4>: echo_timeout=0.5

This one shows at least some exception

Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:147
First occurred: October 8, 2024 at 8:45:36 PM (27 occurrences)
Last logged: 7:18:42 PM

Error doing job: Task exception was never retrieved (None)
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/asyncio/tasks.py", line 520, in wait_for
    return await fut
           ^^^^^^^^^
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/protocol_fsm.py", line 333, in send_cmd
    await asyncio.wait_for(fut, timeout=timeout)
  File "/usr/local/lib/python3.12/asyncio/tasks.py", line 519, in wait_for
    async with timeouts.timeout(timeout):
  File "/usr/local/lib/python3.12/asyncio/timeouts.py", line 115, in __aexit__
    raise TimeoutError from exc_val
TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/ramses_rf/gateway.py", line 628, in async_send_cmd
    return await super().async_send_cmd(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/gateway.py", line 326, in async_send_cmd
    return await self._protocol.send_cmd(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/protocol.py", line 711, in send_cmd
    pkt = await super().send_cmd(  # may: raise ProtocolError/ProtocolSendFailed
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/protocol.py", line 481, in send_cmd
    return await super().send_cmd(cmd, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/protocol.py", line 225, in send_cmd
    return await self._send_cmd(
           ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/protocol.py", line 660, in _send_cmd
    return await self._context.send_cmd(send_cmd, cmd, priority, qos)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/ramses_tx/protocol_fsm.py", line 343, in send_cmd
    raise exc.ProtocolSendFailed(msg) from err  # make msg *before* state reset
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ramses_tx.exceptions.ProtocolSendFailed: <ProtocolContext state=WantEcho cmd_=2309| W|01:205429|00, tx_count=4/4>: Expired global timer after 20.0 sec

What is happening here? Is this a configuration issue, or a real bug ?

Regards,

Bert

Hi,

I am experiencing the same issue as Bert, in my log I see the messages:

Logger: ramses_tx.transport
Bron: /usr/local/lib/python3.12/site-packages/ramses_tx/transport.py:1114
Eerst voorgekomen: 8 oktober 2024 om 20:04:28 (198 gebeurtenissen)
Laatst gelogd: 11:14:47

MqttTransport(QosProtocol(WantEcho, len(queue)=3)): the MQTT topic is offline: RAMSES/GATEWAY/18:227312
MqttTransport(QosProtocol(WantEcho, len(queue)=6)): the MQTT topic is offline: RAMSES/GATEWAY/18:227312
MqttTransport(QosProtocol(WantEcho, len(queue)=7)): the MQTT topic is offline: RAMSES/GATEWAY/18:227312
MqttTransport(QosProtocol(WantEcho, len(queue)=4)): the MQTT topic is offline: RAMSES/GATEWAY/18:227312
MqttTransport(QosProtocol(WantEcho, len(queue)=2)): the MQTT topic is offline: RAMSES/GATEWAY/18:227312

Also when I try to change the preset mode I get an error and the sensor becomes unavailable for a couple of minutes.

Hi hsluis.

Sorry to hear you have the same problem. But good to hear there are more people with the same issue.
I indeed also see the offline/online messages in my log.
There are 79 by now. Perfectly matching eachother.
The messages I sent earlier are however in the 46.000 and 20.000.
I also have checked for all RAMSES related messages in Node-Red. There is a continous wave/tsunami of them. It looks like something is going wrong in the mqtt stack of RAMSES_CC
Anyone else seeing this?
Or anyone else with the RAMSES_CC +MQtt conbination that doesn’t have this. That is a datapoint as well.

Logger: ramses_tx.transport
Source: /usr/local/lib/python3.12/site-packages/ramses_tx/transport.py:1114
First occurred: October 9, 2024 at 8:46:25 PM (79 occurrences)
Last logged: 12:44:18 PM

MqttTransport(QosProtocol(WantEcho, len(queue)=3)): the MQTT topic is offline: RAMSES/GATEWAY/18:017268
MqttTransport(QosProtocol(WantEcho, len(queue)=5)): the MQTT topic is offline: RAMSES/GATEWAY/18:017268
MqttTransport(QosProtocol(WantEcho, len(queue)=2)): the MQTT topic is offline: RAMSES/GATEWAY/18:017268
MqttTransport(QosProtocol(WantEcho, len(queue)=1)): the MQTT topic is offline: RAMSES/GATEWAY/18:017268
MqttTransport(QosProtocol(WantEcho, len(queue)=0)): the MQTT topic is offline: RAMSES/GATEWAY/18:017268

and

Logger: ramses_tx.transport
Source: /usr/local/lib/python3.12/site-packages/ramses_tx/transport.py:1122
First occurred: October 9, 2024 at 8:43:36 PM (79 occurrences)
Last logged: 12:40:00 PM

MqttTransport(QosProtocol(WantEcho, len(queue)=4)): the MQTT topic is online: RAMSES/GATEWAY/18:017268
MqttTransport(QosProtocol(WantEcho, len(queue)=3)): the MQTT topic is online: RAMSES/GATEWAY/18:017268
MqttTransport(QosProtocol(WantEcho, len(queue)=1)): the MQTT topic is online: RAMSES/GATEWAY/18:017268
MqttTransport(QosProtocol(WantEcho, len(queue)=5)): the MQTT topic is online: RAMSES/GATEWAY/18:017268
MqttTransport(QosProtocol(WantEcho, len(queue)=2)): the MQTT topic is online: RAMSES/GATEWAY/18:017268

Regards,

Bert

For the benefit of anyone who has a similar problem in the future, both of these issues were as a result of not removing the original yaml configuration.

Hi Lloyd,
For the avoidance of doubt, which “both issues” are you refering to? Not the one from me and hsluis, right? On my side at least it is still unresolved.

Bert

Apologies, I should have quoted my original post, now edited. And no, not the ones from you or hsluis.

Hi Lloyd,
No problem. Happy to hear your issue is solved. But our isn’t yet, and I wanted to make sure it was clear it that we are still looking for support…

Can anyone help us digging into the appearing/disappearing devices? And/or the flood of errors about mqtt mesages, that are likely related? Any debugging I can do on my side?

Regards,

Bert

It appears all your issues are being caused by an unreliable connection at the MQTT layer.

You could, for example, relocate your RAMSES_ESP device to a place where it’s likely to get the best WiFi signal.

Hi David,

Thanks for your pointer. I think wifi reception is fine. At least in the same room, I have full bars on my phone and my rpi with home assistant also doesn’t have any issue.
Is there a way to verify the wifi on the device? e.g. with a command on the serial bus?

Regards,

Bert