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

Share your Projects!
2307

So finally something is working again… Took me some time to get it up and running. Fore sure I thought there would be someting softwarewise bu as it turned out (I do not quite understand what was going on) it was a combination of things related to the HGI80. That is some nasty piece of electronics… I ordered a NanoCul this week since I think that is going to be (hopefully) more stable

  • Saw that my items were failing, so to say not updating
  • In the errorlog of HASS strangely I spotted nothing really strange, it seemed to be doing its thing
  • But still my items in HASS were not updating
  • Saw that the packetlog was also frozen, meaning no packeges were recorded (still really dont understand this in relation to the HASS logfile which showed decoding of messages)
  • Restored older versions to see if this would help, no to avail. Still freezing
  • In the mean time it seemed to freeze earlier then before, no idea why
  • Suddenly I realized that the power failure I had some time ago
  • I have a UPS feeding my network stuff, but since the NAS had shut itself down because that is what it does with regards to safety
  • BUT the VMs that run on this NAS (still havent fixed this) were inproperly shut down (need to install a NUT client that talks to the Synology → my opinion Synology you could have done a better job! Just give the user a interface to this to safely shutdown the NAS…)
  • The VMs were (phew…) running fine so was thinking it is fixed.
  • But as it turned out, the HGI has not been powerless, that was this first thing I did to proper reset that tricky thing
  • After this reset it would not identify my HGI80 anymore (no device allocated) why??
  • It would ONLY come to life after I had found (was a bit of a search) of the specific ti_3410.fw file and restored this to the firmware folder. (for the one needing this fw file please contact me I can share)
  • As it turned out this fw file had never been there, how on earth could the HGI have run still puzzles me.

Now it is running the last hours (will give it some more time) and I have trust it will not stall anymore. This HGI is a tricky piece… Since all my other (FTDI / Zwave stuff) runs without a problem… See if the Nanocul is more stable. The only thing I see (running 0.8.12) is below: just once:

2022-01-27 15:08:59 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback SerialTransport._read_ready()
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.9/site-packages/serial_asyncio/__init__.py", line 119, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 477, in data_received
    self._line_received(dtm, _normalise(_str(raw_line)), raw_line)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 460, in _line_received
    self._pkt_received(pkt)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 704, in _pkt_received
    self._qos_received(pkt)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 762, in _qos_received
    logger_rcvd(msg, wanted=wanted)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/transport.py", line 723, in logger_rcvd
    pkt._hdr or str(pkt),
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 353, in _hdr
    self._hdr_ = pkt_header(self)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 480, in pkt_header
    return f"{header}|{pkt._ctx}" if isinstance(pkt._ctx, str) else header
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 342, in _ctx
    self._ctx_ = self._idx
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 364, in _idx
    self._idx_ = _pkt_idx(self) or False
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/frame.py", line 439, in _pkt_idx
    raise InvalidPayloadError(
ramses_rf.protocol.exceptions.InvalidPayloadError: Corrupt payload: Packet idx is 01, but expecting no idx (00)
2308

Hi, I have 2 controllers off one boiler using 2 x raspberry pi, they work well in my case, I’ve got a main hassos VM and using remote_homeassistant to pushh the evohome sensors and stuff into my main hassos.
I can’t help much with the placement of the pi’s though both of mine are next to each other with one controller on the other side of a wall and the other controller down stairs
The only thing I would say is if you want to use any automations, use the rpi that is for that controller.

1 Like
2309

boiler_output_temp - same
boiler_return_temp - not available
boiler_setpoint - same
ch_max_setpoint - same
ch_water_pressure - different decimal places but similar data
dhw_flow_rate - not available (system boiler)
dhw_setpoint - with _OT has correct value, without is “Unavailable”
dhw_temp - not available (but may only be available during a reheat which is infrequent)
outside_temp - not available (no sensor)
rel_modulation_level - same

2310

Thanks, it’s helpful to know that general setup works.

This has now made me wonder whether I could use such a set up to effectively relay messages, by faking them on the instance nearest to the controller they’re bound to, and helping to improve the reliability of those signals reaching the controller they’re intended for. If that would work, I could site the two evohome controllers differently and enhance the coverage they get by using the two evohome_cc instances to relay messages from more distant devices.

I guess to do this i’d need to have a carefully defined known_list on each instance, so that they’d only listen to messages from the devices local to them, and then fake those devices bound to the far controller on the instance nearest to it.

I’ve no idea if this is feasible, I wonder if it could be?

2311

Hello,

Sorry for the late reply, but here is what I see on my system:

  • boiler_output_temp → looks the same (with values)
  • boiler_return_temp → looks the same (permanently at 1 degree C)
  • boiler_setpoint → The boiler_setpoint has data (looks ok), the ot_boiler_setpoint is unavailable
  • ch_max_setpoint → ch_max_setpoint is unavailable, the ot_ch_max_setpoint has data (looks ok)
  • ch_water_pressure → both unavailable
  • dhw_flow_rate → both unavailable
  • dhw_setpoint → dhw_setpoint is unavailable, the ot_dhw_setpoint has data (always at 0.1 degree C)
  • dhw_temp → both unavailable
  • outside_temp → both unavailable
  • rel_modulation_level → both have data and the data are quite different. I have no clue which one is the most plausible one :thinking:
2312

Hi,

I’ve just update to 0.18.3 (I was running 0.17.13 before because the versions 0.18.1 and 0.18.2 would not start on my system - see error logs already provided in a previous post).

The good news is that 0.18.3 starts and I can now see the heat demand of one of my UFH zone :champagne:. This is the first time I see that, previously none of my UFH zone would be available.
The heat demand for the other UFH zones are still unavailable unfortunatelly and I have the follwoing errors:

Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:592
Integration: Sensor (documentation, issues)
First occurred: 10:31:59 PM (1 occurrences)
Last logged: 10:31:59 PM

Platform evohome_cc does not generate unique IDs. ID 02:024358-heat_demand already exists - ignoring sensor.02_024358_heat_demand

Logger: homeassistant.components.sensor
Source: custom_components/evohome_cc/sensor.py:129
Integration: Sensor (documentation, issues)
First occurred: 10:31:59 PM (2 occurrences)
Last logged: 10:31:59 PM

Error adding entities for domain sensor with platform evohome_cc
Error while setting up evohome_cc platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 520, in _async_add_entity
    original_icon=entity.icon,
  File "/config/custom_components/evohome_cc/sensor.py", line 175, in icon
    return "mdi:power-plug" if self.state else "mdi:power-plug-off"
  File "/config/custom_components/evohome_cc/sensor.py", line 129, in state
    return state * 100 if state is not None else None
TypeError: unsupported operand type(s) for *: 'Message' and 'int'


Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:98
First occurred: 10:27:10 PM (3 occurrences)
Last logged: 10:47:10 PM

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/helpers.py", line 17, in execute_func
    return fnc(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 131, in wrapper
    return fnc(self, discover_flag=discover_flag)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1124, in _discover
    [self._make_cmd(_000A, payload=ufh_idx) for ufh_idx in self._circuits_alt]
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1176, in _circuits_alt
    if msg := self._msgz[_0005][RP]["0009"]:  # also 0000, 0004
KeyError: '0005'

I send you a PM with my packetlog in parallel in case you need it.

2313

Running 0.18.3 now and have amended settings as follows

  ramses_rf:
    enforce_known_list: true
    # disable_discovery: true
    disable_sending: true
    # enable_eavesdrop: true

On startup I see two very similar errors:

2022-01-28 10:40:04 ERROR (MainThread) [homeassistant.components.sensor] Error adding entities for domain sensor with platform evohome_cc
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 520, in _async_add_entity
    original_icon=entity.icon,
  File "/config/custom_components/evohome_cc/sensor.py", line 175, in icon
    return "mdi:power-plug" if self.state else "mdi:power-plug-off"
  File "/config/custom_components/evohome_cc/sensor.py", line 129, in state
    return state * 100 if state is not None else None
TypeError: unsupported operand type(s) for *: 'Message' and 'int'

2022-01-28 10:40:04 ERROR (MainThread) [homeassistant.components.sensor] Error while setting up evohome_cc platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 257, in _async_setup_platform
    await asyncio.gather(*pending)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 382, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 520, in _async_add_entity
    original_icon=entity.icon,
  File "/config/custom_components/evohome_cc/sensor.py", line 175, in icon
    return "mdi:power-plug" if self.state else "mdi:power-plug-off"
  File "/config/custom_components/evohome_cc/sensor.py", line 129, in state
    return state * 100 if state is not None else None
TypeError: unsupported operand type(s) for *: 'Message' and 'int'

I also see very different data collected now, presumably as a result of using “disable_sending: true” for example:

boiler_output_temp - Unavailable
OT boiler_output_temp - Working

boiler_setpoint - Working
OT boiler_setpoint - Unavailable

I am fairly certain that prior to setting “disable_sending: true”, the UFH controller was being disrupted in some way. I am (and have been for the last couple of weeks) paying close attention to the UFH system as it is new . I have not seen any behaviour which might be considered strange when the evohome_cc is not running, nor when sending is disabled. However, when sending has been enabled the UFH controller has gone into an error state (0.17.3) and has flashed error lights (which I have only noticed whilst walking past the UFH controller). In addition, Zones have switched off with 100% demand showing on the controller, zones have switched on with 0% demand showing on the controller. Of course, at present I have no definitive proof of the link between what evohome_cc is doing and the odd behaviour I am seeing.

2314

I’ve not had any more of these.

2315

Being a newbie to evohome_cc I have some questions I’d appreciate some help on:

  1. I’m having issues with the yaml configuation. I have the basic communication up and running but some commands in the evohome_cc wiki seem to break things. For example if I add the “restore_state: true” command to my configuration then the HA “Check Configuration” operation hangs and if I try a Restart Core I get a “Failed to restart Home AssistantCore. string indices must be integers” error. As an aside, even if I put a dumb command in the YAML I assume it shouldn’t hang?

  2. What is the “send_packet:” command/option for?

  3. I’ve seen the alias command in some configurations, what’s its use/purpose:

known_list:
  - '01:188379' : {"alias": "--controller--"} # Controller

  1. Is there a definitive list of configuration parameters (for the yaml file) anywhere, as a reference. Initially I was using some depreciated ones in error.

  2. Re. the schema (which I can see in the HA logs), is there a mechanism to map the zone names to the relevant xx:yyyyyy items or does that need to be done by hand, i.e. the names of all the RAMSES RF entities in HA.

  3. Currently I still have the standard HA Integration for evohome running too. Is that considered bad practice or will they both play-nice together.

Thanks in advance.

2316

@all I would be very grateful it you could help each other out as much as possible - so I can concentrate on doing only what I can do.

If someone remains stuck after help from the community, I will chip in.

Also, if the wiki is out of date - and it is - it would help if people worked to keep it up to date for the benefit of everyone.

For example, it’s restore_cache: true.

No, and N/A.

… I’ve got a long to-do list here, over to you.

1 Like
2317

Hi,

I’ll try to answer to the best of my knowledge but I might be wrong on some points (anyone should feel free to correct me if this is the case).

Answers to your question:

  1. the “restore_state: true” has been changed to “restore_cache: true” in the configuration ( this was a breaking change which happened a few version back). Changing this should solve your problem.

  2. I’m not 100% sure what you mean here. If it’s a question about an option in the yaml configuration, you can use some advanced options to do eavesdropping only without sending packets. I believe send_packet might be one of the option you can use to prevent the dongle emitting packets in case you want to do eavesdropping (but I never used this so I am really unsure here).

  3. The alias enables you to provide more information for some devices. This can be necessary in some cases (faked sensor, ventillation unit, RF remote control, …). For the other cases like the controller case you mention this is just a way to add information to help you read your schema so you know which device corresponds to what.

  4. I think the best place to start is the Github wiki. David is developping the project quickly at the moment and it evolves every week (thanks again Davis :slight_smile: ) so this information can be a bit out of date and needs to be complemented with the posts from this forum discussion.

  5. That’s where the Alias can help. Once you have mapped a device name to a zone you can put the corresponding alias in you config to remember this mapping. Concerning the entity displayed in HA, you need to rename them by hand as far as I know.

  6. I also have the cloud based evohome integration running in parallel and have not had any problem beause of this so far. As far as I know this is not a problem (and David is the one who developped both integrations).

edit: Sorry was typing while David replied in parallel so some of my answers may be redundant to what David already said…

1 Like
2318

send_packet: true enables the send_packet service call. It allows you to broadcast bespoke packets via RF. I doubt it would be of value to most, especially as it does not yet allow impersonation.

The only parameters it accepts presently are:

parameter description example
device_id The destination device_id. 01:123456
verb The packet verb, one of: I, RQ, RP, W. RQ
code The packet code (class). 1F09
payload The packet payload as a hexadecimal string. 00
2319

I didn’t know a send_packet service existed. I am very interested to use it to simulate packets sent from my RF remote control to control my ventillation (for instance to boost it temporarily instead of having to press on the button of the remote control).

I am trying to emulate this type of packet:

2022-01-11T13:28:06.767137 063  I --- 29:156898 32:132125 --:------ 22F3 007 00020F03040000

I have added the send_packet: true in my configuration and tried to send packets using the following service call (and various variation on it):

service: evohome_cc.send_packet
data:
  device_id: '32:132125'
  verb: I
  code: 22F3
  payload: 00020F03040000

I get the following error:

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/connection.py:134
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 1:30:36 PM (7 occurrences)
Last logged: 3:00:14 PM

[139955753060912] Error handling message: value must be one of [' I', ' W', 'RP', 'RQ'] for dictionary value @ data['verb']. Got None
[139955753060912] Error handling message: does not match regular expression ^[0-9A-F]{4}$ for dictionary value @ data['code']. Got None value must be one of [' I', ' W', 'RP', 'RQ'] for dictionary value @ data['verb']. Got None
[139955475062448] Error handling message: value must be one of [' I', ' W', 'RP', 'RQ'] for dictionary value @ data['verb']. Got None

Am I doing something wrong ?

2320

@All long standing evohome_cc users

As David mentions, the Wiki at Home · zxdavb/evohome_cc Wiki · GitHub is not up to date. Being a newbie to evohome_cc, I have struggled to put together a complete configuration. And reading this entire thread is probably not realistic given its length. I have just amended the Wiki to correct the “restore_cache” option. I’m happy to make some other changes to the Wiki to simplify the getting started steps for other newbies.

To do so, I need to be reasonably certain that I understand things myself. To that end, it would be helpful if others who have fully working and comprehensive evohome_cc configs could post them here or PM them to me. I think it would also be helpful to have logger configs too. I think my config below (slightly simplified from what I am actually running) is all correct. I am unclear on exactly how the alias bit can be used and I removed it because it was not doing what I wanted.

evohome_cc:
  serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  packet_log: packet.log
  restore_cache: true
  ramses_rf:
    enforce_known_list: true
    # disable_discovery: true
    disable_sending: true
    # enable_eavesdrop: true 
  schema:
    controller: 01:123456
  known_list:
    - 01:123456
    - 02:234567
    - 04:456789
    - 07:789012
    - 10:101234
    - 13:134567
    - 18:189012
    - 34:345678

logger:
  default: warn
  logs:
    ramses_rf: warn
    ramses_rf.message: warn
    evohome_rf.packet_log: debug

Please let me know if I’ve got anything wrong, and I’d appreciate explanation of the detail of the alias feature. Once I’m clear I’ll spend a bit of time updating the Wiki.

2321

This is the only logging you should bother with:

  logs:
    # homeassistant.core: debug  # to see: Event state_changed, or not

    # custom_components.evohome_cc: info  # use info for Schema =

    ramses_rf.message: info                # MSGs rcvd (excl. RQ/18:), is the one you usually want
    # ramses_rf.protocol.protocol: info    # PKTs sent (excl. retries) & rcvd
    # ramses_rf.protocol.transport: info   # RF Tx'd (incl. retries) & Rx'd

See: https://github.com/zxdavb/evohome_cc/wiki/5.-Troubleshooting

Note that the above makes no mention of the gateway, active_fault & schema binary sensors, but should.

2322

@bishop Your Zone 5 is misconfigured:

> cat .secrets/bishop/*.log | grep -v RQ | unix2dos | grep -E ' 000[5C] ... 0[45]0[48]' | python client.py -rr parse

22:26:56.008 || CTL:076010 | HGI:198151 | RP | zone_devices     | 0408 || {'zone_idx': '04', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': ['04:240790']}
22:26:56.033 || CTL:076010 | HGI:198151 | RP | zone_devices     | 0508 || {'zone_idx': '05', '_device_class': '08', 'device_class': 'rad_actuators', 'devices': []}
22:26:57.353 || CTL:076010 | HGI:198151 | RP | zone_devices     | 0404 || {'zone_idx': '04', '_device_class': '04', 'device_class': 'sensor', 'devices': ['04:240790']}
22:26:57.402 || CTL:076010 | HGI:198151 | RP | zone_devices     | 0504 || {'zone_idx': '05', '_device_class': '04', 'device_class': 'sensor', 'devices': ['04:081013']}

The TRV, 04:081013, needs to be rebound as an actuator (it is correctly bound as a sensor) - I believe the zone is called Bathroom 2nd.

2323

This will be fixed in 0.18.4.

2324

So, 0.18.5 has been released as a pre-release.

If you have UFH, then the 0.18.x releases are for you, but they are not as stable as the latest 0.17.x release.

Note that it removes duplicate OTB sensors from HA, and is a little friendlier with HGI80s.

The UFH zones should have heat demand now.

Please report any bugs.

2325

It’s got a space before the I (I will address this).

service: evohome_cc.send_packet
data:
  device_id: 32:132125
  verb: " I"
  code: 22F3
  payload: 00020F03040000

With the lack of impersonation, the PIV may not elect to accept the packet.

There are plans to expose things like this PIV as FAN entities.

2326

I updated to 0.18.5 from 0.18.3 and got this error 8 times in the last hour

2022-01-31 09:11:50 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/helpers.py", line 17, in execute_func
    return fnc(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/entities.py", line 131, in wrapper
    return fnc(self, discover_flag=discover_flag)
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1128, in _discover
    [self._make_cmd(_000A, payload=ufh_idx) for ufh_idx in self._circuits_alt]
  File "/usr/local/lib/python3.9/site-packages/ramses_rf/devices.py", line 1195, in _circuits_alt
    if msg := self._msgz[_0005][RP]["0009"]:  # also 0000, 0004
KeyError: '0005'