I thought this is my HGI
18:069148: { class: HGI, alias: “evofw3” }
Is it actually my USB dongle and marked incorrectly?
I’ve included the configuration in the tickets I raised
evofw3 atmega32u4 - /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00, s/n: n/a - SparkFun - 1B4F:9206
gateway configuration
disable_discovery: false
disable_qos: false
disable_sending: false
enable_eavesdrop: false
System schema:
“01:108199”: {}
Known devices:
“01:108199”: {}
“02:022960”: {}
“04:024890”: {}
“04:049506”: {}
“04:112432”: {}
“04:123648”: {}
“04:123650”: {}
“04:123652”: {}
“04:123654”: {}
“04:125369”: {}
“04:246790”: {}
“07:030355”: {}
“13:142019”: {}
“13:181949”: {}
“18:069148”:
alias: evofw3
class: HGI
“34:007977”: {}
“34:009973”: {}
I would love to do work on that… As I have one, and would really like to monitor it more. (and add other bits and peaces with respect to my ventilation unit)
The thing is that the code base is rather large and unsure how to proceed…
Interesting. So youre heating all rooms to the same temperature with little differences here and there?
As far as I understand, its atleast better to still use HR92 (with BDR91T) and have some kind of regulations with remote thermostats (faked or T87RF)?
How were your LSVs set when you were still using evohome?
Atm, Im thoroughly looking at the graphs to “unlock how the algorithm works” and how the LSVs should be set. I cant find anywhere how the radiators should be balanced so I believe they shouldnt be at all, because HR92 should be doing the balancing needed.
Exactly atm, Im lowering LSV daily each time the same amount of one huge radiator, that is mostly responsible of heating 1/4 of the house, because others are set so low (I could “balance” this regulation by upping the setpoints on those, but atm I refuse) so clearly it kinda shows it is struggling but not over struggling or critical. Because it is always a little overshooting and undershooting, I strongly believe that sooner or later changing of LSV will show some difference on some graph at some point.
IOW, Im trying “to tame beast” by “proving” if LSV has any effect at all.
EDIT:
On a side note: on this huge radiator I also have strategically placed for accuracy of reading 8x DS18B20 on flow and 8x DS18B20 on return and in HA I made “maximums” for each of flow and return, and then on top of these max also delta T. I cant for the life of me figure out how one should look at delta T reading, because on a cold radiator, flow always shoots up, so the delta T can be as high as 25C. Then after few minutes, when flow starts to go down, the return is already climbing and it takes again the same amount of minutes when both are in 2-3-4C delta T range. After that it just wobles up or down a little.
So at what point should one take the delta T reading seriously: when the flow reaches its peak for the first time or at any point after that when everything is “stabilized”?
EDIT2:
Its interesting to see a genius like you ditch evohome so Im curious if “ease of use” of LSVs was the main culprit that weighted the scale against imperfections and troubles of using evohome.
@zxdavb Does 0.50.0 include a fix for ramses_cc.get_zone_schedule service failing (#183) ?
Currently on 0.42.0 and it fails (timeouts) with that version
No - I get the same error unfortunately
Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/ramses_cc/climate.py:468
integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 16:19:04 (1 occurrences)
Last logged: 16:19:04
[546805544800] Error handling message: Unknown error (unknown_error) Donald from 192.168.1.72 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.1.1 Safari/605.1.15)
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 28, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 816, in handle_execute_script
script_result = await script_obj.async_run(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
msg.get("variables"), context=context
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1801, in async_run
return await asyncio.shield(create_eager_task(run.async_run()))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 464, in async_run
await self._async_step(log_exceptions=False)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 528, in _async_step
self._handle_exception(
~~~~~~~~~~~~~~~~~~~~~~^
ex, continue_on_error, self._log_exceptions or log_exceptions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 558, in _handle_exception
raise exception
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 526, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 764, in _async_call_service_step
response_data = await self._async_run_long_action(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<9 lines>...
)
^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 727, in _async_run_long_action
return await long_task
^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2802, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2845, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1007, in entity_service_call
single_response = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
hass, entity, func, data, call.context
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1079, in _handle_entity_call
result = await task
^^^^^^^^^^
File "/config/custom_components/ramses_cc/climate.py", line 468, in async_get_zone_schedule
await self._device.get_schedule()
File "/usr/local/lib/python3.13/site-packages/ramses_rf/system/zones.py", line 167, in get_schedule
await self._schedule.get_schedule(force_io=force_io)
File "/usr/local/lib/python3.13/site-packages/ramses_rf/system/schedule.py", line 254, in get_schedule
await asyncio.wait_for(
self._get_schedule(force_io=force_io), timeout=timeout
)
File "/usr/local/lib/python3.13/asyncio/tasks.py", line 507, in wait_for
return await fut
^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/ramses_rf/system/schedule.py", line 296, in _get_schedule
fragment = await get_fragment(frag_num)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/ramses_rf/system/schedule.py", line 274, in get_fragment
pkt: Packet = await self._gwy.async_send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cmd, wait_for_reply=True, priority=Priority.HIGH
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/local/lib/python3.13/site-packages/ramses_rf/gateway.py", line 626, in async_send_cmd
return await super().async_send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<7 lines>...
) # may: raise ProtocolError/ProtocolSendFailed
^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/gateway.py", line 326, in async_send_cmd
return await self._protocol.send_cmd(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<5 lines>...
) # may: raise ProtocolError/ProtocolSendFailed
^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/protocol.py", line 711, in send_cmd
pkt = await super().send_cmd( # may: raise ProtocolError/ProtocolSendFailed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<5 lines>...
)
^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/protocol.py", line 481, in send_cmd
return await super().send_cmd(cmd, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/site-packages/ramses_tx/protocol.py", line 225, in send_cmd
return await self._send_cmd(
^^^^^^^^^^^^^^^^^^^^^
...<5 lines>...
)
^
File "/usr/local/lib/python3.13/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.13/site-packages/ramses_tx/protocol_fsm.py", line 333, in send_cmd
await asyncio.wait_for(fut, timeout=timeout)
File "/usr/local/lib/python3.13/asyncio/tasks.py", line 507, in wait_for
return await fut
^^^^^^^^^
ramses_tx.exceptions.ProtocolSendFailed: <ProtocolContext state=WantRply echo=0404|RQ|01:108199|0501, tx_count=4/4>: Exceeded maximum retries
This post may be helpful for some who are struggling to create custom commands for remotes:
No, no fix: I had a quick look, and I have no idea why/how it broke.
Are you using MQTT?
I am running the Ramses RF integration on Home Assistant on a Rasperry Pi 5 which has MQTT running as another integration.
How would you feel about increasing the timeout as an experiment?
That’s too easy - I tried!
This is certainly a bit odd. I’ve tried moving the evofw3 to my PC and sending the RQ packet via putty. And no response. I know my setup is ok as I tried to send a 0004 packet and got a valid answer. It is almost as if the 0404 packet is no longer being recognised by the controller.
I’ve tried searching for an old packet log when this was working but with no success.
For info, this is the RQ packet:
RQ --- 18:136212 01:185426 --:------ 0404 007 02200008000100… and I can add that it appears a valid RQ|0404|02xx packet (to request the first fragment of the schedule for zone 0x02).
Below is an actual RQ/RP pair (albeit for zone 0x00)…
2021-03-20T22:57:00.662479 000 RQ --- 18:139815 01:201047 --:------ 0404 007 00200008000100
2021-03-20T22:57:00.719326 081 RP --- 01:201047 18:139815 --:------ 0404 048 0020000829010268816DCA311100210C05D11F2019F08320B450A0E4A49C303AA0D82D779E745B26F53ADAB3345DFAE2
To me, it is simply like the controller no longer replies to these RQs.
Hi,
I’m not sure of the best place to post this but would appreciate any wisdom!
My boiler diagnostics as reported by Ramses RF show that there is 99% heat demand, it’s calling for 70 degrees and the current flow temperature is 58, but the boiler isn’t firing, see screenshot for more:
My setup is Evohome, with an RA8810 Opentherm controller, Nefits OT to EMS converter, and Worcester Bosch Greenstar 42CDi.
I also have a BBQKees EMS interface to monitor the EMS side of the equation. It also shows that the thermometer is calling for heat but the boiler isn’t firing. The ‘Burner selected max power’ stays at 0%.
I’ve written an automation that runs every 5 minutes and checks if Heat Demand is > 10%, and current flow temperature is below target, then set ‘Burner selected max power’ to 74% (this is the max for the boiler). This seems to fire up the boiler and the system performs as I would expect it to, albeit with more cycling than I’d like.
If I disable the automation the boiler will occasionally fire up but nowhere near enough to meat the demand.
Any ideas on why the boiler wouldn’t be firing without my crude automation?
I agree.
I think the latest version of Evohome firmware (02.01.01.01) was released April this year. Ramses 0.31.16 was released March 30th. First bug report I can find for get_zone_schedule service failing was April 16th. In my mind not beyond the realms of possibility that 02.01.01.01 has broken this.
Yes - I had done all I could with it & ran out of ideas … Looks like we’ve lost that functionality. 
While setting up Ramses_cc I experienced sensor values going from their correct, recently received status to ‘Unavailable’ all the time, in a time frame of about a minute.
Aforementioned did occur with Ramses_ESP over MQTT but not over serial port. As it turns out, when the Ramses_ESP SNTP server is not configured, MQTT messages are dated with year 1970, probably causing Ramses_cc to believe these are very old and therefore triggering the ‘Unavailable’ status.
Fixing this is easy: configure the SNTP server (see Ramses_ESP docs) and reset the device.
Knowing this, it could helpful for new users if Ramses_cc would log a warning on reception of a message dated such a long time ago, or something similar.
@hsluis @brjhaverkamp reading backwards a bit I believe this might help you.
Last hour I setup the SNTP server and setup the RAMSES_ESP in MQTT mode again. First impression, no unavailable situations untill now. To be certain I need to evaluate longer, but I have a good feeling that this solved the issues. Your explanation is very logical, thank you so much.