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

evohome_cc without Evohome controller…

I have a bit of an atypical setup compared to other evohome_cc users. I simply have two DT92E thermostats each paired with a BDR91A1000 relay box.

When running evohome_cc, I get this schema:

'main_controller': None,
'orphans': [ '22:182330',
             '13:136987',
             '13:043686',
             '22:069734',
             '13:033689',
             '13:260368',
             '30:253184',
             '12:175517',
             '12:238482']

Can evohome_cc be used in this configuration, or does it depend on having an actual evohome controller?

I believe that one of my thermostats is 22:182330 and the other is 22:069734. Ideally I would like to be able to see the current temperature as well as change the set points from Homeassistant.

You need to enable logging too: Create new page · zxdavb/ramses_cc Wiki · GitHub

Thx, this is my schema:
Schema = {‘controller’: ‘01:155341’, ‘system’: {‘heating_control’: ‘13:189740’}, ‘orphans’: [‘17:000730’], ‘stored_hotwater’: {}, ‘underfloor_heating’: {}, ‘zones’: {‘00’: {‘heating_type’: ‘radiator_valve’, ‘sensor’: None, ‘devices’: [‘04:070160’, ‘04:108169’, ‘04:108173’, ‘04:108171’]}, ‘01’: {‘heating_type’: ‘radiator_valve’, ‘sensor’: ‘04:070154’, ‘devices’: [‘04:070154’]}, ‘02’: {‘heating_type’: ‘radiator_valve’, ‘sensor’: ‘04:108167’, ‘devices’: [‘04:108167’]}, ‘03’: {‘heating_type’: ‘radiator_valve’, ‘sensor’: ‘04:073460’, ‘devices’: [‘04:073460’]}, ‘04’: {‘heating_type’: ‘radiator_valve’, ‘sensor’: {‘device_id’: ‘03:256005’, ‘is_faked’: True}, ‘devices’: [‘03:256005’, ‘04:008512’]}, ‘05’: {‘heating_type’: ‘radiator_valve’, ‘sensor’: ‘04:070150’, ‘devices’: [‘04:070150’]}}}

@zxdavb David looking at my schema I’ve obviously bound a few too many fake sensors during my testing.

How do I reset the schema? Do I need to reset the bindings within the Controller and then use restore_state: false?

Schema = {
	'controller': '01:210309',
	'system': {
		'heating_control': '13:099643'}, 
		'orphans': [], 
		'stored_hotwater': {'hotwater_sensor': '07:050079', 'hotwater_valve': '13:045348', 'heating_valve': '13:051578'},
		'underfloor_heating': {}, 
		'zones': {
			'00': {'heating_type': 'radiator_valve', 'sensor': None, 'devices': ['04:032930', '04:032958']},
 			'01': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256026', 'is_faked': True}, 'devices': ['03:256026', '04:033020']}, 
			'02': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256027', 'is_faked': True}, 'devices': ['03:256027', '03:256020', '03:256001', '04:030802', '04:030798']}, 
			'03': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256009', 'is_faked': True}, 'devices': ['03:256009', '04:030582', '03:256019']}, 
			'04': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256017', 'is_faked': True}, 'devices': ['03:256017', '04:033190', '03:256010']}, 
			'05': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256000', 'is_faked': True}, 'devices': ['03:256000', '04:032988', '03:256004']}, 
			'06': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256012', 'is_faked': True}, 'devices': ['03:256012', '04:030586', '03:256002']}, 
			'07': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256028', 'is_faked': True}, 'devices': ['03:256028', '03:256024', '04:030584']}, 
			'08': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256013', 'is_faked': True}, 'devices': ['03:256013', '03:256021', '04:030580']}, 
			'09': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256029', 'is_faked': True}, 'devices': ['03:256029', '04:030796', '04:030800', '03:256003']}, 
			'0A': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256030', 'is_faked': True}, 'devices': ['03:256030', '04:033006']}, 
			'0B': {'heating_type': 'radiator_valve', 'sensor': {'device_id': '03:256014', 'is_faked': True}, 'devices': ['03:256014', '04:032980']
		}
	}
}

This orphan: 17:000730 was caused by a corrupt packet (a corruption of 18:000730 - it is your RF gateway (dongle).

This is another corrupt packet, it should be 03:2560005 (the faked sensor).

Answer: Use an allow_list: 4. Config (reliability) · zxdavb/evohome_cc Wiki (github.com)

1 Like

Yes, this was a design failure - an upcoming version will require you to specify an ID, rather than just create one.

There is nothing you can do, except destroy the zone & start again - I’d wait until Winter is over, as no harm will be caused until then (you can backup/restore zone schedules if required).

The problem is that i have an allow list


evohome_cc:
  scan_interval: 300
  serial_port: /dev/ttyUSB1
  packet_log: /home/homeassistant/packet.log
  advanced_override: true
  config:
    max_zones: 6
  schema:
    controller: 01:155341
  allow_list:
    - 01:155341
    - 04:008512
    - 04:070150
    - 04:070154
    - 04:070160
    - 04:073460
    - 04:108167
    - 04:108169
    - 04:108171
    - 04:108173
    - 13:189740
    - 03:256005 #fake sensor office

Use an allow_list to exclude your neighbour’s devices.

You will get some (not all) functionality…

So…

You can get the sensors, OK, including current temperatures.

The rest is difficult or impossible… for now.

In that case, the bad devices will tombstone after a short while id they’re not whitelisted…

… I will have a look and confirm that is the case.

I think that does not happen, i can’t remove the entities from homeassistant.

Oh yes: sorry - I was talking about ramses_rf and not evohome_cc.

I’ll have a look at this - the whitelist is currently too soft (too forgiving) - I will make it hard.

  • soft - any device_id in a packet with a white-listed device_id (eventually) become HA entities
  • hard - only white-listed device_ids become HA entities

Actually - even better - I’ll try duplicating the filtering that is in ramses_rf up to evohome_cc

1 Like

@amorsen I see a bug in evohome_cc that will stop sensors being shown in HA, if there is no evohome - I will be fixing this soon, and after that, you will see your devices appear.

Excellent, thank you very much!

Will it be possible to use evohome_cc to fake sensors for the BDRs? It appears that they each can handle multiple DT92Es.

I am still in the process of determining which of the other devices belong to me, and which to my neighbours…

If you know how, could the following try the add_otb_sensors branch of evohome_cc?

@amorsen RAMSES devices (e.g. BDR91A, DTS92) should show up, even without an evohome controller

@TheMystery Allow/Block lists are enforced in evohome_cc as well as ramses_rf

@hsluis @phdelodder Many R8810 (OTB) sensors should show up now (about 8 or so…), including:

self.boiler_setpoint
self.boiler_water_temp,
self.ch_water_pressure,
self.dhw_flow_rate,
self.dhw_temp,
self.rel_modulation_level,
self.return_cv_temp,

Warning: I cannot easily test this last feature…

I see that ramses_rf is on version 0.94 but evohome_cc is still on 0.93, nothing committed here?

The add_otb_sensors branch of evohome_cc is using 0.9.4, the master branch is still using 0.9.3.

Your change is also in add_otb_sensors.

Hi David, I have now installed the files of the add_otb_sensors and see the following extra sensors:
boiler_setpoint
actuator
modulation_level
rel_modulation_level
I will let it run and let you know how it updates the next hours.

When I try to adjust the temperature I get the error message ‘EvoBroker’ object has no attribute ‘hass_config’

Hi @zxdavb - I have a regular Evohome configuration (touch controller) with DHW, using an HGI80 with evohome_cc. Should the detected water_heater.stored_hw entity be reporting the current water temperature, or is that not possible at the moment? I know that the controller itself can see the water temperature, but the entity only seems to know the setpoint (and other values to be fair). I can manage the various other parameters for DHW two-ways so I know that the entity is working, but I’m just not sure whether the null value for current_temperature is just my problem, or a limitation?

min_temp: 30
max_temp: 85
operation_list:
  - auto
  - boost
  - 'off'
  - 'on'
current_temperature: null
temperature: 55
target_temp_high: null
target_temp_low: null
operation_mode: null
away_mode: 'off'
config:
  setpoint: 55
  overrun: 0
  differential: 3
mode: null
status:
  temperature: null
  heat_demand: null
controller_id: '01:073765'
zone_idx: HW
heat_demand: null
friendly_name: Stored HW
supported_features: 3

There should be more than that - perhaps you could send me a log file, so I can bugfix?

I have fixed/pushed to the master branch - it is not 100% clear to me if you’ll see it, let me know - you have to “Reinstall” via the HACS UI.