And there is its flaw. I observed that it will ignore the System being set to ‘OFF’ at the Controller during the cycle after it has calculated its firing time and will carry out that calculated fire at what was the end of the next cycle whether needed or not.
If only I could get the system to discard the current cycle part way through its time.
Are there any known issues with reset_system_mode? I’m getting an error when I use it, even from the developer tools. Version 22.1
Automation:
- id: '1607967971509'
alias: Reset schedule on Sunday
description: Resets the heating system to follow schedule at 13:30 each Sunday
trigger:
- platform: time
at: '13:20'
condition:
- condition: time
weekday:
- sun
- condition: state
entity_id: climate.controller
attribute: system_mode
state: Auto
action:
- service: ramses_cc.reset_system_mode
data:
entity_id: climate.controller
mode: single
Error Log:
2022-11-14 15:52:58.790 ERROR (MainThread) [homeassistant.components.automation.reset_schedule_on_sunday] Reset schedule on Sunday: Error executing script. Unexpected error for call_service at pos 1: '06'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 451, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 684, in _async_call_service_step
await service_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1744, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1781, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 770, 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 943, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 709, in _handle_entity_call
result = hass.async_run_job(partial(getattr(entity, func), **data)) # type: ignore[arg-type]
File "/usr/src/homeassistant/homeassistant/core.py", line 621, in async_run_job
return self.async_run_hass_job(HassJob(target), *args)
File "/usr/src/homeassistant/homeassistant/core.py", line 573, in async_run_hass_job
hassjob.target(*args)
File "/config/custom_components/ramses_cc/climate_heat.py", line 215, in svc_reset_system_mode
self._call_client_api(self._device.reset_mode)
File "/config/custom_components/ramses_cc/__init__.py", line 216, in _call_client_api
func(*args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/system/heat.py", line 944, in reset_mode
return self.set_mode(SYS_MODE_MAP.AUTO_WITH_RESET)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/system/heat.py", line 935, in set_mode
Command.set_system_mode(self.id, system_mode, until=until)
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 186, in wrapper
return _wrapper(fcn, cls, dst_id, *args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 163, in _wrapper
return fcn(cls, *args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 900, in set_system_mode
system_mode = SYS_MODE_MAP._hex(
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/const.py", line 172, in _hex
raise KeyError(key)
KeyError: '06'
2022-11-14 15:52:58.809 ERROR (MainThread) [homeassistant.components.automation.reset_schedule_on_sunday] While executing automation automation.reset_schedule_on_sunday
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/automation/__init__.py", line 551, in async_trigger
await self.action_script.async_run(
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1524, in async_run
await asyncio.shield(run.async_run())
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 409, in async_run
await self._async_step(log_exceptions=False)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 453, in _async_step
self._handle_exception(
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 476, in _handle_exception
raise exception
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 451, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 684, in _async_call_service_step
await service_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1744, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1781, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 770, 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 943, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 709, in _handle_entity_call
result = hass.async_run_job(partial(getattr(entity, func), **data)) # type: ignore[arg-type]
File "/usr/src/homeassistant/homeassistant/core.py", line 621, in async_run_job
return self.async_run_hass_job(HassJob(target), *args)
File "/usr/src/homeassistant/homeassistant/core.py", line 573, in async_run_hass_job
hassjob.target(*args)
File "/config/custom_components/ramses_cc/climate_heat.py", line 215, in svc_reset_system_mode
self._call_client_api(self._device.reset_mode)
File "/config/custom_components/ramses_cc/__init__.py", line 216, in _call_client_api
func(*args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/system/heat.py", line 944, in reset_mode
return self.set_mode(SYS_MODE_MAP.AUTO_WITH_RESET)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/system/heat.py", line 935, in set_mode
Command.set_system_mode(self.id, system_mode, until=until)
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 186, in wrapper
return _wrapper(fcn, cls, dst_id, *args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 163, in _wrapper
return fcn(cls, *args, **kwargs)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/command.py", line 900, in set_system_mode
system_mode = SYS_MODE_MAP._hex(
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/const.py", line 172, in _hex
raise KeyError(key)
KeyError: '06'
This looks like a genuine bug.
So that it is not lost, can you please submit it as a ramses_rf issue at Issues · zxdavb/ramses_rf · GitHub
@zxdavb David I think you are right. I tried my pro micro on another PI and after an hour it stopped working and it would not respond.
I set up another serial input to my HA Pi and it worked fine with out issue, tried usb 2 and 3 ports.
What other hardware are being used as a cheap pro micro does not cut it?
Sometimes i don’t understand the evohome system.
Past week it goes to setpoint and than does only fire up the boiler 6 times an hour for 1min (as configered), so it’s stays on setpoint, sometimes for 2min.
Today it’s warmer than yesterday but now it fires up the boiler for 3mins 6 times an hour and now it’s over setpoint. I only changed the batteries of the hr92 because they where empty but that cannot be the reason.
For now I lowered setpoint by 0.5 degree, now it’s back to 2mins.
I noticed that setpoint is now configurable in 0.1 steps that was not possible last year, is something changed?
If I check my Packet.log I get the following:
2022-11-15T01:21:58.925565 092 I --- 31:035676 08:027240 --:------ 0008 013 00979DA846F3F33C0D3BA2617C
2022-11-15T01:28:21.293768 082 I --- 08:027240 63:262142 --:------ 10E0 038 000002FF0801FFFFFFFEFFFFFFFF1C0B07E04A61737065722045494D00000000000000000000
2022-11-15T14:01:44.764076 # ramses_rf 0.21.0
2022-11-15T14:01:45.372037 ... I --- 31:035676 63:262142 --:------ 10E0 038 000002FF1F02FFFFFFFFFFFFFFFF100207E14A61737065722053746174205458585800000000 # 10E0| I|31:035676
2022-11-15T14:01:45.391196 ... I --- 08:027240 63:262142 --:------ 10E0 038 000002FF0801FFFFFFFEFFFFFFFF1C0B07E04A61737065722045494D00000000000000000000 # 10E0| I|08:027240
2022-11-15T14:01:47.062389 000 I --- 18:070686 63:262142 --:------ 7FFF 015 001001847B988C2576302E32312E30
2022-11-15T14:01:47.658232 000 RQ --- 18:070686 31:035676 --:------ 0008 001 00
2022-11-15T14:02:01.211465 000 RQ --- 18:070686 08:027240 --:------ 22F1 001 00
2022-11-15T14:02:01.799939 000 RQ --- 18:070686 31:035676 --:------ 0008 001 00
2022-11-15T14:02:11.023231 000 RQ --- 18:070686 08:027240 --:------ 2210 001 00
2022-11-15T14:02:14.157094 000 RQ --- 18:070686 31:035676 --:------ 0008 001 00
2022-11-15T14:02:14.686537 000 RQ --- 18:070686 08:027240 --:------ 22E0 001 00
2022-11-15T14:02:24.229191 000 RQ --- 18:070686 08:027240 --:------ 22E5 001 00
2022-11-15T14:02:39.819940 000 RQ --- 18:070686 08:027240 --:------ 22E9 001 00
2022-11-15T14:02:44.093055 000 RQ --- 18:070686 31:035676 --:------ 0008 001 00
2022-11-15T14:02:44.329394 000 RQ --- 18:070686 08:027240 --:------ 22F2 001 00
2022-11-15T14:02:54.037179 000 RQ --- 18:070686 08:027240 --:------ 22F4 001 00
2022-11-15T14:03:03.991317 000 RQ --- 18:070686 08:027240 --:------ 22F8 001 00
2022-11-15T14:03:13.881473 000 RQ --- 18:070686 08:027240 --:------ 313E 001 00
2022-11-15T14:03:14.106489 000 RQ --- 18:070686 31:035676 --:------ 0008 001 00
2022-11-15T14:03:23.788573 000 RQ --- 18:070686 08:027240 --:------ 3222 001 00
2022-11-15T14:03:36.645315 000 RQ --- 18:070686 08:027240 --:------ 10D0 001 00
2022-11-15T14:03:44.111680 000 RQ --- 18:070686 31:035676 --:------ 0008 001 00
2022-11-15T14:03:44.337632 000 RQ --- 18:070686 08:027240 --:------ 22F1 001 00
2022-11-15T14:03:54.070206 000 RQ --- 18:070686 08:027240 --:------ 2210 001 00
2022-11-15T14:04:03.955346 000 RQ --- 18:070686 08:027240 --:------ 22E0 001 00
2022-11-15T14:04:13.886760 000 RQ --- 18:070686 08:027240 --:------ 22E5 001 00
2022-11-15T14:04:23.786414 000 RQ --- 18:070686 08:027240 --:------ 22E9 001 00
2022-11-15T14:04:33.669043 000 RQ --- 18:070686 08:027240 --:------ 22F2 001 00
2022-11-15T14:04:43.594857 000 RQ --- 18:070686 08:027240 --:------ 22F4 001 00
2022-11-15T14:04:53.467401 000 RQ --- 18:070686 08:027240 --:------ 22F8 001 00
2022-11-15T14:05:03.380357 000 RQ --- 18:070686 08:027240 --:------ 313E 001 00
2022-11-15T14:05:13.363679 000 RQ --- 18:070686 08:027240 --:------ 3222 001 00
2022-11-15T14:05:26.275923 000 RQ --- 18:070686 08:027240 --:------ 10D0 001 00
2022-11-15T14:05:36.152785 000 RQ --- 18:070686 08:027240 --:------ 22F1 001 00
So I’ve added the following into my configuration/.yaml
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
packet_log:
file_name: packet.log
rotate_backups: 28
ramses_rf:
enforce_known_list: false # if not true, still enforces the block_list
disable_discovery: false
disable_sending: false # do not transmit any packets, ever
enable_eavesdrop: false # can be used to create an initial system schema
# orphans_hvac: [30:123456, 32:222222, 32:444444]
known_list:
18:070686: { class: FAN, _note: Nuaire PIV }
08:027240: {class: FAN, _note: Nuaire PIV1 }
32:222222:
class: REM
faked: true
commands:
normal: ' I --- 32:222222 18:070686 --:------ 22F1 003 00020A'
boost: ' I --- 32:222222 18:070686 --:------ 22F1 003 00030A'
heater_auto: ' I --- 32:222222 18:070686 --:------ 22F1 003 00090A'
heater_off: ' I --- 32:222222 18:070686 --:------ 22F1 003 000A0A'
_note: Nuaire DRI-ECO-4S (4-way switch)
I copied the main bit of code from the guide, but added the 18:070686 but into the Nuaire 4-way switch configuration - as it didn’t find anything without… It was a guess though.
This pulls up a number of sensors and a climate as below:
However, they all show as unavailable… What can I do to get these visable. Where have I gone wrong…
If I look at your packet log, I think 18:070686 is your SSM-D USB stick, not your fan.
You can add it to the known_list:
known_list:
18:070686:
class: HGI
_note: 'SSM-D'
(I don’t like the curly braces notation, sorry).
31:035676 identies as “Jasper Stat”, 08:027240 identifies as “Jasper EIM”. Are they both fans?
OK - I’ll amend the numbers accordingly - reboot and see what comes up.
I don’t know what Jasper Stat or EIM are - to my knowledge I don’t have anything on the frequency. The only thing I have is a Nuaire PIV
I believe this is older Honeywell kit - The stat is the controller, the EIM (equipment interface module) is the relay. They appear to be rare, but whenever I do see them, they have obscured payloads, so they are not well understood.
I have only seen them in retail establishments - stores, coffee shops etc.
Use a device id filter to exclude them from HA (you cant enforce the known_list just yet - use a block_list for now).
What model is your PIV - is it a HC or a LC? I think you said HC before.
If it is a HCS - I don’t think it supports RF? Check with Nuaire.
Assuming it does have an RF module - you have to do something to make it send a packet, so you get its device id.
Turn it off/on - play with its buttons, try to get it to bind with a faked remote, etc.
BTW, all the Nuaire kit I’ve seen have ids starting with 30: or 32:.
They could be Honeywell T-series kit.
If anyone has some, I’d be willing to have a go at decoding the payloads - may not be encrypted, just obscured.
I managed to do some setpoint balancing and Im sure I made everything more efficient, just need clarification on zone’s calling for heat (hvac_action):
Is zone’s calling for heat value manually calculated by ramses_cc or is it directly returned from the controller? This zone is calling for heat whole day today (the most so far), but the BDR91 is the least active so far. 
I cant seem to pinpoint exactly what is mostly firing the boiler. So this zone finally went to sleep 15 minutes ago, now no zones are calling for heat + all heat demands are 0% + the highest valve position is 30% and yet relay_demand is unchanged for exactly 2h at 3% and boiler last fired up exactly 1h ago.
Each zone’s heat demand is ‘manually’ calculated by ramses_rf:
For the above to work, it relies upon the controller and ramses_rf having the same information (having the same schema, seeing the same packets).
Simply check the controller UI whenever you like to confirm that each pair of heat demands match.
Due to optimizations, and other factors a non-zero heat demand from a zone may not result in heat coming from the boiler.
I am sure you know: a zone’s heat demand isn’t the same as its TRV (assuming a single TRV zone): a TRV pin valve position of 30% equals a zone heat demand of 0%
Ah - yes I believe this is the HCS version. I’ll check the manual. That will cause a problem 
Also, for others information as well as mine, in the example for the 4-way switch
32:222222:
class: REM
faked: true
commands:
normal: ' I --- 32:222222 30:082155 --:------ 22F1 003 00020A'
boost: ' I --- 32:222222 30:082155 --:------ 22F1 003 00030A'
heater_auto: ' I --- 32:222222 30:082155 --:------ 22F1 003 00090A'
heater_off: ' I --- 32:222222 30:082155 --:------ 22F1 003 000A0A'
_note: Nuaire DRI-ECO-4S (4-way switch)
Am I correct to assume that the 32:222222 is the number of the NUAIRE in this instance and that number would be replaced with whatever is ‘discovered’? Is the 30:082155 the same for all and to do with the remote, or is that the double string from discovery?
In your example, 32:222222 is the RF remote, as specified by:
32:222222:
class: REM
… and 30:082155 is the fan (the Nuaire PIV).
No, 32:222222 is the id of the (faked) remote (source), 30:082155 is the ID of the fan (destination).
Thank you - both - for the clarity
@zxdavb If you wanted to determine which zone is the most guilty of boiler firing, how would you do it? Which state would you measure?
Question not directely related with ramses_cc but maybe with the protocol.
I have a few time a year that there is no heat demand when it should be.
Today i have 1 room on 19.5 setpoint and the real temperature is 18.6.
But there is no heat demand on the room or on the hr92 or on the controller or bdr91.
I have already removed the battries from the controller and turned the power off from de bdr91 but stil nothing. Restarted ha maybe there is something with the nanocul device, but no change.
On the br91 the setpoint is updated if i set it higer or lower but no heat demand.
I had this before the only thing where i got it working is with is removing all hr92’s batteries en put them back, didn’t done that yet.
someone having this problem before and knows what it can be?