zxdavb / ramses_cc Goto Github PK
View Code? Open in Web Editor NEWHA integration for CH/DHW and HVAC systems that use the RAMSES II RF protocol
License: GNU General Public License v3.0
HA integration for CH/DHW and HVAC systems that use the RAMSES II RF protocol
License: GNU General Public License v3.0
The Orcon RF15 control unit https://orcon.nl/product/afstandsbediening-15rf/ address 18:071957 which sends 2210 messages, do you know what they are?
Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.11/site-packages/ramses_rf/protocol/message.py:350
First occurred: 25 juni 2023 om 19:56:07 (5 occurrences)
Last logged: 25 juni 2023 om 20:13:20
RP --- 32:155021 18:071957 --:------ 2210 042 00FF00FFFFFF0000000000FFFFFFFFFF00FFFFFF0000000000FFFFFFFFFFFFFFFF000000000000020800 < AssertionError(Support the development of ramses_rf by reporting this packet)
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/ramses_rf/protocol/message.py", line 331, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/protocol/parsers.py", line 140, in wrapper
result = fnc(payload, msg, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_rf/protocol/parsers.py", line 1335, in parser_2210
assert payload in (
^^^^^^^^^^^^
AssertionError: Support the development of ramses_rf by reporting this packet
Logger: custom_components.evohome_cc
Source: custom_components/evohome_cc/__init__.py:62
Integration: Honeywell RF (RAMSES II protocol) (documentation, issues)
First occurred: 4:31:51 PM (1 occurrences)
Last logged: 4:31:51 PM
evohome_cc v0.7.1, using evohome_rf v0.7.1 - versions match (this is good)
Even if allow_list is specified, I get a message
Logger: evohome_rf.transport
Source: /usr/local/lib/python3.8/site-packages/evohome_rf/transport.py:323
First occurred: 4:15:47 PM (1 occurrences)
Last logged: 4:15:47 PM
Not Using an device filter (an allow_list is recommended)
If block_list is specified, I get a message
Logger: evohome_rf.schema
Source: /usr/local/lib/python3.8/site-packages/evohome_rf/schema.py:263
First occurred: 4:15:47 PM (1 occurrences)
Last logged: 4:15:47 PM
An empty blocklist was configured, so will be ignored
If both a specified, then I get a correct message that both cannot be specified. But nothing in my allow_list of block_list appears to being processed.
Here is my configuration.yaml
evohome_cc:
scan_interval: 60
serial_port: rfc2217://localhost:5001
config:
packet_log: evohome/packet.log
schema:
controller: 01:078710
allow_list:
- 10:067219
- 07:017494
- 13:109598
- 04:133277
- 04:057586
- 22:032844
- 22:060293
- 13:114333
- 04:061731
- 34:103601
- 04:061402
- 04:187989
- 34:147397
- 04:061760
- 34:103839
- 04:098464
- 04:098306
- 04:098474
- 04:098449
- 04:098455
# block_list:
# - 12:106131
# - 13:031200
# - 13:050361
# - 13:031208
# - 13:101853
# - 13:125302
# - 13:144830
# - 13:133379
# - 22:055075
# - 22:068154
# - 22:006688
# - 22:054901
# - 22:068254
# - 31:118732
# - 31:011364
Executing the climate.set_preset_mode
service call sets the target temperature to 35 degrees.
service: climate.set_preset_mode
data:
preset_mode: None
entity_id: climate.speelkamer
This is on release 0.22.3. I don’t know when it started to happen, just notice it.
Hi,
I'm having some issues with setting the zones to 'permanent'. When there is nobody home I want to set the temperature to 10°C and preset mode to permanent. I cannot use the climate.turn_off function because several zones need to remain on.
It doesn't work from the UI (via the thermostat card) and doesn't work in automations.
Is this a known issue?
Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/ramses_cc/__init__.py:190
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 13:04:16 (17 occurrences)
Last logged: 15:49:57
[281472772568784] Invalid args: For temporary_override, setpoint/active cant be None
[281472711079536] Invalid args: For temporary_override, setpoint/active cant be None
[281473355301696] Error handling message: Unknown error (unknown_error)
[281472729897696] Invalid args: For temporary_override, setpoint/active cant be None
[281472647221536] Error handling message: Unknown error (unknown_error)
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 202, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1738, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1775, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 207, in handle_service
await service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 678, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 931, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 715, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 513, in async_set_preset_mode
await self.hass.async_add_executor_job(self.set_preset_mode, preset_mode)
File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/ramses_cc/climate_heat.py", line 348, in set_preset_mode
self.svc_set_zone_mode(mode=ZoneMode.TEMPORARY)
File "/config/custom_components/ramses_cc/climate_heat.py", line 390, in svc_set_zone_mode
self._call_client_api(
File "/config/custom_components/ramses_cc/__init__.py", line 190, in _call_client_api
func(*args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/system/zones.py", line 748, in set_mode
cmd = Command.set_zone_mode(
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/helpers.py", line 27, in wrapper
return fnc(*args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 193, in wrapper
return _wrapper(fcn, cls, ctl_id, zone_idx, *args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 158, in _wrapper
return fcn(cls, *args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 1083, in set_zone_mode
mode = _normalise_mode(mode, setpoint, until, duration)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 223, in _normalise_mode
raise ValueError(
ValueError: Invalid args: For temporary_override, setpoint/active cant be None
I'm using Ramses CC version 0.21.5
Any ideas?
Regards,
Jasper
I connected an Arduino with a CC1101 and evofw3 on the Raspberry on which I run home assistant (2022.12.4).
Since I just started I only configured it as follows:
ramses_cc: serial_port: /dev/ttyACM0 # or some other serial port name
But on restart I got:
Logger: homeassistant.setup Source: setup.py:338 First occurred: 15:20:59 (1 occurrences) Last logged: 15:20:59 Unable to prepare setup for platform ramses_cc.sensor: Platform not found (cannot import name 'UnitOfTime' from 'homeassistant.const' (/usr/src/homeassistant/homeassistant/const.py)).
Any help?
Looking at the sensor for my heating relay (binary_sensor.13_197705_active), it does not seem to be getting updated consistently, and sometimes not at all.
Having observed the packets, I expected this (filtered) set of packets would have been the ones that updated the sensor, but that does not seem to be the case. Are you using something else?
2021-11-16 13:00:14 INFO (MainThread) [ramses_rf.message] || BDR:197705 | | I | actuator_state | || {'modulation_level': 0.0, '_flags_0': 'FF'}
2021-11-16 13:00:39 INFO (MainThread) [ramses_rf.message] || BDR:197705 | | I | actuator_state | || {'modulation_level': 1.0, '_flags_0': 'FF'}
2021-11-16 13:02:15 INFO (MainThread) [ramses_rf.message] || BDR:197705 | | I | actuator_state | || {'modulation_level': 0.0, '_flags_0': 'FF'}
2021-11-16 13:02:19 INFO (MainThread) [ramses_rf.message] || BDR:197705 | | I | actuator_state | || {'modulation_level': 0.0, '_flags_0': 'FF'}
2021-11-16 13:10:43 INFO (MainThread) [ramses_rf.message] || BDR:197705 | | I | actuator_state | || {'modulation_level': 1.0, '_flags_0': 'FF'}
2021-11-16 13:12:19 INFO (MainThread) [ramses_rf.message] || BDR:197705 | | I | actuator_state | || {'modulation_level': 0.0, '_flags_0': 'FF'}
2021-11-16 13:12:24 INFO (MainThread) [ramses_rf.message] || BDR:197705 | | I | actuator_state | || {'modulation_level': 0.0, '_flags_0': 'FF'}
When using the Orcon RF15 display for controlling the bypass_mode
this is reflected in HA correctly,
When instructing the remote to set bypass_open
, bypass_close
or bypass_auto
the status remains unchanged.
In the packet.log I can see the messages. What could be wrong?
With the BDR91T now functionaly is added to the controller.
To only difference between the BDR91 and BDR91T is sotware..
But still at the controller there will be different settings.
The ID is accoording to overview identically, so how does the controller know it is the T version ?
Would like to simulate this to play with this, and potentially let HA steer a relay instead of the BDR91T.
Since the BDR91T setting are still not so OK for a HeatPump..
I have on orcon fan (32:134446) in Home Assistant, all 31DA messages are present as entities.
However "filter change" (days_remaining
) from 10D0 message class does not show up. The entity simply does not exist. When I set restore_cache
to false, no change.
I see the 10D0 messages in packet.log. It is actively polled by ramses_cc:
Yesterday
2023-03-24T16:21:48.729835 000 RQ --- 18:203011 32:134446 --:------ 10D0 001 00
2023-03-24T16:21:48.747136 074 RP --- 32:134446 18:203011 --:------ 10D0 006 0008B4090000
Today
2023-03-25T07:29:50.228353 000 RQ --- 18:203011 32:134446 --:------ 10D0 001 00
2023-03-25T07:29:50.258392 073 RP --- 32:134446 18:203011 --:------ 10D0 006 0007B4080000
The latter is succesfully parsed by ramses_rf:
07:29:50.258 || HVC:134446 | HGI:203011 | RP | filter_change | || {'days_remaining': 7, 'days_lifetime': 180, 'percent_remaining': 0.04}
days_remaining
seems to be the correct entity: https://github.com/zxdavb/ramses_rf/blob/master/ramses_rf/device/hvac.py#L198
I have no clue why the entity is not in HA. And no clue how to debug this either.
configuration.yaml:
ramses_cc:
serial_port: /dev/ttyACM0 # SSM-D2
#serial_port: /dev/ttyUSB.HIG80
#serial_port: /dev/ttyUSB.nanocul
orphans_hvac: [32:134446, 37:123456, 32:132403, 37:005302, 37:005608, 37:171685, 29:162275, 18:203011, 02:250708]
restore_cache: true
packet_log:
file_name: packet.log
rotate_backups: 100
known_list:
32:134446: {class: FAN} # WTW HRC400
32:132403: {class: HVC} # zone valve unit
37:005302: {class: CO2} # CO2 woonkamer
37:005608: {class: CO2} # CO2 slaapkamer
37:171685: {class: DIS} # RF15 display
02:250704: {class: UFC} # autotemp master beneden
02:250708: {class: UFC} # autotemp master BUREN
02:250984: {class: UFC} # autotemp slave boven
21:033160: {class: THM} # Itho spider livingroom
21:043468: {class: THM}
21:043352: {class: THM}
21:043436: {class: THM}
21:043273: {class: THM}
18:203011:
class: HGI
_note: SSM-D2
29:162275: # RF15 switch bathroom
class: REM
faked: True # real RF15 but not operational, fake it...
_note: Orcon 15RF
commands:
request31DA: 'RQ --- 29:162275 32:134446 --:------ 31DA 001 00'
request10D0: 'RQ --- 29:162275 32:134446 --:------ 10D0 001 00' # filter
low: ' I --- 29:162275 32:134446 --:------ 22F1 003 000107'
high: ' I --- 29:162275 32:134446 --:------ 22F1 003 000307'
away: ' I --- 29:162275 32:134446 --:------ 22F1 003 000007'
low: ' I --- 29:162275 32:134446 --:------ 22F1 003 000107'
medium: ' I --- 29:162275 32:134446 --:------ 22F1 003 000207'
high: ' I --- 29:162275 32:134446 --:------ 22F1 003 000307'
auto: ' I --- 29:162275 32:134446 --:------ 22F1 003 000407'
auto2: ' I --- 29:162275 32:134446 --:------ 22F1 003 000507'
boost: ' I --- 29:162275 32:134446 --:------ 22F1 003 000607'
disable: ' I --- 29:162275 32:134446 --:------ 22F1 003 000707'
bypass_open: ' W --- 29:162275 32:134446 --:------ 22F7 003 00C8EF'
bypass_close: ' W --- 29:162275 32:134446 --:------ 22F7 003 0000EF'
bypass_auto: ' W --- 29:162275 32:134446 --:------ 22F7 003 00FFEF'
high_60: ' I --- 29:162275 32:134446 --:------ 22F3 007 00123C03040404'
high_30: ' I --- 29:162275 32:134446 --:------ 22F3 007 00121E03040404'
high_15: ' I --- 29:162275 32:134446 --:------ 22F3 007 00120F03040404'
reset_filter: ' W --- 29:162275 32:134446 --:------ 10D0 002 00FF'
37:123456:
# let op deze fake remote is niet meer gepaired!!!
class: REM
faked: True
commands:
away: ' I --- 37:123456 32:134446 --:------ 22F1 003 000007'
low: ' I --- 37:123456 32:134446 --:------ 22F1 003 000107'
medium: ' I --- 37:123456 32:134446 --:------ 22F1 003 000207'
high: ' I --- 37:123456 32:134446 --:------ 22F1 003 000307'
auto: ' I --- 37:123456 32:134446 --:------ 22F1 003 000407'
auto2: ' I --- 37:123456 32:134446 --:------ 22F1 003 000507'
boost: ' I --- 37:123456 32:134446 --:------ 22F1 003 000607'
disable: ' I --- 37:123456 32:134446 --:------ 22F1 003 000707'
bypass_open: ' W --- 37:123456 32:134446 --:------ 22F7 003 00C8EF'
bypass_close: ' W --- 37:123456 32:134446 --:------ 22F7 003 0000EF'
bypass_auto: ' W --- 37:123456 32:134446 --:------ 22F7 003 00FFEF'
reset_filter: ' W --- 37:123456 32:134446 --:------ 10D0 002 00FF'
_note: based upon an Orcon 15RF 6-button remote (VMN-15LF01)
scan_interval: 180
block_list:
18:111262: {} # identified as HGI. Neighbours?
advanced_features:
message_events: None
send_packet: true
ramses_rf:
enforce_known_list: true
#enable_eavesdrop: false
unable to set the setpoint of a zone
using version 0.5.16a
2021-03-07 13:43:33 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140328212481696] set_zone_setpoint() takes 3 positional arguments but 4 were given
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 137, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1488, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1523, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 642, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 681, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 544, in async_service_temperature_set
await entity.async_set_temperature(**kwargs)
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 404, in async_set_temperature
await self.hass.async_add_executor_job(
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/evohome_cc/climate.py", line 243, in set_temperature
self._evo_device.setpoint = setpoint
File "/usr/local/lib/python3.8/site-packages/evohome_rf/zones.py", line 769, in setpoint
cmd = Command.set_zone_setpoint(self._ctl.id, self.idx, value)
TypeError: set_zone_setpoint() takes 3 positional arguments but 4 were given
Do not allow HA to change a zone's friendly_name
Instead, through an error, asking the user to rename teh zone in teh controller UI - this is to keep teh friendly name and teh zone name in sync.
I am unable to use the set_system_mode
service with any of the addition options the service defines with my evohome system.
If I provide duration or period, I receive an error and the service call fails.
Additionally I can only get it working for eco_boost, all the other modes do nothing.
HA version: 2023.10.3
Ramses_cc version: 0.21.40
I can use the standard climate.set_preset_mode service but this does not allow you to set non default periods/durations.
Using the native set_system_mode like so...
eg,
tap_action:
action: call-service
service: ramses_cc.set_system_mode
data:
mode: eco_boost
duration: 120
entity_id: climate.controller
If omit duration, it will set the system mode to eco for the rest of the day.
But other modes don't seems to be settable, for example:
action: call-service
service: ramses_cc.set_system_mode
data:
mode: away
period: 2
entity_id: climate.controller
This does nothing, no error, system mode remains in current mode
Says "(WIP) HA custom component for ehohome_rf" instead of "(WIP) HA custom component for evohome_rf"
Using the service call evohome_cc.set_zone_mode I can't combine until with mode 'temporary_override' -> returns an error:
Kan service evohome_cc/set_zone_mode niet aanroepen value must be one of ['follow_schedule'] for dictionary value @ data['mode']
service: evohome_cc.set_zone_mode
data:
entity_id: climate.bureau
mode: temporary_override
setpoint: 5
until: '22:00:00'
The Nuaire Drimaster PIV is supported by ramses_cc but provides limited functionality and in my setup, the sensor entities don't provide any data/change values. That said, Faking the wireless remote works brilliantly. The following commands are supported through faking;
Nuaire 4-way switch:
I am suggesting some feature enhancement ideas for consideration, not all may be technically possible due to Nuaire's implementation. Unfortunately I am unable to help with coding but could help with the packet data collection and software testing!
Sensors:
Commands:
The Nuaire Remote Monitoring Device confirms that runtime hours and filter status is reported by the Drimaster.
I was chatting with @phdelodder about a few things, he also noted the issue/fix with window sensors:
For the window open state you need to change line 23 of
https://github.com/zxdavb/evohome_cc/blob/93622024ae852f233d75ec8b1a774e76de1fb1a7/custom_components/evohome_cc/const.py and the reason you can see zxdavb/ramses_rf@2e7e138 on file evohome_rf/devices.py at line 1018 and line 1026
Depends whether you want to fix it in evohome_cc, or evohome_rf? :)
When starting the custom component, home assistant complains about deprecated device_state_attributes
:
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc] Schema = {}
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc] Devices = ['13:003246', '12:158468', '12:165258', '12:155287', '18:198161']
2021-12-10 16:49:48 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.evohome_cc
2021-12-10 16:49:48 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.evohome_cc
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Creating a Binary Sensor (active) for 13:003246
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Creating a Binary Sensor (battery_low) for 12:158468
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Creating a Binary Sensor (battery_low) for 12:165258
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Creating a Binary Sensor (battery_low) for 12:155287
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Gateway (config), id=18:198161
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.sensor] Creating a Sensor (relay_demand) for 13:003246
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.sensor] Creating a Sensor (temperature) for 12:158468
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.sensor] Creating a Sensor (temperature) for 12:165258
2021-12-10 16:49:48 INFO (MainThread) [custom_components.evohome_cc.sensor] Creating a Sensor (temperature) for 12:155287
2021-12-10 16:49:48 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.13_003246_active (<class 'custom_components.evohome_cc.binary_sensor.EvoActuator'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-10 16:49:48 WARNING (MainThread) [homeassistant.helpers.entity] Entity binary_sensor.18_198161_config (<class 'custom_components.evohome_cc.binary_sensor.EvoGateway'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-10 16:49:48 WARNING (MainThread) [homeassistant.helpers.entity] Entity sensor.13_003246_relay_demand (<class 'custom_components.evohome_cc.sensor.EvoRelayDemand'>) implements device_state_attributes. Please report it to the custom component author.
2021-12-10 16:49:53 INFO (MainThread) [ramses_rf] ENGINE: Saving schema/state...
my manifest.json:
{
"domain": "evohome_cc",
"name": "RAMSES RF",
"documentation": "https://github.com/zxdavb/evohome_cc",
"requirements": [
"ramses-rf==0.16.24",
"pyserial-asyncio==0.5"
],
"dependencies": [],
"issue_tracker": "https://github.com/zxdavb/evohome_cc/issues",
"codeowners": ["@zxdavb"],
"version": "0.0.1"
}
I'm running Home Assistant 2021.12.0b1
:
version | core-2021.12.0b1 |
---|---|
installation_type | Home Assistant OS |
dev | false |
hassio | true |
docker | true |
user | root |
virtualenv | false |
python_version | 3.9.7 |
os_name | Linux |
os_version | 5.10.63-v8 |
arch | aarch64 |
timezone | Europe/London |
GitHub API | ok |
---|---|
Github API Calls Remaining | 4820 |
Installed Version | 1.18.0 |
Stage | running |
Available Repositories | 911 |
Installed Repositories | 6 |
logged_in | false |
---|---|
can_reach_cert_server | ok |
can_reach_cloud_auth | ok |
can_reach_cloud | ok |
host_os | Home Assistant OS 7.0 |
---|---|
update_channel | beta |
supervisor_version | supervisor-2021.12.1 |
docker_version | 20.10.9 |
disk_total | 116.5 GB |
disk_used | 3.9 GB |
healthy | true |
supported | true |
board | rpi4-64 |
supervisor_api | ok |
version_api | ok |
installed_addons | Terminal & SSH (9.2.1), Studio Code Server (3.7.0), Log Viewer (0.12.1) |
dashboards | 3 |
---|---|
resources | 2 |
views | 8 |
mode | storage |
Can the attributes listed below be add to the actuator binary sensor?
OTB:040239 | CTL:223036 | RP | actuator_state | 00001... || {'actuator_enabled': False, 'modulation_level': 0.0, '_unknown_0': '10', 'flame_active': False, 'flame_state': '00', '_unknown_1': '00FF020A64'}
With:
'10:040239': {'actuator_cycle': None, 'actuator_state': None, 'boiler_setpoint': None, 'modulation_level': 0.0, 'opentherm_status': {'boiler_temp': None, 'ch_pressure': None, 'dhw_flow_rate': None, 'dhw_temp': None, 'rel_modulation_level': None, 'return_cv_temp': None}}}
2021-03-07 13:48:38 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140170447772976] isinstance() arg 2 must be a type or tuple of types
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 137, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1488, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1523, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 642, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 681, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 679, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 446, in async_set_preset_mode
await self.hass.async_add_executor_job(self.set_preset_mode, preset_mode)
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/evohome_cc/climate.py", line 255, in set_preset_mode
self._evo_device.reset_mode()
File "/usr/local/lib/python3.8/site-packages/evohome_rf/zones.py", line 824, in reset_mode
return self.set_mode(mode="follow_schedule")
File "/usr/local/lib/python3.8/site-packages/evohome_rf/zones.py", line 815, in set_mode
cmd = Command.set_zone_mode(self._ctl.id, self.idx, mode, setpoint, until)
File "/usr/local/lib/python3.8/site-packages/evohome_rf/command.py", line 512, in set_zone_mode
elif not isinstance(setpoint, (None, float)):
TypeError: isinstance() arg 2 must be a type or tuple of types
Since I have added my new evohome_cc configuation to my configuation.yaml file I get a "Failed to restart Home AssistantCore. string indices must be integers" error when I try to restart core. Also when I do a "Check Configuration" it hangs for ever.
If I comment-out some of the evohome_cc configuation then all is good. This is the corresponding error in the logs:
File "/usr/local/lib/python3.9/site-packages/voluptuous/schema_builder.py", line 817, in validate_callable return schema(data) File "/usr/src/homeassistant/homeassistant/helpers/config_validation.py", line 797, in validator value = config[key] TypeError: string indices must be integers
Extract of my configuration.yaml file:
evohome_cc:
serial_port:
port_name: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
baudrate: 115200
timeout: 0
dsrdtr: false
rtscts: false
xonxoff: true
restore_state: true
config:
enforce_allowlist: true
max_zones: 0B
schema:
controller: 01:145378
allow_list:
- 01:145378
- 04:005496
- 04:002363
- 04:023049
- 04:096551
- 13:198335
- 18:209827
packet_log:
file_name: evohome_packet.log
rotate_bytes: null
rotate_backups: 7
If I comment-out the restore_state, config, schema, allow_list sections then all is good.
Then if I un-comment just the restore_state I get the issue (as an example).
hvac_mode remains off after window open detection has timed out.
I have noticed that it could happen when an open window was detected, and after X min the state returns to normal but the
entity isn't fully updated:
If I would restart HA it is fixed, so there must be small glitch some where.
Here are the logs:
I'm thinking it's related to https://github.com/zxdavb/evohome_cc/blob/b119afafc5e5ab33fa29a903cec39d80d71010d8/custom_components/evohome_cc/climate.py#L151
Kindly ask for support with controlling Vasco D500 ventilation unit with RF (4 buttons) remote.
I successfully configured ramses_cc with faking. I see packets from original RF transmitter:
058 I --- 29:083043 32:024669 --:------ 22F1 003 000206
060 I --- 29:083043 32:024669 --:------ 22F1 003 000306
060 I --- 29:083043 32:024669 --:------ 22F1 003 000406
in configuration.yaml i got faking device:
known_list:
18:070952: {class: HGI}
29:083043: {class: REM, faked: true}
32:024669: {class: FAN, _note: D500}
29:073042:
class: REM
faked: True
commands:
low: ' I --- 29:073042 32:024669 --:------ 22F1 003 000206'
medium: ' I --- 29:073042 32:024669 --:------ 22F1 003 000306'
high: ' I --- 29:073042 32:024669 --:------ 22F1 003 000406'
and using the command:
service: remote.send_command
data:
command: max
target:
entity_id: remote.29_083043
i see packet beeing transmited that exactly match that what were sniffed:
000 I --- 29:083043 32:024669 --:------ 22F1 003 000406
but ventilation unit is not reacting on any command.
Could you please support, and advice what would be the potential root cause, and how it can be improved ?
Thanks!
With evohome_cc I have the sensors below:
With Domoticz I also had these OTB sensors:
When selecting a beta version, it can’t be installed. I believe this is caused by the rename of evohome_cc to ramses_cc. As you can see from the log below, HACS still tries to use the old name.
Deze fout is ontstaan door een aangepaste integratie.
Logger: custom_components.hacs
Source: custom_components/hacs/websocket.py:286
Integration: HACS (documentation, issues)
First occurred: 07:53:10 (6 occurrences)
Last logged: 09:36:45
No manifest.json file found 'custom_components/evohome_cc/manifest.json'
Preset default should be AUTO and not AWAY
Round temperatures reported by the OTB to 2 decimal places.
I'm currently running the latest release at the time of this writing that is 0.20.22g with the configuration from the 0.19.2. My configuration indeed is the one with evohome_cc
.
I got updates into HACS throughout the summer and I haven't put much attention to the CHANGELOG. Then I got into this state.
Now I'm asking whether the process to follow to migrate successfully is the one from the release 0.20.15a. Could you confirm please @zxdavb?
Just a suggestion, instead of opting out (e.g. blacklist way), it might be a idea to change this to a white-list way; e.g. add option allow_list
which would mean only those controllers would be connected to.
I have a strange situation where it looks like the temperature entity for a TRV is not being created, but the demand, window status and battery entities are. This is only happening for one TRV, all others are OK. From the log, I'm seeing this:
2021-11-02 10:20:28 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (battery_low), id=04:026298
2021-11-02 10:20:28 INFO (MainThread) [custom_components.evohome_cc.binary_sensor] Found a Binary Sensor (window_open), id=04:026298
2021-11-02 10:20:28 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (heat_demand), id=04:026298
2021-11-02 10:20:28 INFO (MainThread) [custom_components.evohome_cc.sensor] Found a Sensor (temperature), id=04:026298
but all searches for that entity are failing.
This is an extract from the packet.log, searching on that id.
2021-11-02T08:19:05.774571 059 I --- 04:026298 --:------ 01:185426 3150 002 063A
2021-11-02T08:19:15.540739 059 I --- 04:026298 --:------ 04:026298 30C9 003 0005BF
2021-11-02T08:20:08.411651 ... I --- 04:026298 --:------ 01:185426 1060 003 06C801 # 1060| I|04:026298|06 (06)
2021-11-02T08:20:08.416771 ... I --- 04:026298 --:------ 04:026298 1060 003 00C801 # 1060| I|04:026298
2021-11-02T08:20:08.558479 ... I --- 04:026298 --:------ 01:185426 12B0 003 060000 # 12B0| I|04:026298|06 (06)
2021-11-02T08:20:08.922698 ... I --- 04:026298 --:------ 01:185426 3150 002 06A6 # 3150| I|04:026298|06 (06)
2021-11-02T08:20:08.925061 ... I --- 04:026298 --:------ 04:026298 30C9 003 00056B # 30C9| I|04:026298
2021-11-02T08:21:17.466113 063 I --- 04:026298 --:------ 04:026298 30C9 003 0005DB
2021-11-02T08:22:08.047815 064 I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T08:23:17.974858 064 I --- 04:026298 --:------ 04:026298 30C9 003 0005F3
2021-11-02T08:25:16.450908 065 I --- 04:026298 --:------ 04:026298 30C9 003 000607
2021-11-02T08:28:18.278433 065 I --- 04:026298 --:------ 04:026298 30C9 003 000621
2021-11-02T08:31:17.564646 060 I --- 04:026298 --:------ 04:026298 30C9 003 000634
2021-11-02T08:34:15.735271 060 I --- 04:026298 --:------ 04:026298 30C9 003 000647
2021-11-02T08:35:15.467072 059 I --- 04:026298 --:------ 01:185426 2309 003 0605DC
2021-11-02T08:35:15.481652 059 I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T08:35:17.894218 060 I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T08:38:18.675305 060 I --- 04:026298 --:------ 04:026298 30C9 003 00065A
2021-11-02T08:42:08.143821 060 I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T08:42:17.660345 060 I --- 04:026298 --:------ 04:026298 30C9 003 00066E
2021-11-02T08:49:17.348809 052 I --- 04:026298 --:------ 04:026298 30C9 003 000682
2021-11-02T08:52:23.192846 ... I --- 04:026298 --:------ 01:185426 1060 003 06C801 # 1060| I|04:026298|06 (06)
2021-11-02T08:52:23.205490 ... I --- 04:026298 --:------ 04:026298 1060 003 00C801 # 1060| I|04:026298
2021-11-02T08:52:23.409089 ... I --- 04:026298 --:------ 01:185426 2309 003 0605DC # 2309| I|04:026298|06 (06)
2021-11-02T08:52:23.416607 ... I --- 04:026298 --:------ 01:185426 12B0 003 060000 # 12B0| I|04:026298|06 (06)
2021-11-02T08:52:23.487101 ... I --- 04:026298 --:------ 01:185426 3150 002 0600 # 3150| I|04:026298|06 (06)
2021-11-02T08:52:23.719065 ... I --- 04:026298 --:------ 04:026298 30C9 003 000682 # 30C9| I|04:026298
2021-11-02T08:58:15.210531 061 I --- 04:026298 --:------ 04:026298 30C9 003 000694
2021-11-02T09:02:06.909361 057 I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T09:22:08.624545 053 I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T09:27:16.005859 058 I --- 04:026298 --:------ 04:026298 30C9 003 000681
2021-11-02T09:33:17.221380 056 I --- 04:026298 --:------ 04:026298 30C9 003 00066E
2021-11-02T09:35:12.688809 057 I --- 04:026298 --:------ 01:185426 2309 003 0605DC
2021-11-02T09:35:12.704170 057 I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T09:35:13.288467 057 I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T09:42:09.426030 056 I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T09:42:16.606795 056 I --- 04:026298 --:------ 04:026298 30C9 003 00065B
2021-11-02T09:51:15.074033 052 I --- 04:026298 --:------ 04:026298 30C9 003 000648
2021-11-02T10:02:09.820152 071 I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T10:11:16.689118 060 I --- 04:026298 --:------ 04:026298 30C9 003 000633
2021-11-02T10:20:27.098694 ... I --- 04:026298 --:------ 01:185426 1060 003 06C801 # 1060| I|04:026298|06 (06)
2021-11-02T10:20:27.113696 ... I --- 04:026298 --:------ 04:026298 1060 003 00C801 # 1060| I|04:026298
2021-11-02T10:20:27.311082 ... I --- 04:026298 --:------ 01:185426 12B0 003 060000 # 12B0| I|04:026298|06 (06)
2021-11-02T10:20:27.581447 ... I --- 04:026298 --:------ 01:185426 3150 002 0600 # 3150| I|04:026298|06 (06)
2021-11-02T10:20:27.755137 ... I --- 04:026298 --:------ 04:026298 30C9 003 000633 # 30C9| I|04:026298
2021-11-02T10:22:06.554402 065 I --- 04:026298 --:------ 01:185426 3150 002 0600
2021-11-02T10:35:13.766704 060 I --- 04:026298 --:------ 01:185426 2309 003 0605DC
2021-11-02T10:35:13.781870 060 I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T10:35:14.163014 060 I --- 04:026298 --:------ 01:185426 12B0 003 060000
2021-11-02T10:42:09.282850 054 I --- 04:026298 --:------ 01:185426 3150 002 0600
Any suggestions on how I can debug this one?
Config changed as logs warned about options that not supported
Commented Out:
enforce_known_list: true
disable_sending: false
I connected an Arduino with a CC1101 and evofw3 on the Raspberry on which I run home assistant (2022.12.4).
Since I just started I only configured it as follows:
ramses_cc: serial_port: /dev/ttyACM0 # or some other serial port name
But on restart I got:
Logger: homeassistant.setup Source: setup.py:338 First occurred: 15:20:59 (1 occurrences) Last logged: 15:20:59 Unable to prepare setup for platform ramses_cc.sensor: Platform not found (cannot import name 'UnitOfTime' from 'homeassistant.const' (/usr/src/homeassistant/homeassistant/const.py)).
Any help?
From log:
2021-03-23 20:01:53 WARNING (MainThread) [homeassistant.loader] No 'version' key in the manifest file for custom integration 'evohome_cc'. This will not be allowed in a future version of Home Assistant. Please report this to the maintainer of 'evohome_cc'
Hi
The relative_modulation_level sensor appears to be reporting its percentage incorrectly. Looking at the values reported the % appears to be incorrectly multiplied by 1000.
Examples include: 4,900%, 5,300% etc...
Thanks
-- EDIT BEGINS --
The solution for v0.20.x and v0.21.x is to use:ramses_rf.send_command
instead.
-- EDIT ENDS --
Hi,
Have
The packet flew in and out, so nanocul with HA is working.
Tried impersonate and faking, etc., seven days 12+ hours reading miles-long topics but no signs that anything is working.
This is what shows in HA Logs when using all buttons on the remote and PIV unit's response
This is my HA nanocull config
When trying to use commands via services like below
Service call
Debug output
Tried to send a packet ( boost)
Debug
and the outcome is - nothing happens
Some errors time after time appears, I have no idea what is about
Lovelace some strange things as well
I have 0 idea how people managed to make it work with Nuaire Drimaster and at least fake a remote.
Tried anything, 0 success., I assume that ramses_cc has bugs with the newest home assistant
Running the 0.5.1 for about 7 hours, the state of the controller and all the zone became "unknown".
climate.controller
State: unknown
Attributes:
hvac_modes:
- 'off'
- heat
min_temp: null
max_temp: null
preset_modes:
- none
- eco
- away
- home
- custom
current_temperature: 16
temperature: 12
preset_mode: null
controller: '01:223036'
heat_demand: 1
friendly_name: Controller
supported_features: 17
climate.controller:
state: unknown
Attributes:
hvac_modes:
- heat
- 'off'
min_temp: 5
max_temp: 35
current_temperature: 15.1
temperature: 12
controller: '01:223036'
heating_type: radiator_valve
zone_config:
min_temp: 5
max_temp: 35
local_override: true
openwindow_function: true
multiroom_mode: false
heat_demand: 0
friendly_name: Dressing
supported_features: 1
2021-01-26 06:51:29 INFO (MainThread) [custom_components.evohome_cc] Schema = {'controller': '01:223036', 'system': {'heating_control': None, 'orphans': []}, 'ufh_controllers': {}, 'stored_hotwater': None, 'zones': {'00': {'heating_type': 'radiator_valve', 'sensor': None, 'devices': ['04:231774', '04:231772', '04:231776']}, '01': {'heating_type': 'radiator_valve', 'sensor': '04:231770', 'devices': ['04:231770']}, '02': {'heating_type': 'radiator_valve', 'sensor': '04:155537', 'devices': ['04:155537', '04:155533']}, '03': {'heating_type': 'radiator_valve', 'sensor': '04:155551', 'devices': ['04:155551']}, '04': {'heating_type': 'radiator_valve', 'sensor': '04:155443', 'devices': ['04:155443']}, '05': {'heating_type': 'radiator_valve', 'sensor': '04:155445', 'devices': ['04:155445']}, '06': {'heating_type': 'radiator_valve', 'sensor': '04:155407', 'devices': ['04:155407']}, '07': {'heating_type': 'radiator_valve', 'sensor': '04:155403', 'devices': ['04:155403']}, '08': {'heating_type': 'radiator_valve', 'sensor': '04:050559', 'devices': ['04:050559']}, '09': {'heating_type': 'radiator_valve', 'sensor': '04:081849', 'devices': []}}}
2021-01-26 06:51:29 INFO (MainThread) [custom_components.evohome_cc] Params = {'system': {'mode': {'system_mode': 'auto', 'until': None}, 'language': 'nl', 'heating_control': {}}, 'stored_hotwater': None, 'zones': {'00': {'name': 'Woonkamer', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': False, 'openwindow_function': False, 'multiroom_mode': False}}, '01': {'name': 'Inkom', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '02': {'name': 'Speelkamer', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '03': {'name': 'Bureau', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '04': {'name': 'Febe', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '05': {'name': 'Badkamer', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '06': {'name': 'Margot', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '07': {'name': 'Dressing', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '08': {'name': 'Keuken', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '09': {'name': 'Slaapkamer', 'mode': None, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}}, 'mode': None, 'language': 'nl'}
2021-01-26 06:51:29 INFO (MainThread) [custom_components.evohome_cc] Status = {'system': {}, 'devices': {'04:050559': {'temperature': 18.75, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 1.0, 'window_state': False}, '04:081849': {'temperature': 14.14, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.67, 'window_state': False}, '04:155403': {'temperature': 15.06, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155407': {'temperature': 13.85, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.69, 'window_state': False}, '04:155443': {'temperature': 14.16, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.83, 'window_state': False}, '04:155445': {'temperature': 18.45, 'setpoint': 20.0, 'battery_state': None, 'enabled': True, 'heat_demand': 1.0, 'window_state': False}, '04:155533': {'temperature': 14.73, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155537': {'temperature': 14.59, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155551': {'temperature': 15.7, 'setpoint': 12.0, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:231770': {'temperature': 15.71, 'setpoint': 15.0, 'battery_state': None, 'enabled': True, 'heat_demand': 0.47, 'window_state': False}, '04:231772': {'temperature': 28.39, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.44, 'window_state': False}, '04:231774': {'temperature': 28.55, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.44, 'window_state': False}, '04:231776': {'temperature': 30.07, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.44, 'window_state': False}, '10:040239': {'actuator_cycle': {'actuator_enabled': True, 'modulation_level': 1.0, 'actuator_countdown': 60, 'cycle_countdown': None}, 'actuator_state': {'actuator_enabled': True, 'modulation_level': 0.5, 'flame_active': True, 'flame_state': '0A'}, 'enabled': True, 'boiler_setpoint': None, 'modulation_level': 0.5, 'boiler_temp': 58.0, 'ch_pressure': 1.59765625, 'dhw_flow_rate': 71.66796875, 'dwh_temp': 71.66796875, 'rel_modulation_level': 0.0, 'return_cv_temp': 57.69921875}}, 'heat_demand': 1.0, 'heat_demands': {'FC': 1.0}, 'relay_demands': {'FC': 1.0}, 'fault_log': {0: ['0021-01-19T14:08:33', 'unknown_c0', 'sensor_error', 'sensor', '02', None], 1: ['0021-01-19T14:06:06', 'unknown_c0', 'sensor_error', 'sensor', '02', None]}, 'datetime': None, 'stored_hotwater': None, 'zones': {'00': {'setpoint': 21.0, 'temperature': 21.02, 'heat_demand': 0.44, 'open_window': None}, '01': {'setpoint': 15.0, 'temperature': 15.41, 'heat_demand': 0.47, 'open_window': None}, '02': {'setpoint': 12.0, 'temperature': 14.59, 'heat_demand': 0.0, 'open_window': None}, '03': {'setpoint': 12.0, 'temperature': 15.7, 'heat_demand': 0.0, 'open_window': None}, '04': {'setpoint': 15.0, 'temperature': 13.9, 'heat_demand': 0.83, 'open_window': None}, '05': {'setpoint': 20.0, 'temperature': 17.85, 'heat_demand': 1.0, 'open_window': None}, '06': {'setpoint': 15.0, 'temperature': 13.85, 'heat_demand': 0.69, 'open_window': None}, '07': {'setpoint': 12.0, 'temperature': 15.06, 'heat_demand': 0.0, 'open_window': None}, '08': {'setpoint': 21.0, 'temperature': 18.55, 'heat_demand': 1.0, 'open_window': None}, '09': {'setpoint': 15.0, 'temperature': 14.14, 'heat_demand': None, 'open_window': None}}}
When using evohome_rf 0.5.0, I get the following error at startup:
05': {'heating_type': 'radiator_valve', 'sensor': '04:155445', 'devices': ['04:155445']}, '06': {'heating_type': 'radiator_valve', 'sensor': '04:155407', 'devices': ['04:155407']}, '07': {'heating_type': 'radiator_valve', 'sensor': '04:155403', 'devices': ['04:155403']}, '08': {'heating_type': 'radiator_valve', 'sensor': '04:050559', 'devices': ['04:050559']}, '09': {'heating_type': 'radiator_valve', 'sensor': '04:081849', 'devices': []}}}
2021-01-24 18:06:36 ERROR (MainThread) [custom_components.evohome_cc.evohome_rf] handle_exception(): Caught: Task exception was never retrieved
2021-01-24 18:06:36 ERROR (MainThread) [asyncio] Unhandled error in exception handler
context: {'message': 'Task exception was never retrieved', 'exception': AttributeError("'Evohome' object has no attribute 'devices'"), 'future': <Task finished name='Task-11943' coro=<EvoBroker.update() done, defined at /config/custom_components/evohome_cc/__init__.py:167> exception=AttributeError("'Evohome' object has no attribute 'devices'")>}
Traceback (most recent call last):
File "/usr/local/lib/python3.8/asyncio/base_events.py", line 1744, in call_exception_handler
self._exception_handler(self, context)
File "/config/custom_components/evohome_cc/evohome_rf/__init__.py", line 118, in handle_exception
raise exc
File "/config/custom_components/evohome_cc/__init__.py", line 192, in update
if new_sensors(self):
File "/config/custom_components/evohome_cc/__init__.py", line 76, in new_sensors
for d in broker.client.evo.devices
AttributeError: 'Evohome' object has no attribute 'devices'
Upgraded to Home Assistant 2023.1.0 this morning and the integration fails to load. There are two distinct errors in the logs;
Both have the same error text;
Logger: homeassistant.setup
Source: setup.py:340
First occurred: 08:49:19 (4 occurrences)
Last logged: 08:49:29
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)).
Hi, i think i have a new feature request. I have an evohome setup with a heatpump that supports heating and cooling. Basically my heatpump is controlled by 2 BRD91T1004. One for the normal demand, and one for sending that demand to the heating input or to the cooling input. From my evohome, i can set the system modus in cooling or heating. this is the support article of my setup.
When i switch from heat to cold, i see the following errors.
[ramses_rf.protocol.message] I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00
[ramses_rf.protocol.message] I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00
[ramses_rf.protocol.message] I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00
[ramses_rf.protocol.message] I --- 01:172368 13:040439 --:------ 1100 008 FC042814007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC042814007FFF00
[ramses_rf.protocol.message] I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00
[ramses_rf.protocol.message] I --- 01:172368 --:------ 01:172368 1100 008 FC180400007FFF00 < Corrupt payload: Payload doesn't match '^(00|FC)[0-9A-F]{6}(00|FF)([0-9A-F]{4}01)?$': FC180400007FFF00
Package log of today.
packet.log
'01:172368': {}
config:
enforce_known_list: false
known_list:
- '01:172368':
class: controller
- '04:197921':
class: radiator_valve
- '04:197927':
class: radiator_valve
- '04:197901':
class: radiator_valve
- '34:239834':
class: thermostat
- '13:075359':
class: electrical_relay
- '12:235249':
class: thermostat
- '13:040441':
class: electrical_relay
- '18:009876':
class: gateway_interface
- '13:040439':
class: electrical_relay
block_list:
other_list:
_is_evofw3: null
device_class: problem
friendly_name: 18:009876 status
My feature request will be, can we make it support cooling?
@tomkooij has been the source of a many recent improvements to the library, particularly the HVAC parsers. Thanks!
In addition, the latest master of ramses_rf has many other (albeit beneficial) changes, some deep within the codebase. And there is a significant bug in ramses_rf's to-do list, that will be included in this next release.
Unfortunately, there are breaking changes that I will find difficult to test/debug (i.e. I have no access to live HVAC systems via RF).
One example is:
{"setpoint_low": 19.5, "setpoint_high": 21.0}
... being changed to:
{"setpoint_bounds": [19.5, 21.0]}
The prudent action is to recruit selected users who have the right HVAC systems and involve them in this test/debug cycle, with a dev/test platform.
Specifically, their existing HA systems will not be used for this function; rather: they will have a second HA instance for test/debug. Ideally, they will have two USB dongles (at least one running evofw3), although it is likely that ser2net will be used instead.
Note: the second instance can still 'influence' with the first, as they'll share the same RF space.
First step, is to set up a development environment and clone the master branch of the:
... and get ser2net working.
Once a dev/test environment is established, start HA and any report bugs; then update the repos and repeat the cycle.
Description of setup:
Evohome controller, connected to Remeha Elga Ace heatpump with R8810A1018 (Opentherm module)
Firmware version: WiFi module: 02.00.17.00, Application module: 02.00.19.33
ramses_cc ver: 0.21.0
Home Assistant config:
ramses_cc:
serial_port:
port_name: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
baudrate: 57600 # default: 115200
packet_log:
file_name: packet.log
rotate_backups: 30
Nanocul from this supplier: https://schlauhaus.biz/en/product/nanocul-868/
Firmware: 0.7.1
Problem
After setup of the nanocul and software, all the sensors and entities became visible in Home Assistant. However, the heatpump started showing strange behaviour. Even though there is a heat demand from the Evohome to the heatpump, and output/return watertemp are below set point, every 6-10 minutes the heatpump stops heating for about 2 minutes. After this, the heatpump turns back on. The display on the heatpump doesn't show anything abnormal or error codes.
As soon as I disabled the ramses_cc plugin in Home Assistant, the heatpump started operating normally again. This can be seen in the energy diagram as attached. There was constant heatdemand most of the time between 11.35 and 13.50, but the heatpump was switching on and off. The peak around 13.40 was caused by setting the Evohome to 25 degrees to force a very high setpoint, but here the heatpump also stopped way before the setpoint was reached.
I disabled the plugin at 13.50. The Evohome send heat demand between 13.50 - 14.15 and 14.40 - 15.08. Between these timestamps, there is clear correlation between heat demand and power usage. Between 14.56 and 15.08 there was heat demand, but the heatpump reached it's setpoint. Therefore only the circulation pump was active which causes the lower power usage.
Outdoor temperature is between 10-15 degrees celcius, so defreeze cycles are not relevant.
It seems like the nanocul is interfering the messages between the Evohome and heatpump (connected through R8810A1018) Could this be caused by active probing?
I despair. For hours I've been trying to get my configuration to work under HA. I keep getting the following error message.
Invalid config for [ramses_cc]: expected a list for dictionary value @ data['ramses_cc']['known_list']. Got OrderedDict([('32:123456', OrderedDict([('class', 'FAN'), ('_note', 'Orcon HRC 400')])), ('29:123456', OrderedDict([('class', 'REM'), ('faked', True), ('commands', OrderedDict([('away', ' I --- 29:123456 32:123456 --:------ 22F1 003 000007'), ('low', ' I --- 29:123456 32:123456 --:------ 22F1 003 000107'), ('medium', ' I --- 29:123456 32:123456 --:------ 22F1 003 000207'), ('high', ' I --- 29:123456 32:123456 --:------ 22F1 003 000307'), ('auto', ' I --- 29:123456 32:123456 --:------ 22F1 003.... (See /config/configuration.yaml, line 18).
Here my Config from line 18
ramses_cc:
serial_port: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
known_list:
32:123456 : { class: FAN, _note: Orcon HRC 400 }
29:123456:
class: REM
faked: True
commands:
away: ' I --- 29:123456 32:123456 --:------ 22F1 003 000007'
low: ' I --- 29:123456 32:123456 --:------ 22F1 003 000107'
medium: ' I --- 29:123456 32:123456 --:------ 22F1 003 000207'
high: ' I --- 29:123456 32:123456 --:------ 22F1 003 000307'
auto: ' I --- 29:123456 32:123456 --:------ 22F1 003 000407'
auto2: ' I --- 29:123456 32:123456 --:------ 22F1 003 000507'
boost: ' I --- 29:123456 32:123456 --:------ 22F1 003 000607'
disable: ' I --- 29:123456 32:123456 --:------ 22F1 003 000707'
bypass_open: ' W --- 29:123456 32:123456 --:------ 22F7 003 00C8EF'
bypass_close: ' W --- 29:123456 32:123456 --:------ 22F7 003 0000EF'
bypass_auto: ' W --- 29:123456 32:123456 --:------ 22F7 003 00FFEF'
reset_filter: ' W --- 29:123456 32:123456 --:------ 10D0 002 00FF'
_note: based upon an Orcon 15RF 6-button remote (VMN-15LF01)`
When the preset mode of the controller is set to away and a zone is showing heat demand because the temperature is lower then the setpoint, this isn't visible in the climate entity.
The state of that entity(zone) should not be "auto" but should be "head", as there is heat demand.
As for the state of the controller is also showing "heat_demand" > 0 , so the state should also reflect that
home-assistant.log
Version 0.5.20
If I make a manual Preset change to a heating zone - for example, None -> Temporary - the UI will flick back to 'None', the original state, before updating to the new state (Temporary) around a minute later. I don't think this used to happen on earlier releases, such as 0.5.10, although I will roll-back to check.
Video demo attached:
https://www.dropbox.com/s/hvr6x9ag0y6gb1k/Screen%20Recording%202021-03-08%20at%2012.04.24.mov?dl=0
Version evohome_rf: 0.5.0
When the heat_demand = 0, the state of climate is unknown. In the previous version the state was heat and the attribute was: hvac_action: idle
hvac_modes:
- heat
- 'off'
min_temp: 5
max_temp: 35
current_temperature: 19.2
temperature: 16
controller: '01:223036'
heating_type: radiator_valve
zone_config:
min_temp: 5
max_temp: 35
local_override: true
openwindow_function: true
multiroom_mode: false
heat_demand: 0
friendly_name: Bureau
supported_features: 1
2021-01-25 19:34:55 DEBUG (MainThread) [custom_components.evohome_cc] Params = {'system': {'mode': None, 'language': None, 'heating_control': {}}, 'stored_hotwater': None, 'zones': {'00': {'name': 'Woonkamer', 'mode': {'zone_idx': '00', 'mode': 'follow_schedule', 'setpoint': 22.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': False, 'openwindow_function': False, 'multiroom_mode': False}}, '01': {'name': 'Inkom', 'mode': {'zone_idx': '01', 'mode': 'follow_schedule', 'setpoint': 18.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '02': {'name': 'Speelkamer', 'mode': {'zone_idx': '02', 'mode': 'temporary_override', 'setpoint': 18.0, 'until': '2021-01-25 20:30:00'}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '03': {'name': 'Bureau', 'mode': {'zone_idx': '03', 'mode': 'temporary_override', 'setpoint': 19.5, 'until': '2021-01-25 20:30:00'}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '04': {'name': 'Febe', 'mode': {'zone_idx': '04', 'mode': 'follow_schedule', 'setpoint': 12.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '05': {'name': 'Badkamer', 'mode': {'zone_idx': '05', 'mode': 'follow_schedule', 'setpoint': 18.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '06': {'name': 'Margot', 'mode': {'zone_idx': '06', 'mode': 'follow_schedule', 'setpoint': 18.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '07': {'name': 'Dressing', 'mode': {'zone_idx': '07', 'mode': 'follow_schedule', 'setpoint': 15.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '08': {'name': 'Keuken', 'mode': {'zone_idx': '08', 'mode': 'follow_schedule', 'setpoint': 21.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}, '09': {'name': 'Slaapkamer', 'mode': {'zone_idx': '09', 'mode': 'follow_schedule', 'setpoint': 12.0}, 'zone_config': {'min_temp': 5.0, 'max_temp': 35.0, 'local_override': True, 'openwindow_function': True, 'multiroom_mode': False}}}, 'mode': None, 'language': None}
2021-01-25 19:34:55 DEBUG (MainThread) [custom_components.evohome_cc] Status = {'system': {}, 'devices': {'04:050559': {'temperature': 20.6, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.71, 'window_state': None}, '04:081849': {'temperature': 18.38, 'setpoint': 12.0, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155403': {'temperature': None, 'setpoint': 15.0, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:155407': {'temperature': 17.32, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.58, 'window_state': None}, '04:155443': {'temperature': 18.14, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:155445': {'temperature': 18.03, 'setpoint': 18.0, 'battery_state': None, 'enabled': True, 'heat_demand': 0.27, 'window_state': False}, '04:155533': {'temperature': 17.67, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': False}, '04:155537': {'temperature': 17.3, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:155551': {'temperature': None, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:231770': {'temperature': 18.15, 'setpoint': None, 'battery_state': None, 'enabled': False, 'heat_demand': 0.0, 'window_state': None}, '04:231772': {'temperature': 26.03, 'setpoint': 22.0, 'battery_state': None, 'enabled': True, 'heat_demand': 0.47, 'window_state': False}, '04:231774': {'temperature': 25.0, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.47, 'window_state': None}, '04:231776': {'temperature': 27.12, 'setpoint': None, 'battery_state': None, 'enabled': True, 'heat_demand': 0.47, 'window_state': None}, '10:040239': {'actuator_cycle': None, 'actuator_state': None, 'enabled': None, 'boiler_setpoint': None, 'modulation_level': 0.0, 'boiler_temp': 32.59765625, 'ch_pressure': 1.59765625, 'dhw_flow_rate': 71.66796875, 'dwh_temp': 71.66796875, 'rel_modulation_level': 0.0, 'return_cv_temp': 32.3984375}}, 'heat_demand': None, 'heat_demands': None, 'relay_demands': None, 'fault_log': {0: ['0021-01-19T14:08:33', 'unknown_c0', 'sensor_error', 'sensor', '02', None], 1: ['0021-01-19T14:06:06', 'unknown_c0', 'sensor_error', 'sensor', '02', None]}, 'datetime': None, 'stored_hotwater': None, 'zones': {'00': {'setpoint': 22.0, 'temperature': 21.69, 'heat_demand': 0.47, 'open_window': None}, '01': {'setpoint': 18.0, 'temperature': 18.15, 'heat_demand': 0.0, 'open_window': None}, '02': {'setpoint': 15.0, 'temperature': 17.3, 'heat_demand': 0.0, 'open_window': None}, '03': {'setpoint': 16.0, 'temperature': 19.21, 'heat_demand': 0.0, 'open_window': None}, '04': {'setpoint': 12.0, 'temperature': 18.14, 'heat_demand': 0.0, 'open_window': None}, '05': {'setpoint': 18.0, 'temperature': 18.03, 'heat_demand': 0.27, 'open_window': None}, '06': {'setpoint': 18.0, 'temperature': 17.32, 'heat_demand': 0.58, 'open_window': None}, '07': {'setpoint': 15.0, 'temperature': 16.21, 'heat_demand': 0.0, 'open_window': None}, '08': {'setpoint': 21.0, 'temperature': 20.6, 'heat_demand': 0.71, 'open_window': None}, '09': {'setpoint': 12.0, 'temperature': 18.38, 'heat_demand': None, 'open_window': None}}}
I've updated this morning to the new stable version 0.20.22j released. Unfortunately it is broken
Logger: homeassistant.setup
Source: setup.py:338
First occurred: 9:59:07 AM (1 occurrences)
Last logged: 9:59:07 AM
Unable to prepare setup for platform ramses_cc.sensor: Platform not found (cannot import name 'UnitOfTime' from 'homeassistant.const' (/usr/src/homeassistant/homeassistant/const.py)).
I'm going through the code and detect that hvac_mode: uses self._evo_device.mode["setpoint"] and target_temperature: uses self._evo_device.setpoint. In case of an open window the target remains at eg 18 but the state is off, although the set point according to evohome is set to 5°c. So I guess the target _tempature should also be using self._evo_device.mode["setpoint"]?
Logger: homeassistant.setup
Source: custom_components/evohome_cc/init.py:188
First occurred: 7:50:34 (1 occurrences)
Last logged: 7:50:34
Error during setup of component evohome_cc
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 213, in _async_setup_component
result = await task
File "/config/custom_components/evohome_cc/init.py", line 100, in async_setup
await broker.async_restore_client_state()
File "/config/custom_components/evohome_cc/init.py", line 188, in async_restore_client_state
await self.client._set_state(**app_storage["client_state"])
KeyError: 'client_state'
Running: 0.5.16a
When trying to change the Preset for a zone in HA, the below is shown and no change is performed:
Failed to call service climate/set_preset_mode set_zone_mode() takes 3 positional arguments but 6 were given.
Rolling back to 0.5.10 resolves the issue.
I encounter an issue with this cc for a few days.
I tried re-install of the cc via HACS, HAOS is up to date (5.11), and last releases.
The full error message : Invalid config for [evohome_cc]: required key not provided @ data['evohome_cc']['config']. Got None.
Extract of my configuration.yaml :
evohome_cc:
scan_interval: 60
serial_port: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
schema:
controller: 01:xxxxxx
If I add the packet_log attribute, i got this error : Invalid config for [evohome_cc]: [packet_log] is an invalid option for [evohome_cc]. Check: evohome_cc->evohome_cc->packet_log.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.