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

Share your Projects!
3255

Difference in HGI80 and Nanocul

In preperation for some testing I have a Intel NUC running my main version of HA. I also have a VM running on another machine. Both are running the latest version of HAOS.

I am lucky enough to have a HGI80 and is normally on the NUC. I also have a Nanocul that is flashed per the instructions on the git page. running version version 0.7.1 evofw3.

When I have the HGI on the NUC it finds everything and brings back a correct schema. Room names, multiple devices in the rooms etc. When I plug the Nanocul into the VM it finds devices and gets settings but doesnt get a schema. Tried removing the ramses_cc including the file in the .config folder. In the configuration.yaml i just have the port entry (For now). Did this 3 or 4 times with no schema found. Cleared out again and attached the HGI80 to the VM and it found the schema straight away with all the details that had been in the NUC.

Is this by design / a limitiation on the Nanocul or is there a different firmware version that should be used?

3256

The nanoCUL, which runs evofw3, offers more features - such as impersonation/faking (using another deviceā€™s source address).

The HGI80 (whihc cannot impersonate) has been ā€˜tunedā€™ in the factory (should offer the best reception). However, the evofw3 FW has a auto tune command, that you should use, and may solve some of teh problems you describe.

EVOFW3 Autotune Ā· ghoti57/evofw3 Wiki (github.com)

3257

You really need to see the packet log for both scenarios.

3258

@zxdavb I am stilling looking for the event that changes the states to unknown. I found this below but it does not point to the cause. 11 out of 12 zones were unknown this morning.
@maesenator did you have any luck figuring it out?

2022-12-23 06:14:23.978 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=climate.ensuite, old_state=<state climate.ensuite=off; hvac_modes=[<HVACMode.AUTO: 'auto'>, <HVACMode.HEAT: 'heat'>], min_temp=5.0, max_temp=35.0, target_temp_step=0.1, preset_modes=['none', 'temporary', 'permanent'], current_temperature=18.1, temperature=5.0, hvac_action=idle, preset_mode=none, zone_idx=0B, heating_type=radiator_valve, mode=mode=follow_schedule, setpoint=5.0, config=min_temp=5.0, max_temp=35.0, local_override=False, openwindow_function=False, multiroom_mode=False, schema=_name=Ensuite, class=radiator_valve, sensor=04:116501, actuators=['04:116501'], params=config=min_temp=5.0, max_temp=35.0, local_override=False, openwindow_function=False, multiroom_mode=False, mode=mode=follow_schedule, setpoint=5.0, name=Ensuite, schedule=None, schedule_version=None, icon=mdi:radiator, friendly_name=Ensuite, supported_features=ClimateEntityFeature.PRESET_MODE|TARGET_TEMPERATURE @ 2022-12-23T05:46:23.844603+00:00>, new_state=<state climate.ensuite=unknown; hvac_modes=[<HVACMode.AUTO: 'auto'>, <HVACMode.HEAT: 'heat'>], min_temp=5.0, max_temp=35.0, target_temp_step=0.1, preset_modes=['none', 'temporary', 'permanent'], current_temperature=18.1, temperature=5.0, preset_mode=None, zone_idx=0B, heating_type=radiator_valve, mode=mode=follow_schedule, setpoint=5.0, config=min_temp=5.0, max_temp=35.0, local_override=False, openwindow_function=False, multiroom_mode=False, schema=_name=Ensuite, class=radiator_valve, sensor=04:116501, actuators=['04:116501'], params=config=min_temp=5.0, max_temp=35.0, local_override=False, openwindow_function=False, multiroom_mode=False, mode=mode=follow_schedule, setpoint=5.0, name=Ensuite, schedule=None, schedule_version=None, icon=mdi:radiator, friendly_name=Ensuite, supported_features=ClimateEntityFeature.PRESET_MODE|TARGET_TEMPERATURE @ 2022-12-23T06:14:23.977909+00:00>>
3259

Hi,

Unfortunately I did not. I did remove my fake sensor last week and rebuilt the schema. It was stable for a whole week so I thought it was resolved.
Just checked and itā€™s back to Unknown.
image

Thereā€™s a whole lot of stuff in the logs but none of it seems to be of any help.

Logger: ramses_rf.entity_base
Source: runner.py:120
First occurred: December 22, 2022 at 20:20:06 (194 occurrences)
Last logged: 08:35:21

No response for task(3220|RP|10:030051|78): throttling to 1/6h
No response for task(3220|RP|10:030051|79): throttling to 1/6h
No response for task(3220|RP|10:030051|7A): throttling to 1/6h
No response for task(3220|RP|10:030051|7B): throttling to 1/6h
No response for task(3220|RP|10:030051|19): throttling to 1/6h

Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:97
First occurred: December 22, 2022 at 23:34:26 (3 occurrences)
Last logged: 08:26:04

Error doing job: Exception in callback SerialTransport._read_ready()
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.10/site-packages/serial_asyncio/__init__.py", line 120, in _read_ready
    self._protocol.data_received(data)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 609, in data_received
    self._line_received(dtm, _normalise(_str(raw_line)), raw_line)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 635, in _line_received
    self._pkt_received(pkt)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 851, in _pkt_received
    if pkt._hdr == self._qos_cmd.tx_header:
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/frame.py", line 405, in _hdr
    self._hdr_ = pkt_header(self)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/frame.py", line 559, in pkt_header
    return f"{header}|{pkt._ctx}" if isinstance(pkt._ctx, str) else header
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/frame.py", line 393, in _ctx
    self._ctx_ = self._idx
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/frame.py", line 416, in _idx
    self._idx_ = _pkt_idx(self) or False
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/frame.py", line 503, in _pkt_idx
    raise InvalidPayloadError(
ramses_rf.protocol.exceptions.InvalidPayloadError: Corrupt payload: Packet idx is 04, but expecting no idx (00) (0xAB)

Logger: ramses_rf.protocol.message
Source: runner.py:120
First occurred: December 22, 2022 at 20:21:12 (5 occurrences)
Last logged: 03:51:07

RQ --- 18:205572 10:030051 --:------ 3220 005 0008750000 < Corrupt payload: OpenTherm: Invalid spare bits: 0b1000
RQ --- 18:205572 01:205114 --:------ 12B0 001 60 < Corrupt payload: Payload doesn't match '^0[0-9A-F](00)?$': 60
RQ --- 18:205572 01:205114 --:------ 2349 002 6000 < Corrupt payload: Payload doesn't match '^0[0-9A-F](00|[0-9A-F]{12})?$': 6000
RP --- 01:205114 18:205572 --:------ 2349 007 607FFF02FFFFFF < Corrupt payload: Payload doesn't match '^0[0-9A-F]{5}0[0-4][0-9A-F]{6}([0-9A-F]{12})?$': 607FFF02FFFFFF
RQ --- 18:205572 01:205114 --:------ 120B 001 04 < Corrupt packet: Unknown code: 120B
3260

My instinct is: it is nothing to do with the (presumably faked) sensor.

Very few people report this issue, so we can work on the basis that it is unique to your systemsā€¦

AM I right in thinking that is goes back from unknown by itself? Is it only the climate entities that are unknown?

Please both provide a 24h packet log.

The above is expected behaviour for some systems - you can ignore this.

The below are simply corrupted packets - the fact that the RQ is corrupt suggests a hardware problem:

Have you both used the autotune?

I wonder if the whole issue is caused by the packet expiry featureā€¦

3261

@zxdavb I think you are right as I donā€™t have fake sensors.

Yes and no. If it is following the schedule then it will be stuck on unknown and if I give a temp override all at the controller then it changes state. I tested this on the zones I emailed to you.
The Setpoint also did not respond to the scheduled changed but it did for the temporary override.

The other associated entities go unavailable instead of unknown.

Yes, I am using a arduino micro and cc1101 while I await Petes own board as its stuck in the UK post strikes :frowning:

where is this buried and can I adjust it to test?

3262

A long shot: After a HASS OS update (I think it was to 9.4) I also had this issue. It turned out that I had 2 devices (a zwave stick) and Ramses competing for the same USB port

3263

I ran autotune on the nanocul and now all seems to be working correctly. Thanks for the pointer.

3264

I have my Ramses and zwave stick on a powered USB hub. Iā€™ll try switching and see. No harm in trying :blush:

3265

I updated today to HA 2023.01, but since the update ramses_cc doesnt work anymore.

Logger: homeassistant.setup
Source: setup.py:340 
First occurred: 08:43:49 (4 occurrences) 
Last logged: 08:44:23

Unable to prepare setup for platform ramses_cc.sensor: Platform not found (cannot import name 'TEMP_CELSIUS' from 'homeassistant.components.sensor' (/usr/src/homeassistant/homeassistant/components/sensor/__init__.py)).
Unable to prepare setup for platform ramses_cc.climate: Platform not found (cannot import name 'TEMP_CELSIUS' from 'homeassistant.components.climate' (/usr/src/homeassistant/homeassistant/components/climate/__init__.py)).
1 Like
3266

OK, this has my attention - will address it ASAP (but I am not in Europe, so bear with me).

It will be a straight-forward fix.

1 Like
3267

Yes, those constants have been deprecated since 2022.11, youā€™re supposed to use the new UnitOfTemperature enumerator: Introducing new unit enumerators | Home Assistant Developer Docs.

3268

Thatā€™s the easy bit - the difficult bit is creating a new dev environment, here in Australia.

3 Likes
3269

My integration stopped working all of sudden (No change in the config), rebooting HA produce
Invalid config - The following integrations and platforms could not be set up:
ramses_cc.sensor
ramses_cc.climate

Strangly, some items works, such as Stored HW, I can change mode and that is updated in Evo Controller, but other including all zones are unavailable. Any pointers greatly appricated.

image

image
image713Ɨ267 13.6 KB

3270

Sorry to put a mix into the ongoing threads around this post! But Iā€™m having some trouble setting up my ramses_cc configuration.

For a breif configuration of our heating system. I have a simple ancient wireless Thermostat (CM67NG) which communicates with a HC60NG to turn on and off our home radiators.
I have confirmed by checking through my packet.log and the auto configuration on the plugin that my devices are:

  • 12:215819 - My Honeywell CM67NG Thermostat
  • 13:081775 - The Honeywell HC60NG Relay box
  • 18:204314 - Not totally sure what this one is but it seems important! Appears to be the ā€˜controllerā€™?

The Thermostat has had no temperature sent to HA since setup, itā€™s always ā€˜unavailableā€™.
The relay does appear to be sending active / relay_demand data to HA.

Iā€™m trying to figure out how to control the temperature - or at the very least, turn on the heating. Iā€™ve looked at trying to use the ā€˜send packetsā€™ service, as I am about 40% sure this packet data sends a ā€˜turn onā€™ signal

 075  I 122 --:------ --:------ 12:215819 0008 002 00C8

but I it doesnā€™t appear to work.

Iā€™m not entirely sure if Iā€™m going about this in the correct way! Is there a step Iā€™m missing? What Iā€™ve
mentioned is the entire story, I havenā€™t ventured into much customisation, therefore I havenā€™t really touched my configuration.yaml in terms of actual device control. Any help would be appreciated! Iā€™ve taken a look through the docs on evofw3, ramses_rf and ramses_cc but Iā€™m not really sure if the wiki articles can be applied to my device configuration.

3271

What version are you using, as the send packet service does not work in the latest. It does work in 0.22.1

3272

Iā€™m using 0.22.3
I can give a downgrade a go, but the messaging appears to be:

000  I --- 18:204314 12:215819 --:------ 0008 002 00C8

Looks like a completely different me. Would you say this service data looks correct from the original packet data?

 075  I 122 --:------ --:------ 12:215819 0008 002 00C8

device_id: "12:215819"
verb: I
code: "0008"
payload: 00C8
3273

Hi,

I noticed you got the Orcon MVS-15R working with the Nano CUL 868 - smart-home-komponente ?

Still any issues? Is it still working great?

Do you have any summary of what you have done to get it working? I am not sure if my head is overloaded of all the information about this topic on several wikis, but maybe you can point me out to what you have done exactly to get everything running. cause my head is a little bit spinning of going through this forum topic and several websitesā€¦

Best would be pointing out to some video tutorial on this. But I recon I have to do with some written instructionsā€¦ :smiley:

kind regards

3274

You sure you didnā€™t upgrade your Home Assistant to 2023.1? Because that error looks very familiarā€¦
That version doesnā€™t work yet, see the posts above yours.