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

sciorty · February 19, 2023, 2:51pm

Hi guys, sorry to show up here as a noob but I’m really stuck.
I have an Arduino with a CC1101 and evofw3, connected via USB to the Raspberry on which I run my home assistant. I also installed the ramses_cc components from HACS

I have a ventilation system which I would like to control/monitor, and a physical remote. My intention is to still be able to use the physical button (VMN-02LM11) but be able to set the speed of the ventilation, possibly also turn off, control bypass and possibly extract all the interesting data that the machine should have available (input/output temperatures/humidities of the fresh/exhaust air)

If i run the screen cmd on the serial port, while pushing some buttons, I get:

061  I --- 32:126818 32:142858 --:------ 22F1 003 000207
082  I 030 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
083  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF069B7FFF07F4067EF000004150500000EFEF7FFF7FFF00

063  I --- 32:126818 32:142858 --:------ 22F1 003 000307
081  I 031 32:142858 --:------ 32:142858 31D9 017 002A030020202020202020202020202008
082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF069C7FFF07F8067DF00000428C8C0000EFEF7FFF7FFF00
081  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF069C7FFF07F8067DF00000428C8C0000EFEF7FFF7FFF00

062  I --- 32:126818 32:142858 --:------ 22F1 003 000707
082  I 032 32:142858 --:------ 32:142858 31D9 017 002A070020202020202020202020202008
082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF069C7FFF07F8067CF0000057C8C80000EFEF7FFF7FFF00

Which are the commands and response to/from the ventilation unit for the three velocities that I send through the physical remote.

How can I replicate this through the home assistant ramses_cc? How can I be able to monitor the responses of the unit so that I have an updated status even if I sent the commands through the physical remote?

For now, I tried with the following configuration that I thought should allow me to create a “remote”, and restarted the core:


ramses_cc:
  serial_port: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_A4132373935351B0F041-if00
  packet_log: ~/packets.log
  known_list:
    32:126818:
      class: REM
      faked: True
      commands:
        low:    ' 32:126818 32:142858 --:------ 22F1 003 000207
        medium: ' 32:126818 32:142858 --:------ 22F1 003 000307'
        high:   ' 32:126818 32:142858 --:------ 22F1 003 000707'

But I don’t neither see any new entity, nor the log!
Any help?

zxdavb · February 19, 2023, 4:06pm

sciorty:

ramses_cc:
  serial_port: /dev/serial/by-id/usb-Arduino__www.arduino.cc__0043_A4132373935351B0F041-if00
  packet_log: ~/packets.log
  known_list:
    32:126818:
      class: REM
      faked: True
      commands:
        low:    ' I --- 32:126818 32:142858 --:------ 22F1 003 000207'
        medium: ' I --- 32:126818 32:142858 --:------ 22F1 003 000307'
        high:   ' I --- 32:126818 32:142858 --:------ 22F1 003 000707'

Note the above changes - try that, for a start.

See: 3. Support for HVAC systems · zxdavb/ramses_cc Wiki (github.com)

Also, have a look at your HA log.

sciorty · February 19, 2023, 4:43pm

Yeah sorry it was a cut/paste error. I originally did how you wrote, still nothing. I mean, should i see a new entity named with something like “32_…” or “remote” after reboot? Beacause i don’t.
Also i do not see anything in the logs where should I look?

sciorty · February 20, 2023, 9:14am

Ok i think i’m getting on tracks.
I had to reboot because apparently another process was using the USB port. Now i also have the logs. I tried the configuration you suggested for HVAC, adapting it to my case:

    32:142858 : { class: FAN, _note: Orcon HRC 400 } 
    32:126818:
      class: REM
      faked: True
      commands:
        low:          ' I --- 32:126818 32:142858 --:------ 22F1 003 000207'
        medium:       ' I --- 32:126818 32:142858 --:------ 22F1 003 000307'
        high:         ' I --- 32:126818 32:142858 --:------ 22F1 003 000707'
        bypass_open:  ' W --- 32:126818 32:142858 --:------ 22F7 003 00C8EF'
        bypass_close: ' W --- 32:126818 32:142858 --:------ 22F7 003 0000EF'
        bypass_auto:  ' W --- 32:126818 32:142858 --:------ 22F7 003 00FFEF'
        reset_filter: ' W --- 32:126818 32:142858 --:------ 10D0 002 00FF'
      _note: based upon an Orcon 15RF 6-button remote (VMN-15LF01)

First of all:
This now creates various sensor entities that start with 32_142858, and that’s ok. But i thought it would also have generatet something with 32:126818, that is the faked remote that i want to copy. But it doesn’t. I just have climate.32_142858 whose commands does not work:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 200, in handle_call_service
    await hass.services.async_call(
  File "/usr/src/homeassistant/homeassistant/core.py", line 1787, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1824, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, in handle_service
    await service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 680, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 968, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 720, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 489, in async_set_fan_mode
    await self.hass.async_add_executor_job(self.set_fan_mode, fan_mode)
  File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 485, in set_fan_mode
    raise NotImplementedError()
NotImplementedError

Second thing:
Now that i see the logs, i see that every 30 seconds a “RQ” is sent but the machine does not reply, unless every 5 or 10 minutes that it spontaneously send this “I” messages:

2023-02-20T09:26:23.298665 # ramses_rf 0.21.40
2023-02-20T09:26:27.388119 ...  I --- 32:142858 --:------ 32:142858 313F 009 007C1B12970B0207D0 # 313F| I|32:142858
2023-02-20T09:26:42.994369 000 RQ --- 18:070400 32:142858 --:------ 22F1 001 00
2023-02-20T09:27:43.001038 000 RQ --- 18:070400 32:142858 --:------ 22E0 001 00
2023-02-20T09:28:13.002893 000 RQ --- 18:070400 32:142858 --:------ 22E5 001 00
2023-02-20T09:28:43.048082 000 RQ --- 18:070400 32:142858 --:------ 22E9 001 00
2023-02-20T09:29:13.026771 000 RQ --- 18:070400 32:142858 --:------ 22F2 001 00
2023-02-20T09:29:43.024651 000 RQ --- 18:070400 32:142858 --:------ 22F4 001 00
2023-02-20T09:30:13.034708 000 RQ --- 18:070400 32:142858 --:------ 22F8 001 00
2023-02-20T09:30:43.024047 000 RQ --- 18:070400 32:142858 --:------ 313E 001 00
2023-02-20T09:31:13.021659 000 RQ --- 18:070400 32:142858 --:------ 3222 001 00
2023-02-20T09:31:46.059183 000 RQ --- 18:070400 32:142858 --:------ 10D0 001 00
2023-02-20T09:32:16.035952 000 RQ --- 18:070400 32:142858 --:------ 22F1 001 00
2023-02-20T09:32:26.792031 080  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF05997FFF079E0541F000004150500000EFEF7FFF7FFF00
2023-02-20T09:32:26.865664 000 RQ --- 18:070400 32:142858 --:------ 2210 001 00
2023-02-20T09:33:26.852352 000 RQ --- 18:070400 32:142858 --:------ 22E5 001 00
2023-02-20T09:33:56.854041 000 RQ --- 18:070400 32:142858 --:------ 22E9 001 00
2023-02-20T09:34:26.852013 000 RQ --- 18:070400 32:142858 --:------ 22F2 001 00
2023-02-20T09:34:56.849726 000 RQ --- 18:070400 32:142858 --:------ 22F4 001 00
2023-02-20T09:35:26.884125 000 RQ --- 18:070400 32:142858 --:------ 22F8 001 00
2023-02-20T09:35:56.873880 000 RQ --- 18:070400 32:142858 --:------ 313E 001 00
2023-02-20T09:36:26.895799 000 RQ --- 18:070400 32:142858 --:------ 3222 001 00
2023-02-20T09:36:59.875425 000 RQ --- 18:070400 32:142858 --:------ 10D0 001 00
2023-02-20T09:37:26.973206 080  I 107 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-02-20T09:37:27.055202 000 RQ --- 18:070400 32:142858 --:------ 22F1 001 00
2023-02-20T09:37:57.044487 000 RQ --- 18:070400 32:142858 --:------ 2210 001 00
2023-02-20T09:38:27.058501 000 RQ --- 18:070400 32:142858 --:------ 22E0 001 00
2023-02-20T09:38:57.048654 000 RQ --- 18:000370 32:142858 --:------ 22E5 001 00
2023-02-20T09:39:27.050005 000 RQ --- 18:070400 32:142858 --:------ 22E9 001 00
2023-02-20T09:39:57.055714 000 RQ --- 18:070400 32:142858 --:------ 22F2 001 00
2023-02-20T09:40:27.049268 000 RQ --- 18:070400 32:142858 --:------ 22F4 001 00
2023-02-20T09:40:57.080390 000 RQ --- 18:070400 32:142858 --:------ 22F8 001 00
2023-02-20T09:41:27.060903 000 RQ --- 18:070400 32:142858 --:------ 313E 001 00
2023-02-20T09:41:57.058449 000 RQ --- 18:070400 32:142858 --:------ 3222 001 00
2023-02-20T09:42:27.191530 082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF058F7FFF079E0533F000004150500000EFEF7FFF7FFF00
2023-02-20T09:42:30.078599 000 RQ --- 18:070400 32:142858 --:------ 10D0 001 00
2023-02-20T09:43:00.047424 000 RQ --- 18:070400 32:142858 --:------ 22F1 001 00
2023-02-20T09:43:30.098902 000 RQ --- 18:070400 32:142885 --:------ 2210 001 00
2023-02-20T09:44:00.075474 000 RQ --- 18:070400 32:142858 --:------ 22E0 001 00
2023-02-20T09:44:30.077379 000 RQ --- 18:070400 32:142858 --:------ 22E5 001 00
2023-02-20T09:45:00.066630 000 RQ --- 18:070400 32:142858 --:------ 22E9 001 00
2023-02-20T09:45:30.089175 000 RQ --- 18:070400 03:142858 --:------ 22F2 001 00
2023-02-20T09:46:00.115151 000 RQ --- 18:070400 32:142858 --:------ 22F4 001 00
2023-02-20T09:46:30.088012 000 RQ --- 18:070400 32:142858 --:------ 22F8 001 00
2023-02-20T09:47:00.123303 000 RQ --- 18:070400 32:142858 --:------ 313E 001 00
2023-02-20T09:47:30.124352 000 RQ --- 18:070400 32:142858 --:------ 3222 001 00
2023-02-20T09:48:03.087169 000 RQ --- 18:070400 32:142858 --:------ 10D0 001 00
2023-02-20T09:48:33.097270 000 RQ --- 18:070400 32:142858 --:------ 22F1 001 00
2023-02-20T09:49:03.099546 000 RQ --- 18:070400 32:142858 --:------ 2210 001 00
2023-02-20T09:49:33.137678 000 RQ --- 18:070400 32:142858 --:------ 22E0 001 00
2023-02-20T09:50:03.098851 000 RQ --- 18:070400 03:045706 --:------ 22E5 001 00
2023-02-20T09:50:33.100480 000 RQ --- 18:070400 32:142858 --:------ 22E9 001 00
2023-02-20T09:51:03.143055 000 RQ --- 18:070400 32:142858 --:------ 22F2 001 00
2023-02-20T09:51:33.119944 000 RQ --- 18:070400 32:142858 --:------ 22F4 001 00
2023-02-20T09:52:03.121594 000 RQ --- 18:070400 32:142858 --:------ 22F8 001 00
2023-02-20T09:52:27.590125 082  I 108 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-02-20T09:52:27.692558 080  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF05917FFF079A0535F000004150500000EFEF7FFF7FFF00

The questions are:
-Where is the address 18:070400 originated from? Should i bind this address to the machine in some way to let it reply?
-When this “I” messages are received, that’s when the sensors mentioned before are upodated. But how do i know that these values are correct? I just know that the machine has this PCB and i just have this remote.
I thought mine was an Orcon remote, as the example in the wiki, but for example this command:

disable: ' I --- 29:123456 32:123456 --:------ 22F1 003 000707'

To me is instead the maximum fan speed (or at least the maximum available for my remote. So How do i know that the bypass command would work? I don’t have any certainty neither on the command nor on the response “deparsing”

Sorry for the shitload of question but it’s one year since i wanted to interface qith the ventilation machine and it’s finally happening

Edit:
I added

  advanced_features:
    send_packet: true

And i now see the remote and have the possibility to call this service:

service: remote.send_command
data:
  command: medium
target:
  entity_id: remote.32_126818

The commands generates the correct string in the logs, i can see it, but the machine does not reply:

2023-02-20T16:31:40.997945 000  I --- 32:126818 32:142858 --:------ 22F1 003 000307
2023-02-20T16:31:41.231152 000 RQ --- 18:070400 32:142858 --:------ 22F8 001 00
2023-02-20T16:32:10.442831 000 RQ --- 18:070400 32:142858 --:------ 313E 001 00
2023-02-20T16:32:40.411689 000 RQ --- 18:070400 32:142858 --:------ 3222 001 00
2023-02-20T16:32:43.854149 079  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06087FFF07B605D5F000004150500000EFEF7FFF7FFF00
2023-02-20T16:32:46.932729 000 RQ --- 18:070400 32:142858 --:------ 10D0 001 00
2023-02-20T16:33:16.926040 000 RQ --- 18:070400 32:142858 --:------ 22F1 001 00
2023-02-20T16:33:46.911184 000 RQ --- 18:070400 32:142858 --:------ 2210 001 00
2023-02-20T16:34:16.908580 000 RQ --- 18:070400 32:142858 --:------ 22E0 001 00
2023-02-20T16:34:46.922969 000 RQ --- 18:070400 32:142858 --:------ 22E5 001 00
2023-02-20T16:35:16.944959 000 RQ --- 18:070400 32:142858 --:------ 22E9 001 00

As you can see it spontaneously sends the 31DA oacket after a minute but with no changes

guyank · February 23, 2023, 8:52pm

I’m seeing some strange behaviours within my automations whilst running 0.21.40 When I set an action to call the ‘Set the Mode of a TCS’ service, both the ‘Days’ and ‘Eco/boost duration’ options are ticked. I want to set them without a duration, so untick both. When I save the automation and go back in, both options are ticked again. Editing in YAML has the same effect. When the automations run, its creating an error in the logs, depending on which option is not applicable to the chosen mode. This is the only service I’m having the problem with. Is anyone else seeing this?

cvenn · February 23, 2023, 11:49pm

My HGI is a Honeywell HGI80, which is about 3m away from the UFC (HCC80r), so reception shouldn’t really be an issue.

cvenn · February 24, 2023, 12:02am

I can try power cycling the HCC80.

cvenn · February 24, 2023, 4:29pm

That didn’t make any difference.

zxdavb · February 26, 2023, 1:00am

I dunno - I’d like to see what happens with an evofw3…

cvenn · February 26, 2023, 12:21pm

I’ll let you know, I just ordered one.

scriven33 · February 28, 2023, 2:20pm

I have recently acquired a indalo-tech stick and setup this integration.
This has of course shown that our EvoHome setup isn’t correct, which explains some of the odd behaviour we have seen. Therefore I am trying to fix it, before moving forwards.

We have zones like this:

0B:
    _name: Hall
    class: radiator_valve
    sensor: null
    actuators: []

and then zones like this:

 '06':
    _name: Bedroom 1
    class: radiator_valve
    sensor: null
    actuators:
      - '04:191575'
      - '04:191597'

So showing multiple actuators (when there should be one), no sensors etc. It is a real mess.
Therefore I trying to workout exactly what I need to do to clean up the mess.

Questions.

Do I need to delete both types of zones and recreate, or can I just delete the ones with nothing and rebind the TRV, so it moves to the correct zone?
What do I need to do on HA? Just delete the “ramses_cc” file in .storage and reboot? Something else or in addition to that?

Thanks.

cvenn · February 28, 2023, 5:57pm

Doesn’t look any different to me. The UFC still isn’t responding to the (new evofw3) HGI (or anything else for that matter). The UFC is only sending Information packets, to CTL or itself.

zxdavb · February 28, 2023, 11:45pm

Your scenario is not uncommon, but be careful, there are two reasons why you’ll see things like:

They are:

your system is misconfigured, and the schema that you are seeing is a true representation of your system
ramses_rf asked for this data, and didn’t get a reply, or received an invalid reply

Before you rush to reconfigure your system, I’d be looking to confirm that you’re really seeing 1), and not 2.

The best way to do this is to review the packet logs and looks for the lines containing 000C.

If you post those here, I (or others can comment further).

Answers:

Strictly, it depends. For example, if a missing TRV is (instead) in the wrong zone, you cannot remove it from that zone: you have to delete that zone & re-create it. In other scanarios, all you have to do is re-bind.

The best thing to do is to post all your 000C packets (and your configuration.yaml.

Officially, you need to restart HA with the packet cache disabled:

ramses_cc:
  ramses_rf:
    restore_cache: false

… and then re-enable it.

Or you can just delete the ramses_cc file, like you say.

scriven33 · March 1, 2023, 11:14am

Hello,
The configuration.yaml entry is very light, as I have only just started with the process. This is it:

serial_port: rfc2217://192.168.1.125:5001
  
packet_log:
  file_name: packet.log
  rotate_backups: 28

I am using the ser2net method, which I am aware of the limitations of, but I have no choice as the HA installation lives in a VM.
I haven’t gone down the path of allow lists etc because it is only detecting our EvoHome kit. When I checked the list of actuators, the number found match how many we have.
Furthermore not all zones are wrong - five of the twelve zones we have are correct.

This is the 000C lines from the log file:

2023-3-01T10:46:58.177343 ... RP --- 01:121726 18:201244 --:------ 000C 6 000F00340E25 # 000C|RP|01:121726|000F (000F)
2023 3 01T10:46:58.178936 ... RP --- 01:121726 18:201244 --:------ 000C 6 000E0034389B # 000C|RP|01:121726|000E (000E)
2023 3 01T10:46:58.183552 ... RP --- 01:121726 18:201244 --:------ 000C 6 010E7FFFFFFF # 000C|RP|01:121726|010E (010E)
2023 3 01T10:46:58.184429 ... RP --- 01:121726 18:201244 --:------ 000C 6 000D001C85F4 # 000C|RP|01:121726|000D (000D)
2023 3 01T10:46:59.540603 ... RP --- 01:121726 18:201244 --:------ 000C 6 00080012E0B3 # 000C|RP|01:121726|0008 -8
2023 3 01T10:46:59.549155 ... RP --- 01:121726 18:201244 --:------ 000C 6 0004005AF744 # 000C|RP|01:121726|0004 -4
2023 3 01T10:46:59.554785 ... RP --- 01:121726 18:201244 --:------ 000C 6 01080013480F # 000C|RP|01:121726|0108 -108
2023 3 01T10:46:59.560860 ... RP --- 01:121726 18:201244 --:------ 000C 18 02080012EB8D02080012E0B502080012EB8F # 000C|RP|01:121726|0208 -208
2023 3 01T10:46:59.570511 ... RP --- 01:121726 18:201244 --:------ 000C 6 01040013480F # 000C|RP|01:121726|0104 -104
2023 3 01T10:46:59.576503 ... RP --- 01:121726 18:201244 --:------ 000C 6 0204005AF743 # 000C|RP|01:121726|0204 -204
2023 3 01T10:46:59.579870 ... RP --- 01:121726 18:201244 --:------ 000C 6 03080012E0AF # 000C|RP|01:121726|0308 -308
2023 3 01T10:46:59.584648 ... RP --- 01:121726 18:201244 --:------ 000C 18 04080011519804080012EC6304080012E0B1 # 000C|RP|01:121726|0408 -408
2023 3 01T10:46:59.600321 ... RP --- 01:121726 18:201244 --:------ 000C 6 03040012E0AF # 000C|RP|01:121726|0304 -304
2023 3 01T10:46:59.603858 ... RP --- 01:121726 18:201244 --:------ 000C 6 04040012EC63 # 000C|RP|01:121726|0404 -404
2023 3 01T10:46:59.609340 ... RP --- 01:121726 18:201244 --:------ 000C 18 0508001151A20508001151A005080012EB91 # 000C|RP|01:121726|0508 -508
2023 3 01T10:46:59.619105 ... RP --- 01:121726 18:201244 --:------ 000C 18 06080012EC5706080012EC6D060800115198 # 000C|RP|01:121726|0608 -608
2023 3 01T10:46:59.631269 ... RP --- 01:121726 18:201244 --:------ 000C 6 0504001151A2 # 000C|RP|01:121726|0504 -504
2023 3 01T10:46:59.639389 ... RP --- 01:121726 18:201244 --:------ 000C 6 60400115198 # 000C|RP|01:121726|0604 -604
2023 3 01T10:46:59.643086 ... RP --- 01:121726 18:201244 --:------ 000C 6 070800131BB4 # 000C|RP|01:121726|0708 -708
2023 3 01T10:46:59.646576 ... RP --- 01:121726 18:201244 --:------ 000C 6 08080012EC57 # 000C|RP|01:121726|0808 -808
2023 3 01T10:46:59.657298 ... RP --- 01:121726 18:201244 --:------ 000C 6 070400131BB4 # 000C|RP|01:121726|0704 -704
2023 3 01T10:46:59.661115 ... RP --- 01:121726 18:201244 --:------ 000C 6 08040012EC57 # 000C|RP|01:121726|0804 -804
2023 3 01T10:46:59.672559 ... RP --- 01:121726 18:201244 --:------ 000C 6 09087FFFFFFF # 000C|RP|01:121726|0908 -908
2023 3 01T10:46:59.678166 ... RP --- 01:121726 18:201244 --:------ 000C 12 0A0800130F330A080012EB95 # 000C|RP|01:121726|0A08 (0A08)
2023 3 01T10:46:59.684379 ... RP --- 01:121726 18:201244 --:------ 000C 6 09047FFFFFFF # 000C|RP|01:121726|0904 -904
2023 3 01T10:46:59.707261 ... RP --- 01:121726 18:201244 --:------ 000C 6 0A040012EB95 # 000C|RP|01:121726|0A04 (0A04)
2023 3 01T10:47:00.068847 ... RP --- 01:121726 18:201244 --:------ 000C 6 0B087FFFFFFF # 000C|RP|01:121726|0B08 (0B08)
2023 3 01T10:47:00.083627 ... RP --- 01:121726 18:201244 --:------ 000C 6 0B040012E0B1 # 000C|RP|01:121726|0B04 (0B04)

Thank you for your assistance.

scriven33 · March 1, 2023, 12:37pm

I have just built a fresh install of HA on a spare RPi, and connected the stick directly to it.
The schema that is shown is identical to the one that I have on my live system which was using the ser2net connection.

scriven33 · March 1, 2023, 3:36pm

Replying to myself again, deleting the bad zones and recreating it has sorted the mess out. What I wasn’t sure about was deleting both the zones with the missing TRV and the ones with the additional TRVs. Took a little while to put it all back, but the schema now matches the real world.

zxdavb · March 1, 2023, 10:34pm

Yes - ser2net is useful if you need it, but is a best-efforts solution.

It can drop packets, and exhibit the behaviour you describe, although as we see in your case, your system was truly misconfigured.

( There have occasionally been thoughts / rumours of adding MQTT into the mix. )

Well done.

Your HA log would have had these entries:

CorruptStateError(Inconsistent schema: 04:086424 (TRV): None cant change parent (01:121726_04 (RAD)_04 to 01:121726_06 (None)_06)(try restarting the client library))

It is saying that the evohome controller thinks that 04:086424 (a TRV) is in both zones 4 and 6 (oddly, the TRV won’t be confused about what zone it is in).

In such cases you usually have to delete/re-create at least one of the zones (and maybe even both), as there is no way to remove a actuator from a zone in the evohome UI.

You won’t be the last person who turns on ramses_rf and discovers the system is misconfigured.

zxdavb · March 1, 2023, 10:37pm

You can try to autotune evofw3.

You can also ensure the USB dongle is close to the HCC80.

Other than that, I dunno what to say - can you pull a 10E0 packet form teh logs for the HCC80 - grep for:

" 02:.* 10E0 "

cvenn · March 2, 2023, 10:05am

Did that last night and restarted HA - no change. UFC still not responding to anything.

It is 3.5m from HCC, with one plasterboard stud wall and a thin wooden door between them.
I could try temporarily moving it closer?

There are no 10E0 packets in the log.

Maybe my HCC80 is faulty? It appears to be deaf.

zxdavb · March 2, 2023, 11:26am

No - it should work reliably with the scenario you describe.

The reality is - I can’t really say - I have never had a HCC80 (UFC) to play with - they’re too expensive - all I see is people’s packet logs.

I do know the HCC80 has a lot of configuration options…

Though I can see it transmit, it isn’t a HCE80 without an antenna?

We have these in your packet log:

 I --- 02:028423 --:------ 01:085545 3150 002 0032

… so the UFC was bound to the CTL at some stage: i.e. it can’t be ‘deaf’.

I just don’t know - every other HCC80 I’ve seen responds to RQ|000C, and they all send 10E0 packets spontaneously.

Here is a example of one:

 I --- 02:001786 --:------ 02:001786 10E0 036 000003FF0203FFFF0001FFFFFFFF060B07E148434538302056332E313020303631313137