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

Here you go sir:

evohome_cc:
  scan_interval: 60
  serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
  packet_log: /config/custom_components/evohome_cc/packet.log
  advanced_override: true
  restore_state: false
  schema:
    controller: 01:205114
  allow_list:
    - 01:205114
    - 03:256031
    - 04:014696
    - 04:014708
    - 04:014710
    - 04:014712
    - 04:079671
    - 04:120442
    - 04:122639
    - 04:164041
    - 04:164227
    - 04:164247
    - 34:018143
    - 00:025031
    - 32:056031
    - 00:110303
    - 10:030051
    - 03:256007
    - 03:256027
    - 30:256031
    - 00:256031
    - 17:000730
    - 01:125665
    - 30:256007
    - 03:056031
    - 00:110279

You need to add faking here, something like:

  schema:
    controller: 01:205114
    zones:
      "07": {"sensor": {"device_id": "03:256031", "is_faked": true}}
  allow_list:
...

Make sure you use the right zone idx.

Hi David,

Oh… :frowning: I didn’t have to do that before. Do I only need to add the faked sensors like this? How do I know which ID’s I need to add? I have absolutely no idea which ID in my allow_list does what. In fact, maybe some devices from my neighbor are in there, I wouldn’t know (I can tell you I only have 8 HR92’s :smiley:).

Construct a fresh schema by restore_state: false - one place to see it is in .storage/evohome_cc, then minimalize that & use it in configuration.yaml - just add the fake hints to it.

Perhaps someone could start a wiki entry how to do this & I’ll help to give it some polish.

Thanks for that explanation, but still the question remains how do I know which of those ID’s are the fake sensors? Or which of those ID’s belong to me in the first place?

I’ve got 3 faked sensors, those are probably the orphans in this storage file?

                "orphans": [
                    "10:030051",
                    "04:014710",
                    "04:164247"
                ]

Fake sensors are starting with 03:

Thank you! Found them :smiley:

You don’t need to find them: they will be in your schema, which is constructed via Discovery.

All you have to know is which zones are faked.

Nevermind, it fixed itself!
image

OLD POST:

@zxdavb I do need to “find” them. I have to add them to my yaml file manually and to do so I need to know which ID’s belong to the fake sensors :stuck_out_tongue:

This is my configuration.yaml now:

evohome_cc:
  scan_interval: 60
  serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
  packet_log: /config/custom_components/evohome_cc/packet.log
  advanced_override: true
  restore_state: false
  schema:
    controller: 01:205114
    zones:
      "04": {"sensor": {"device_id": "03:256031", "is_faked": true}}
      "05": {"sensor": {"device_id": "03:256007", "is_faked": true}}
      "06": {"sensor": {"device_id": "03:256027", "is_faked": true}}
  allow_list:
    - 01:205114
    - 03:256031
    - 04:014696
    - 04:014708
    - 04:014710
    - 04:014712
    - 04:079671
    - 04:120442
    - 04:122639
    - 04:164041
    - 04:164227
    - 04:164247
    - 34:018143
    - 00:025031
    - 32:056031
    - 00:110303
    - 10:030051
    - 03:256007
    - 03:256027
    - 30:256031
    - 00:256031
    - 17:000730
    - 01:125665
    - 30:256007
    - 03:056031
    - 00:110279

And this is the outcome. I have states current temperatures on all my zones except the faked ones :confused:
image

To be clear. They don’t need to be found: ramses_rf will do that via discovery ( it can’t do so via eavesdropping) - all you need to do get the schema into your configuration.yaml file and say which are faked.

This example may be insightful: the schema will tell you which device is the sensor for each zone - you can take the batteries out of any real thermostat so that it no longer sends temperatures, and then nominate it as a faked sensor!

I should warn you that this piece of code is a little unsatisfactory and is very likely to be changed sometime in the future.

I wil try to do that in one of the coming days :slight_smile:

Actually, looking at the code, it would be preferable to do something like one of these:

  schema:
    controller: 01:205114
    zones:
      "04": {"enable_faking": true}
      "05": {"sensor": {"is_faked": true}}

That is, no device_id required.

1 Like

Release 0.10.6 - main change is save_state() feature (i.e. the .storage/evohome_cc file used by restore_state: true) now includes all relevant packets.

I would like someone with an OTB to send me their evohome_cc file after starting HA without restoring a state,

That is, one of:
a) delete your .evohome_cc & restart HA
b) set restore_state: false & restart (remember to set it back to true)

Or you could - if you wanted to keep you old state:
c) move your evohome_cc somewhere (i.e. do a)), and later stop HA & restore your saved file before restarting

In all cases, please wait 10 mins or so before collecting the fresh evohome_cc for me.

@llevering Your schema is particularly interesting, so I’d be keen to see yours.

Also, anyone with an OTB could also try this:

python client.py execute /dev/ttyUSB0 -sx 10:000000  -o scan_otb.log

where 10:000000 is your OTB’s device ID.

You can press control-C when you see: 'msg_id': '0x7D', and send me a copy of the log file.

1 Like

I just give a restart to HA. I will send you my evohome_cc file.
Do you also need the config?

Yeah, is always helpful.

I’ve updated and waited 10 minutes. But unfortunately 1 of my zones (Hoofd Slaapkamer) no longer has an HR92 associated with them, only a sensor. It’s a fake sensor. This is apparent firstly because this zone is not displaying Idle but instead is always heating, I can also see in my history graph that the heating is always on. What is particularly interesting is that if I change the temperature of the broken zone, I can actually hear the HR92 spring into immediate action. So it does work in some way or another.

I have identified this zone in my evohome_cc file and it indeed does not have an HR92 there. Note that the 03:xxx is a fake sensor.
Hoofd slaapkamer:

                        "04": {
                            "heating_type": "radiator_valve",
                            "sensor": {
                                "device_id": "03:256031",
                                "is_faked": true
                            },
                            "devices": [
                                "03:256031"
                            ]
                        },

In the bottom of the file I see orphans and I see a 04:xxx there, which I believe to be the “missing” HR92 (no idea what the 10:xxxx is). Any ideas how I can fix this? I don’t have any errors in the log.

                "orphans": [
                    "10:030051",
                    "04:014710"
                ]

Weirdly enough there appears to be another zone with this issue (Badkamer Boven) as it is not displaying Idle but it’s not showing heating in the history graph either. So I guess this one is out of the ordinary but less annoying.


Badkamer boven. Here we can see that we DO have an an HR92 associated (04:xxx) and the external temperature sensor (34:xxxx)

                        "02": {
                            "heating_type": "radiator_valve",
                            "sensor": "34:018143",
                            "devices": [
                                "04:014712",
                                "34:018143"
                            ]
                        },

This is my configuration.yaml file:

evohome_cc:
  scan_interval: 60
  serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
  packet_log: /config/custom_components/evohome_cc/packet.log
  advanced_override: true
  restore_state: false
  schema:
    controller: 01:205114
    zones:
      "04": {"sensor": {"device_id": "03:256031", "is_faked": true}}
      "05": {"sensor": {"device_id": "03:256007", "is_faked": true}}
      "06": {"sensor": {"device_id": "03:256027", "is_faked": true}}

@maesenator What does your packet log say?

If you just restart - the issue may resolve itself: indicating lost packets.

Thanks for the update, I am going to message you all the files requested. But I already see a huge improvement as all HCE80 unit (underfloor heating controllers) are found.

I see now two opentherm bridges, so I have to find out which one is mine and send you logs. Maybe that explains the weird results you saw earlier.

FYI - scanning an OTB doesn’t change it’s configuration/behaviour - so accidentally scanning your neighbour’s OTB wont be a problem.